Jump to content
Froxlor Forum

chrisv

Members
  • Posts

    11
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by chrisv

  1. Nice to see continuous progress on this project, and thanks d00p for all the work!

     

    One point, however:

     

    the defined directory (default /etc/apache2/ssl/) will be truncated by the cronjob

     

     

    If this folder is truncated by the cronjob, wouldn't it be better to set the default to some folder which doesn't exist usually (for example /etc/froxlor/customer-certificates/), to avoid accidental damage? There may be people who don't read release notes before upgrading...

  2. if you want, collect some more infos about that, and i can take a look at this (you might as well just report a bug (feature request) for that)

    I have found a quite detailed series of posts on how to set up shared hosting with mod_wsgi, which also takes into account the dependency/virtualenv problem (Python relies very heavily on shared libraries, and different users/applications often require different versions of these libraries, so you can't just install them globally as you would with PHP extensions). But while this approach may serve as a very good starting point, it would require a little bit more work (for Froxlor) than just adding a few lines to a config...

     

    Unfortunately I do not have really much time to help much with this at the moment :( Also, for users (like me) who do not require a real shared-hosting-proof solution there is an easy workaround which allows to manage DNS/Mail/FTP/Stats/... with Froxlor while the actual site is served by python:

     

    1. create the domain(s) as usual in Froxlor
    2. create the virtualenv(s) as usual somewhere on the filesystem
    3. put the python project folder(s) also somewhere on the filesystem (for security reasons, this should be outside of the document root)
    4. create a .wsgi file as described in WSGI docs
    5. copy all the static media files into a single folder below the document root as defined in Froxlor (e.g. /var/customers/webs/customername/domain.tld/media/)
    6. now add a custom snippet to the respective domain config(s):
       
      Alias /media /var/customers/webs/customername/domain.tld/media
      WSGIScriptAlias / /path/to/wsgi/myapp.wsgi
      


    In this setup, the Python app would run under the web server's user ("embedded mode", similar to mod_php). For added security, daemon mode (similar to suexec/fcgid mode with PHP) could be activated by adding

     

    WSGIDaemonProcess site-1 user=user-1 group=user-1 threads=25
    WSGIProcessGroup site-1
    

    to the vhost config (the various options and statements are explained in the mod_wsgi docs).

     

    there is no ETA for 1.0

     

    I suspected an anwser like that ;) So would it be safe to say that smaller features/improvements should be directed at 0.9.x for the time being?

  3. hi,

     

    since I am very satisfied with Froxlor managing my PHP sites, I want these cool features for my Django-based sites, too ;)

     

    And while it is possible to have this by just adding custom snippets to the apache config of the domain(s) in question, I wonder whether anyone would be interested in (or even willing to help with) a more general solution, which would eventually allow customers to deploy their own Python developments. Also, I would like to ask whether it would make sense to implement this against current branch (0.9.x) or against 1.0 (are there estimates yet when this will be available?).

     

    Any input will be appreciated...

     

    regards,

    chris

  4. If just 20,- Euros per month will really help you, I can pay this for the next year (PM me with a bank account #, if possible, so we can avoid the PayPal tax).

     

    Some additional ideas for generating revenue/taking the project further:

     

    1.) backlinks from a PR5 site (as froxlor.org is) are worth something. And as long as you dont overplay it, nothing bad will happen - BTDT ;)

     

    2.) people are much more willing to pay for something concrete. That's not only for psychologic reasons (if you get something in return, you can tell yourself that you have made a good deal. Also, seeing a concrete result as the consequence of your action is much more rewarding than just having supported the project somehow, without knowing whether it made a difference at all), but has also concrete implications for commercial enterprises: Paying for feature xyz is an expenditure ("Betriebsausgabe") and there is nothing a tax auditor can do about it. Donations, on the other hand, are much more difficult to get accepted.

     

    3.) because of 2.), it would definitively be useful if one could "vote" for issues/feature requests with money

     

    4.) another idea: getting enough donations to pay for a regular full-time developer will probably be difficult at this stage, except you find a really big sponsor. A much less expensive alternative would be an internship, provided you are willing and capable of overseeing that (there are some organizational requirements, and of course you also need someone acting as tutor). The advantage of internship is that you can really get something done in these two or three months, if you have a motivated intern. And the chance of getting something done may motivate people to donate (see 2.)...

×
×
  • Create New...