Jump to content
Froxlor Forum


  • Content Count

  • Joined

  • Last visited

  • Days Won


chrisv last won the day on September 21 2011

chrisv had the most liked content!

Community Reputation

2 Neutral

About chrisv

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Actually, after some consideration I think it can be done with less changes: we don't need a table which says which task to run where, as froxlor_master_cronjob.php can already do that: scripts/froxlor_master_cronjob.php --tasks scripts/froxlor_master_cronjob.php --traffic ... we therefore only need a mechanism which prevents generation of (webserver) config for IPs which are not bound to the host - and this is relatively easy I created a proof-of-concept in this branch - so far Apache only. Any testers/comments welcome. Some specific questions: If that path was followed, would it need a setting to turn it on/off? I'd argue there is no reason why one would ever want to generate config for an IP which is not bound to the host (Apache wouldn't even start with that), but there may be special cases I'm not aware of. Can anyone confirm (or deny) whether hostname --all-ip-addresses works on his platform? It works on Ubuntu, Debian and Centos, what about Gentoo?
  2. After having read some of the cronjob code, it looks like this feature would require touching almost all of the code in /scripts/. Since this is a good opportunity for a general cleanup in this area, how do you think about using an object-relational mapper for database access? IMHO (but I'm probably biased, as a long-time Python/Django dev) this could help to make the code smaller and more readable, also (with a good ORM) we become independent from the database (Froxlor on sqlite, finally!) and get stuff like migrations (DB structure upgrades) for free. If used properly, this can also be helpful for a future API, as it is possible in many cases to map objects to a REST API without much effort. So, whats the general opinion on this?
  3. I'm not sure why this would be necessary? Domains are linked to node(s) through ipandport, which would also link customer to node(s). Resellers can already be limited to IP, so they could be limited to node, too (by assigning appropriate IP).
  4. Hello Froxies, trying to take another stab at this long-standing issue. I'll first define what "multi-server" means (in my opinion), why one might want it, then discuss how it could be implemented. The purpose of this post is to achieve a consensus, so I can build a patch and get it accepted - I need that stuff, so I'm going to build it. Definition of multi-server / cluster setup A multi-server setup is any setup in which two or more physical or virtual machines (henceforth called "node") are used together to provide the hosting services (e.g. Web/FTP/Mail/...). Possible scenarios include: using dedicated/separate nodes for mail or database distributing customers onto multiple nodes running froxlor itself on a dedicated node (so customer services won't interfere with it) serving a domain from multiple nodes (high-availability / load distribution) Possible use-cases There are several reasons why one would want to split services across multiple nodes: Scaling Obviously, if you have too many customers / services for a single server, you need additional nodes. Installing discrete (unconnected) Froxlor instances on every server is (sometimes) an option, but hardly desirable. Or maybe you want to move a customer who needs more resources to a dedicated host, without changing a lot of configs in a lot of places. Having Froxlor in a central instance makes this possible. Robustness / Availability If you let customer run their own scripts, some scripts will misbehave. With the default Froxlor installation (one server which has the Froxlor DB, the customer DBs and everything else), one misbehaving script or query can bring the whole server down (by overloading it), including panel, mail and everything. Only advantage of this is, angry emails from customers won't bother you, as you won't be getting them anyway. In any other case, it is in many cases highly desirable to have separate nodes for certain services, especially mail and database. Flexibility Different nodes can have different configurations, for example some nodes might run older php versions to support legacy services, whereas others run the latest version. Or some customer needs a special configuration, additional packages, whatever. Example scenarios Separate dabase servers for customers and Froxlor This is actually already addressed in pull request #237 Froxlor & central services (mail, ftp) running on separate node Froxlor is running on the management node, whereas customer domains run on app node(s). Dedicated nodes for some customers This is actually not very different from #2, just with one customer per node Load balancing with multiple app servers for one domain This means that two or more nodes actually have the same configuration, just with different IPs. We can either add two A-records for these IPs in the DNS, or we can put a balancer in front (configuring the balancer itself is out of the scope of this document). Of course, in this case we must make sure that the customer directory is the same for all nodes. This can be achieved either by using a distributed file system, or by mounting the customer directory over NFS (see pull request #236). Implementation The main idea of the proposed implementation is that we split Froxlor into two parts: The panel itself (which runs on the central management node) An agent which runs on the applications nodes, and creates the necessary configuration Thankfully, this is already the case with current Froxlor, as we have already the panel (running as CGI with Froxlor user) and the cron job, which runs as root. Furthermore, we need to have the same users and groups on every node, which can be achieved by configuring libnss-mysql to connect to the central Froxlor database?. The only thing we need to add is some way to tell the local agents/cronjobs what to do, and (equally important) what not to do. For this, I would add the following: A new table panel_nodes which contains a list of the nodes we have in our cluster. A new table panel_node_tasks which contains the tasks (e.g. webserver config, mailserver config, traffic, ...) which should be executed on a given node A new foreign key node in panel_ipandports - with this, the webserver task can find out whether to generate config for a given domain (config is only generated for domains which have an ipandport matching the node) a command line switch --for-host which tells the froxlor_master_cronjob.php which host it is running on. Possible improvements (in later stage) At the moment, each node would require a live connection to the central Froxlor database. This could be solved by having an API which agents could call, but this does not help much as long as we need it for libnss-mysql anyway. Use eventing instead of polling (don't run agent over cron, but trigger it when necessary): Triggering could be done via ssh, or by making the agent listen on a network socket (there was a solution for this once in Froxlor, but it got removed) Relevant forum posts http://forum.froxlor.org/index.php/topic/1661-centralized-froxlor-setup-with-multiple-server-nodes/ http://forum.froxlor.org/index.php/topic/1561-mehrere-server-verwalten/ http://forum.froxlor.org/index.php/topic/11844-clustercloudgalera-support/ Notes We can get rid of this connection if the libnss-extrausers patch is integrated in Froxlor, but that's a different topicAny comments are welcome.
  5. chrisv

    Release 0.9.29

    Nice to see continuous progress on this project, and thanks d00p for all the work! One point, however: 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...
  6. 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: create the domain(s) as usual in Froxlor create the virtualenv(s) as usual somewhere on the filesystem put the python project folder(s) also somewhere on the filesystem (for security reasons, this should be outside of the document root) create a .wsgi file as described in WSGI docs 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/) 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). 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?
  7. 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
  8. 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...