Customer/Domain concept questions.

[pulponair]

Hi,

 

Yesterday, i came across a blog post describing froxlor that pique my curiosity.

 

I've been using ispcp for some years and it bugs me here and there especially when it comes to integration of

new webserver/PHP SAPI technology other than apache/fastcgi. ISPCP's underlying engine isn't very modular,

actually its just a bunch of Perl Scripts handling things just in a row, which makes customization or integration of new features quite annoying.

But that's another story.

 

Back to topic:

After reading trough froxlor's feature list, clicking around at the demosite and having a look at the git repository i decided to give it a try.

So i got myself a huge coffee, set up a virtual machine (Debian squeeze@virtualBox) and spend the night playing around with it.

These were the things i had on my list to check for (Mainly webserver focused):

 

A. Technical things

1. How are things handled behind the scenes (filesystem organization, system users, configuration files etc).
   
2. Expandability/Codestructure
   
3. Transfer of GUI Operations to "root" operations.
   

 

 

B. Logical/Usability things

1. Underlying Logical Concept (i.e. Customer/Domain)
   
2. Feasibility of common usecases (read common as "common for what i ve seen that far/what i need").
   

 

These are my findings, questions, concerns and questions:

To be upfront with it: I did not tried every single feature. I might have missunderstood some things. Don't feel offended about criticism this is meant to be a constructive feedback post

 

Here we go.

 

A. Technical things

How are things handled behind the scenes

There is one system user per customer. Domains belonging to this customer are placed beyond the customers "home" directory and are beloging to the customer's system user. I guess you guys decided to organized it this way to manage filesystem permissions (e.g. ftp users access to either the full customer root or just single domain directories etc) right?

 

Expandability/Codestructure

There is an modular approach and some kind of "module" registration for the GUI as well as for the "engine" which is by far better than anything else i'v seen from other panels that far. Though there is room for improvement (as always). So i would impute floxlor a good expandability compared to other panels.

 

Floxlor does not use any PHP Framework. Did you concider to use a lightweight framework to ease common things (DB stuff, GUI stuff)?. If so what where the pros/cons?

 

Transfer of GUI Operations to "root" operations.

This is solved by a bunch of cronjobs executed by a master cronjob. That's in general a good and simple approach though it has one major drawback: delay. Expecially during inititial setup, testing and/or debugging you don't want to wait 1 minute before your changes become visible. Did you thought about having a small root privilege php daemon that can be notified instantly to execute certain task/jobs immediatly/on demand (at least for admins)?.

 

 

B. Logical/Usability things

No need to seperate the points from the list here since they interact with each other.

 

This is the current "structure":

• Admins manage Customers and Domains
  
• Customers can have 1 to many domains, databases and ftp users
  
• Customers can have restrictions like bandwith, number of domains etc.
  
• Domains can have restrictions ....
  

 

Some thoughts - random order:

In most cases you won't have a customer without a domain so it would be nice to have it created optional while creating the customer itself.

 

The "create standard subdomain" - thing creates a vhost "cumstomername.hostname" (by default) pointing to the customer's root directory. What for? Wouldn't that lead to fact that you can surf customername.hostname/domain1 and will reach domain one of that particular customer? Is this an intended behavior? What usecase covers this?

 

Domains i.e vhosts of a certain customer point their docroot to the customers home directory. I don't think that makes sense at all (I'v seen there is a patch in redmine). Was this an intended behavior? If so, what for?.

 

Well as you might have assumed from my questions that i either don't understand the hirarchical concept, it has just evolved over time or it covers some special needs i am not aware of .

 

So final questions:

Are there plans to rework/smooth out this concept?

How are priorities regarding new features vs a more solid logical concept?

 

Without to go into the details but:

IMHO something like admins->resellers->customers->domains with some nice level wise restriction/default inheritance would greatly improve consistency and use case coverage.

 

Well that's it that far...

 

Cheers,

Nikolas

[pulponair]

Hi Wolfgang,

That is what feels wrong to me as well. Actually it should be that way:

 

A Customer should be a container for 1-n domains (logically but not necessarily directory wise).

A Domain should have 0-n aliases.

A Domain should have 0-n subdomain.

 

IMHO the whole domain/vhost/customer/directory hierarchy needs some consistence hardening ;>.

 

Cheers,

Nikolas

[arnoldB]

Hey are there still open questions?

[pulponair]

Hello,

 

Well, every phrases of the original post ending with the "?" character ;>.

In fact none of them has been answered yet.

 

Cheers,

Nikolas

[arnoldB]

How are things handled behind the scenes

There is one system user per customer. Domains belonging to this customer are placed beyond the customers "home" directory and are beloging to the customer's system user. I guess you guys decided to organized it this way to manage filesystem permissions (e.g. ftp users access to either the full customer root or just single domain directories etc) right?

 

I'm not sure, but the FTP user should not be a (*nix) system user.

 

 

Expandability/Codestructure

There is an modular approach and some kind of "module" registration for the GUI as well as for the "engine" which is by far better than anything else i'v seen from other panels that far. Though there is room for improvement (as always). So i would impute floxlor a good expandability compared to other panels.

 

Yes, that's one of the advantages of Froxlor

 

 

 

 

Transfer of GUI Operations to "root" operations.

This is solved by a bunch of cronjobs executed by a master cronjob. That's in general a good and simple approach though it has one major drawback: delay. Expecially during inititial setup, testing and/or debugging you don't want to wait 1 minute before your changes become visible. Did you thought about having a small root privilege php daemon that can be notified instantly to execute certain task/jobs immediatly/on demand (at least for admins)?.

 

There was a "realtime function" which executed the operations in realtime, but was removed by Froxlor v0.9.14.

Realtime update-feature has been removed due to problems and possible skipped/unfinished tasks

 

 

 

 

This is the current "structure":

• Admins manage Customers and Domains
  
• Customers can have 1 to many domains, databases and ftp users
  
• Customers can have restrictions like bandwith, number of domains etc.
  
• Domains can have restrictions ....
  

 

The bandwidth restriction function is not onboard.

 

 

 

Some thoughts - random order:

In most cases you won't have a customer without a domain so it would be nice to have it created optional while creating the customer itself.

 

The "create standard subdomain" - thing creates a vhost "cumstomername.hostname" (by default) pointing to the customer's root directory. What for? Wouldn't that lead to fact that you can surf customername.hostname/domain1 and will reach domain one of that particular customer? Is this an intended behavior? What usecase covers this?

 

You did have answered the question

In most cases you won't have a customer without a domain so it would be nice to have it created optional while creating the customer itself.

 

 

 

 

Domains i.e vhosts of a certain customer point their docroot to the customers home directory. I don't think that makes sense at all (I'v seen there is a patch in redmine). Was this an intended behavior? If so, what for?.

 

Why should this make no sense?

 

 

 

IMHO something like admins->resellers->customers->domains with some nice level wise restriction/default inheritance would greatly improve consistency and use case coverage.

 

That's AFAIK reported yet.

 

 

 

-----

 

If I'm not right, feel free to correct me

[woro]

The "create standard subdomain" - thing creates a vhost "cumstomername.hostname" (by default) pointing to the customer's root directory. What for? Wouldn't that lead to fact that you can surf customername.hostname/domain1 and will reach domain one of that particular customer? Is this an intended behavior? What usecase covers this?

 

Domains i.e vhosts of a certain customer point their docroot to the customers home directory. I don't think that makes sense at all (I'v seen there is a patch in redmine). Was this an intended behavior? If so, what for?.

 

I was trying froxlor some time ago already but now trying to start using it in a production environment and came across the same issues.

 

The first is not really a problem and makes it a bit easier to test it as long as DNS is not setup correctly for a new domain. I also don't see a big issue with it but I'm still interested if there are/were other reasons to provide that.

 

The latter is the thing I actually wondered and why I came here to write a post about it before I found that one.

 

There are alias domains and "normal" domains. I'd have expected that froxlor builds up a structure (probably below the customer path) with those domains but connects the alias domain to its main one.

But apparently froxlor treats every domain the same (main issue for me is that apache configs are pointing to the same docroot which just is the customer). I guess it's possible to configure the domains "correctly" but by default everything points to the same data which looks wrong to me given there explicitely exists an option to have alias domains. At the moment every domain of a customer behaves like an alias domain. Or did I miss something?

 

Wolfgang