Go Back   HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials > ISPConfig 3 > Developers' Forum

Do you like HowtoForge? Please consider supporting us by becoming a subscriber.
Reply
 
Thread Tools Display Modes
  #11  
Old 31st August 2010, 12:55
ispcomm ispcomm is offline
Senior Member
 
Join Date: Aug 2010
Posts: 166
Thanks: 19
Thanked 11 Times in 11 Posts
Default

Quote:
Originally Posted by till View Post
This might be the case, even if it is not a bug as it matches the current ispconfig implementation of paths. But it might have to be extended then if other path identifiers are available in future.
Perhaps this can be broken by using a different setting in the server configuration? I'll have a look at how the URL is constructed so that I can change it to be read from the db and this will fix it once for all.

Quote:
Please be aware that there is on "real" path and one symlink (for easier shell navigation for the admin). On current setups, /var/www/domain.com is a symlink and /var/www/clients/client1/web1/ is the real path which uses ID's to ensure that it never changes on a domain name update, otherwise it would break cms systems and scripts that are installed in the website.
Yes, found the real dir+(dual) links.

The way it's done, the paths will stay the same even if the domain is renamed. But any CMS will have a setting for the base_dir (if not calculated automtically). It should not be a big issue (my guess).

ispcomm.
Reply With Quote
Sponsored Links
  #12  
Old 31st August 2010, 13:00
till till is offline
Super Moderator
 
Join Date: Apr 2005
Location: Lüneburg, Germany
Posts: 35,478
Thanks: 813
Thanked 5,255 Times in 4,121 Posts
Default

Quote:
Perhaps this can be broken by using a different setting in the server configuration? I'll have a look at how the URL is constructed so that I can change it to be read from the db and this will fix it once for all.
I guess we will have to add a database field for the www_path then in the website database table that we will with the correct path when the website is inserted or updated like we do it now for the real path.

Quote:
The way it's done, the paths will stay the same even if the domain is renamed. But any CMS will have a setting for the base_dir (if not calculated automtically). It should not be a big issue (my guess).
It would be great if all cms systems and custom scripts would do that, but I've seen a lot of scripts breaking when you e.g. rename a website from test.domain.com to domain.com when it gets switched to live mode. So if you like to kep such problems away from your support team, I can only recommed to stay with the IP approach and only modify the symlink part.
__________________
Till Brehm
--
Get ISPConfig support and the ISPConfig 3 manual from ispconfig.org.
Reply With Quote
  #13  
Old 31st August 2010, 14:00
ispcomm ispcomm is offline
Senior Member
 
Join Date: Aug 2010
Posts: 166
Thanks: 19
Thanked 11 Times in 11 Posts
Default

Quote:
Originally Posted by till View Post
I guess we will have to add a database field for the www_path then in the website database table that we will with the correct path when the website is inserted or updated like we do it now for the real path.
I agree. Please do so in trunk as I'm still a bit confused as to where to find things (and I can easily break them).

Meanwhile, I'm installing the debugger on my test setup so I can step trough code more easily. I hope to be up to speed in a few hours.

Quote:
It would be great if all cms systems and custom scripts would do that, but I've seen a lot of scripts breaking when you e.g. rename a website from test.domain.com to domain.com when it gets switched to live mode. So if you like to kep such problems away from your support team, I can only recommed to stay with the IP approach and only modify the symlink part.
I have to agree with you that CMS are usually not well written and a source of continuous headaches. client_id/web_id/ stays the same, and as long as the web server is instructed to not-follow symlinks should be fine. It makes it harder at the beginning to find the correct path and to move sites between clusters.

But whatever reasoning there's behind the path, I'll try to fix my patch so it works.

ispcomm
Reply With Quote
  #14  
Old 31st August 2010, 14:09
till till is offline
Super Moderator
 
Join Date: Apr 2005
Location: Lüneburg, Germany
Posts: 35,478
Thanks: 813
Thanked 5,255 Times in 4,121 Posts
Default

Quote:
I agree. Please do so in trunk as I'm still a bit confused as to where to find things (and I can easily break them).
I will add the field.

Quote:
It makes it harder at the beginning to find the correct path and to move sites between clusters.
Thats depends on how you plan your cluster. ISPConfig is able to manage several clusters of replicated servers from one controlpanel and as long as you use the same master ispconfig controlpanel instance for all clusters, then the ID's are unique.
__________________
Till Brehm
--
Get ISPConfig support and the ISPConfig 3 manual from ispconfig.org.
Reply With Quote
  #15  
Old 31st August 2010, 14:29
ispcomm ispcomm is offline
Senior Member
 
Join Date: Aug 2010
Posts: 166
Thanks: 19
Thanked 11 Times in 11 Posts
Default

I saw your change in SVN. One question is in order: Isn't it more efficient to point the site to the real directory instead of the symlink ? A symlink means an extra access for every object on the web root.

ispcomm
Reply With Quote
  #16  
Old 31st August 2010, 14:42
till till is offline
Super Moderator
 
Join Date: Apr 2005
Location: Lüneburg, Germany
Posts: 35,478
Thanks: 813
Thanked 5,255 Times in 4,121 Posts
Default

The site points in almost all cases to the real directory. Only some special cases (combinations of php modes with suexec etc) made it nescessary to point the site to the symlink. If you switch the php modes, you will see that in the vhost file.

The problem is as follows: On older ispconfig releases, the clients directory was not inside the /var/www directory, it was /var/clients and not /var/www/clients as it is now. For security reasons, I would have preferred if we could have used /var/clients till now but some apache modules had problems with that. So we had to introduce the switching between the symlink and the real directory depending on the apache modules used in a specific vhost. Since we moved the clients directory to /var/www now to circumvent these problems, we would be able to always use the real path. But there are a few ten thousand install which use the old path layout and we can not break them.
__________________
Till Brehm
--
Get ISPConfig support and the ISPConfig 3 manual from ispconfig.org.
Reply With Quote
  #17  
Old 31st August 2010, 17:41
ispcomm ispcomm is offline
Senior Member
 
Join Date: Aug 2010
Posts: 166
Thanks: 19
Thanked 11 Times in 11 Posts
Default

Till, I got your point. I too have several constraints for not breaking sites, some of which are over 10 years old (ouch). I remember having to recompile some of the suid php interpreters (perhaps it was suphp or was it cgi?) debian packages to allow for sites out of /var/www.

I installed a second copy of ispconfig with xdebug+eclipse and I get to understand a little better the process.

It seems that document_root_www is used for some cgi interpreters (fastcgi for example) while document_root is used for the others (plain cgi).

With my patch, apache vhost is created in the split path (/var/www/sites/a/ab etc) while symlinks stay as default (/var/www/clients/client1/web2 etc).

FastCGI uses DocumentRoot with a symlink /var/www/testsite3.com/web
CGI uses the real directory. I havent tested others.

Renaming a site the way I proposed, would mean moving the directory from the old "attach point" to the new one, which means a little change i server.php is also due (should be easy).

A problem would be not breaking the old installs. Perhaps it would suffice to create the symlinks they expect to the real directory. An "fopen" from an old site would open the file trough the symlink. php_open_basedir would have this symlink in the path.

so old sites would work untouched, while new ones could start with the full path.

There's a problem in onAfterUpdate: the $document_root is calculated correctly (and I added my patch) but it's never written to the database, so server.php cannot do anything about it. Incidentally, the new site name is placed in the log file.

I can modify onAfterUpdate to update the site with the new path. However, since there's no place to record the old path it will be impossible for server.php to know which site to move around.

Any idea about a solution? (other than disabling site renaming after it's created) ?

ispcomm.
Reply With Quote
  #18  
Old 31st August 2010, 19:11
till till is offline
Super Moderator
 
Join Date: Apr 2005
Location: Lüneburg, Germany
Posts: 35,478
Thanks: 813
Thanked 5,255 Times in 4,121 Posts
Default

Quote:
I can modify onAfterUpdate to update the site with the new path. However, since there's no place to record the old path it will be impossible for server.php to know which site to move around.
Thats not the case, the plugin always "knows" the old and new path as ISPConfig has its own event based system that tracke the changes (see serialized objects sys_datalog), every event function in the plugins receive a $data array which contains the old and new values. Everything that is changed in the database onAfterUpdate event is part of the current transaction. So you can safely change the path in that event in the interface and the plugin gets automatically the old and new path values. This way all moving opertions, e.g. for maildirs in the email module, are implemented.

Regarding the overall changes you proposed, I fear this will break to many setups as not everything will work trough a symlink so we can not implement this as new default. The solution I would propose is that we add some kind of layout selector in the server settings to keep the current layout as default and allow the new scheme as option plus maybe other schemes later.

The problem with the layout is that some apache modules and settings are really picky and even a small change makes specific combinations to fail. It tooks several months and a lot of patch releases to get this all to a stable point where all combinations work and we can not risk this without a easy option to switch back. So a selector might be the best solution. levae the current setup as it is and implement a new layout beside the current setup in the apache plugin.

Quote:
Renaming a site the way I proposed, would mean moving the directory from the old "attach point" to the new one, which means a little change i server.php is also due (should be easy).
Just as a side note, please do not change server.php. ISPConfig is event and plugin based, so always do changes in the plugins only as a change in the main script which only contains the process management and plugin loading code shall not be nescessary
__________________
Till Brehm
--
Get ISPConfig support and the ISPConfig 3 manual from ispconfig.org.
Reply With Quote
  #19  
Old 31st August 2010, 19:37
ispcomm ispcomm is offline
Senior Member
 
Join Date: Aug 2010
Posts: 166
Thanks: 19
Thanked 11 Times in 11 Posts
Default

Till,

We're missing something (and I don't want to break things). The new structure would be in effect only if someone changes the web server config paths.

If the web server setting never uses website_domain_x there will be no change accross the whole setup, so in reality there is no real problem.

Also, if the symlink and the web_dir lead to the same "path" the symlink call will silently fail (I hope so) and there will be no difference between the various CGI/FastCGI/SuPHP etc modules.

I'll need to read a little more the code to understand the plugin/events structure. Is there any doc/thread where something is explained?

If it's the frontend to change things and it's server.php to do the changes, what is the glue? Server.php is called from a server.sh, but where's the state retrieved from?

sorry for so much questions.... I hope I can be usefull once I understand how things are layed down.

ispcomm.
Reply With Quote
  #20  
Old 31st August 2010, 19:47
till till is offline
Super Moderator
 
Join Date: Apr 2005
Location: Lüneburg, Germany
Posts: 35,478
Thanks: 813
Thanked 5,255 Times in 4,121 Posts
 
Default

Quote:
If the web server setting never uses website_domain_x there will be no change accross the whole setup, so in reality there is no real problem.
This would only be the case if no changes in the server path are nescessary, but as we will have to add a field already for the www path, we start to change the current system layout. But we will see.

Quote:
I'll need to read a little more the code to understand the plugin/events structure. Is there any doc/thread where something is explained?
There is no docs beside the info here in the dev forum.

Quote:
If it's the frontend to change things and it's server.php to do the changes, what is the glue? Server.php is called from a server.sh, but where's the state retrieved from?
server.php is executed once a minute, if there are pending changes to be processed, then it the loads the module and plugin framework which then load all plugins in alphabetical order and attaches them to the event listeners. Then it loads all record changes from the sys_datalog, processes them and calls the event based functions in the plugins. Every even based function recieves the old and new state of the record, so the function uses only the values form that array and never read directly from the database as this would break the atomicity of the actions.
__________________
Till Brehm
--
Get ISPConfig support and the ISPConfig 3 manual from ispconfig.org.
Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
I'm attack brute force qb7 General 6 21st July 2012 21:34
Change domain of existing web? wpwood3 Installation/Configuration 3 11th November 2008 20:03
change web-ownership to different customer? brengo General 2 18th March 2007 15:58
Mail using postfix receive but cannot send garfabian Installation/Configuration 17 2nd September 2006 13:55


All times are GMT +2. The time now is 01:38.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.