Hello, I wrote small tool that should make our life much more comfortable. It's like apachectl for Dancer. https://github.com/knutov/dancerctl This is working prototype. Any comments, especially about default paths and values, are welcome. -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130
On Mon, Nov 21, 2011 at 8:15 AM, Nick Knutov <mail@knutov.com> wrote:
Hello,
I wrote small tool that should make our life much more comfortable. It's like apachectl for Dancer.
https://github.com/knutov/**dancerctl<https://github.com/knutov/dancerctl>
This is working prototype. Any comments, especially about default paths and values, are welcome.
Looks very cool! I wish I had time to look at it in more detail now, but alas I'm busier than someone who is otherwise very busy. :) Still, great initiative and it looks very useful! :)
The main question - is it ok to use /etc/dancer.conf ~/.dancer ~/.dancer/ as default config files? Or may be better to change their names? 23.11.2011 16:59, sawyer x пишет:
On Mon, Nov 21, 2011 at 8:15 AM, Nick Knutov <mail@knutov.com <mailto:mail@knutov.com>> wrote:
Hello,
I wrote small tool that should make our life much more comfortable. It's like apachectl for Dancer.
https://github.com/knutov/__dancerctl <https://github.com/knutov/dancerctl>
This is working prototype. Any comments, especially about default paths and values, are welcome.
Looks very cool!
I wish I had time to look at it in more detail now, but alas I'm busier than someone who is otherwise very busy. :)
Still, great initiative and it looks very useful! :)
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
-- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130
On Wed, Nov 23, 2011 at 7:35 PM, Nick Knutov <mail@knutov.com> wrote:
The main question - is it ok to use /etc/dancer.conf ~/.dancer ~/.dancer/ as default config files? Or may be better to change their names?
It would be hard for me to officially say yes. Perhaps if we could integrate dancerctl into the Dancer core, this would make it more possible. What do you think? I imagine that meanwhile you could unofficially use it, and perhaps in the future we'll need .dancer and ask you to change it to something else like .dancerapps, or .dancerctl, or whatever. At the moment it seems unlikely we would use .dancer. What do you think?
Integration dancerctl into the Dancer core is good idea, I was always wondered why `dancer -a` exists while `dancer start` don't. The technical side is more complex, at least I need separate repository for the first time to finish adaptation to our shared hosting (and I'm not good with git - it's my first time, I always used svn before). The first idea is just call dancertctl from dancer (something like `dancer start` calls `dancerctl start`) - this allows visually integrate them now while code will remain separate. Also it's will be good to mention this script on main site and documentation, dancerctl way to run and control app is much easier then all other ways known to me. This should be good for new to Dancer users. 24.11.2011 18:19, sawyer x пишет:
On Wed, Nov 23, 2011 at 7:35 PM, Nick Knutov <mail@knutov.com <mailto:mail@knutov.com>> wrote:
The main question - is it ok to use /etc/dancer.conf ~/.dancer ~/.dancer/ as default config files? Or may be better to change their names?
It would be hard for me to officially say yes. Perhaps if we could integrate dancerctl into the Dancer core, this would make it more possible. What do you think?
I imagine that meanwhile you could unofficially use it, and perhaps in the future we'll need .dancer and ask you to change it to something else like .dancerapps, or .dancerctl, or whatever. At the moment it seems unlikely we would use .dancer.
What do you think?
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
-- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130
Alright, considering we have some common ground on integrating paths here, I think we can put this aside for a little bit while we individually (or together :) work on maturing the independent parts so we could reach a point in time in which it will be easier to integrate them. I wish to integrate Carlos' work from GSoC (which posed quite some difficulty) and make a few more releases covering issues which should be closed. You want to mature dancerctl some more and decouple it from your company logic. I think that we could work on these things and once they would be resolved, we could resume discussion on integrating dancerctl into the core and how to do that. Thanks Nick. :) S. On Thu, Nov 24, 2011 at 2:55 PM, Nick Knutov <mail@knutov.com> wrote:
Integration dancerctl into the Dancer core is good idea, I was always wondered why `dancer -a` exists while `dancer start` don't.
The technical side is more complex, at least I need separate repository for the first time to finish adaptation to our shared hosting (and I'm not good with git - it's my first time, I always used svn before).
The first idea is just call dancertctl from dancer (something like `dancer start` calls `dancerctl start`) - this allows visually integrate them now while code will remain separate.
Also it's will be good to mention this script on main site and documentation, dancerctl way to run and control app is much easier then all other ways known to me. This should be good for new to Dancer users.
24.11.2011 18:19, sawyer x пишет:
On Wed, Nov 23, 2011 at 7:35 PM, Nick Knutov <mail@knutov.com <mailto:mail@knutov.com>> wrote:
The main question - is it ok to use /etc/dancer.conf ~/.dancer ~/.dancer/ as default config files? Or may be better to change their names?
It would be hard for me to officially say yes. Perhaps if we could integrate dancerctl into the Dancer core, this would make it more possible. What do you think?
I imagine that meanwhile you could unofficially use it, and perhaps in the future we'll need .dancer and ask you to change it to something else like .dancerapps, or .dancerctl, or whatever. At the moment it seems unlikely we would use .dancer.
What do you think?
______________________________**_________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/**cgi-bin/listinfo/dancer-users<http://www.backup-manager.org/cgi-bin/listinfo/dancer-users>
-- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 ______________________________**_________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/**cgi-bin/listinfo/dancer-users<http://www.backup-manager.org/cgi-bin/listinfo/dancer-users>
I think dancerctl is a great idea and will be useful to many people. However, I would not like it to be imposed on us in the future by integrating it into the core as such. Personally, I prefer to create my own custom ctl scripts because some of my apps have unique startup requirements, such as chrooting. Also, since your script calls system commands such as ps, it is unlikely it will be platform agnostic. On 24 November 2011 12:55, Nick Knutov <mail@knutov.com> wrote:
The first idea is just call dancertctl from dancer (something like `dancer start` calls `dancerctl start`) - this allows visually integrate them now while code will remain separate.
On Nov 25, 2011, at 9:03 AM, al wrote:
I think dancerctl is a great idea and will be useful to many people. However, I would not like it to be imposed on us in the future by integrating it into the core as such. Personally, I prefer to create my own custom ctl scripts because some of my apps have unique startup requirements, such as chrooting. Also, since your script calls system commands such as ps, it is unlikely it will be platform agnostic.
I wholeheartedly agree. `dancerctl` (or, my own `web_ctl`) is a good solution for a very specific setup (Dancer + plackup). It won't work in other deployment situations, and certainly won't work on Windows. It should not be a part of the core. Perhaps it could be offered as a plugin, or remain an external utility.
On 24 November 2011 12:55, Nick Knutov <mail@knutov.com> wrote:
The first idea is just call dancertctl from dancer (something like `dancer start` calls `dancerctl start`) - this allows visually integrate them now while code will remain separate.
Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
On Fri, Nov 25, 2011 at 5:16 PM, Mr. Puneet Kishor <punk.kish@gmail.com>wrote:
On Nov 25, 2011, at 9:03 AM, al wrote:
I think dancerctl is a great idea and will be useful to many people. However, I would not like it to be imposed on us in the future by integrating it into the core as such. Personally, I prefer to create my own custom ctl scripts because some of my apps have unique startup requirements, such as chrooting. Also, since your script calls system commands such as ps, it is unlikely it will be platform agnostic.
I wholeheartedly agree. `dancerctl` (or, my own `web_ctl`) is a good solution for a very specific setup (Dancer + plackup). It won't work in other deployment situations, and certainly won't work on Windows. It should not be a part of the core. Perhaps it could be offered as a plugin, or remain an external utility.
Those are good points. Thanks for raising them!
On 24 November 2011 12:55, Nick Knutov <mail@knutov.com> wrote:
The first idea is just call dancertctl from dancer (something like
`dancer
start` calls `dancerctl start`) - this allows visually integrate them now while code will remain separate.
Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
Did you ever seen deployment case when plackup is not used? Does it have any practical reason? The main goal of dancerctl is to provide easy way to manage dancer apps. Really easy. UBIC, daemontools, custom scripts are too complex for the most of users. Also dancerctl is universal. You can user-friendly setup any plackup parameter, including server (for example, you can use FCGI instead of starman). It's platform specific now (by the way, it's only 0.03 version), but it is known bug ;) It will be changed in future. 25.11.2011 21:16, Mr. Puneet Kishor пишет:
I wholeheartedly agree. `dancerctl` (or, my own `web_ctl`) is a good solution for a very specific setup (Dancer + plackup). It won't work in other deployment situations, and certainly won't work on Windows. It should not be a part of the core. Perhaps it could be offered as a plugin, or remain an external utility.
-- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130
On Nov 25, 2011, at 11:01 AM, Nick Knutov wrote:
Did you ever seen deployment case when plackup is not used? Does it have any practical reason?
I routinely use Dancer apps with Apache cgi. The performance, while not great, is good enough, and works quite well for a lot of apps. Also, Apache with mod_perl works quite well, though with multiples apps and sessions, routes can collide. -- Puneet Kishor
It's a little bit different, in this case you do not use personally any of starters, apache did all work itself. 25.11.2011 23:05, Mr. Puneet Kishor wrote:
On Nov 25, 2011, at 11:01 AM, Nick Knutov wrote:
Did you ever seen deployment case when plackup is not used? Does it have any practical reason?
I routinely use Dancer apps with Apache cgi. The performance, while not great, is good enough, and works quite well for a lot of apps. Also, Apache with mod_perl works quite well, though with multiples apps and sessions, routes can collide.
-- Puneet Kishor
-- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130
With Plack there are number of ways to run the script. You can always use any of them, default/integrated way does not matter. 25.11.2011 21:03, al пишет:
I think dancerctl is a great idea and will be useful to many people. However, I would not like it to be imposed on us in the future by integrating it into the core as such. Personally, I prefer to create my own custom ctl scripts because some of my apps have unique startup requirements, such as chrooting. Also, since your script calls system commands such as ps, it is unlikely it will be platform agnostic.
On 24 November 2011 12:55, Nick Knutov<mail@knutov.com> wrote:
The first idea is just call dancertctl from dancer (something like `dancer start` calls `dancerctl start`) - this allows visually integrate them now while code will remain separate.
-- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130
btw, can you describe your case with chrooting? I can add support of this feature. Platform-specific is known bug, it will be fixed in future. 25.11.2011 21:03, al пишет:
Personally, I prefer to create my own custom ctl scripts because some of my apps have unique startup requirements, such as chrooting. Also, since your script calls system commands such as ps, it is unlikely it will be platform agnostic.
-- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130
An unprivileged process can only be chrooted by another process with superuser privileges. This requires separation of dancerctl and the Dancer startup process. But if dancerctl was bundled with the Dancer distribution, instead of hooked into the core, I think that would be good. [By the way, thanks for asking, but it is not worth implementing such a feature in dancerctl. Chrooting Perl is not simple and very few people do this.] On 25 November 2011 17:04, Nick Knutov <mail@knutov.com> wrote:
btw, can you describe your case with chrooting? I can add support of this feature.
Platform-specific is known bug, it will be fixed in future.
25.11.2011 21:03, al пишет:
Personally, I prefer to create my own custom ctl scripts because some of my apps have unique startup requirements, such as chrooting. Also, since your script calls system commands such as ps, it is unlikely it will be platform agnostic.
-- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130
Hello , On 11/28/2011 11:37 PM, al wrote:
An unprivileged process can only be chrooted by another process with superuser privileges. This requires separation of dancerctl and the Dancer startup process. But if dancerctl was bundled with the Dancer distribution, instead of hooked into the core, I think that would be good.
[By the way, thanks for asking, but it is not worth implementing such a feature in dancerctl. Chrooting Perl is not simple and very few people do this.]
I have some chrooted perl applications , there are some tools which make live easier: for example makejail [python] , jailtool , jailer .. Best regards , Alex
On 25 November 2011 17:04, Nick Knutov <mail@knutov.com> wrote:
btw, can you describe your case with chrooting? I can add support of this feature.
Platform-specific is known bug, it will be fixed in future.
25.11.2011 21:03, al пишет:
Personally, I prefer to create my own custom ctl scripts because some of my apps have unique startup requirements, such as chrooting. Also, since your script calls system commands such as ps, it is unlikely it will be platform agnostic.
-- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
participants (5)
-
al -
Alex Mestiashvili -
Mr. Puneet Kishor -
Nick Knutov -
sawyer x