PHP open_basedir Field Limit?

Discussion in 'Installation/Configuration' started by GoremanX, Nov 3, 2010.

  1. GoremanX

    GoremanX New Member

    There appears to be a 256 character limit for the open_basedir field in ISPConfig 3.0.3. This is pretty aggravating if a web site domain name gets on the long side, especially when creating a separate web site on a different sub-domain (ie. subsite1.longwebsitename.com). It makes it impossible to add any directories using the ISPConfig interface.

    I assume this is a database field limit? Can this be changed in future releases?

    Why is there a /srv/www/blablabla pre-filled in this field on a Ubuntu system? I thought /srv/www/ was for SUSE-based systems (among others). Can I remove that entry to make room?
     
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    No, the database field is limited to 64 000 chars in ispconfig 3.0.3

    The limit is just the input field in the browser, you can change it by removing the

    maxlength="255"

    in the web_domain_advanced.htm file for that field.
     
  3. GoremanX

    GoremanX New Member

    woohoo! Thanks!
     
  4. cbj4074

    cbj4074 Member

    Out of curiosity, why is this limit imposed at the HTML level in the first place? My open_basedir values routinely exceed 255 characters.

    My preference would be that this field is a <textarea></textarea> instead of an <input />.

    I realize that I could modify the markup in the template and remove the limit, but wouldn't the file be overwritten with each ISPConfig update?

    I just don't see the usefulness of imposing a length limit (especially one as small as 255 characters) here.
     
  5. GoremanX

    GoremanX New Member

    I agree completely with that statement. A textarea with no limit would be much better.
     
  6. cbj4074

    cbj4074 Member

    Frankly, I would prefer that this field be removed from the interface entirely.

    Why? Because when using a PHP mode that makes use of this field, the paths that are pasted into the field cannot be modified by placing something like the following in the "Custom php.ini settings" box:

    Code:
    open_basedir = "/var/www/example.com/tmp:/var/www/example.com/web"
    
    If I try to do this, the values in the "PHP open_basedir" field take precedence over those appended to /var/www/conf/webX/php.ini. Is this because the open_basedir directive is passed as a command-line argument when starting the PHP executable in (Fast-)CGI mode, and cannot be overridden?

    Then I thought, "Well, then I'll just leave that field blank and enter my open_basedir directives in the 'Custom php.ini settings' box".

    As it turns-out, the "PHP open_basedir" field cannot be left blank. At some point in the past, I recall ISPConfig throwing an error when the field was left blank, but now it appears that the field is repopulated with the defaults when left blank.

    So, short of editing the HTML templates, there's no easy way for me to define lengthy open_basedir values on a per-vhost basis.

    It would be nice if I could just paste custom php.ini directives (including open_basedir) into the "Custom php.ini settings" box each time I create a new site. I find it less than ideal to have to handle open_basedir values separately from all other php.ini customizations, especially in consideration of the 255-character limit. Why is open_basedir treated differently than other PHP configuration directives?

    Just some food for thought...
     
  7. till

    till Super Moderator Staff Member ISPConfig Developer

    Which ISPConfig version do you use? There is no 255 char limit in ISPConfig 3.0.4.1, you can enter 65k chars.
     
  8. cbj4074

    cbj4074 Member

    I do use 3.0.4.1, and didn't realize that the limit had been removed. My thanks to you and the rest of the team for fixing that.

    Do you have any additional thoughts regarding my most recent post? Am I missing something, or is my concern well-founded?

    I hope I don't seem ungrateful :) I'm grateful for ISPConfig and all the hard work that's gone into it. (Hopefully, this is evidenced by the time and energy I've put into my posts on this forum.)

    Thanks, Till!
     
  9. till

    till Super Moderator Staff Member ISPConfig Developer

    You mean to remove the open_basedir field? I dont see this as an option for the following reasons:

    1) The php.ini field works only for some php methods, not all. E.g. it does not work for mod_php.
    2) ISPConfig would have to parse any input in the php.ini field to modify settings e.g. when a website is renamed. This is much more error prone then using a separate field.
    3) If you want to disable open_basedir, then enter / in the feild and dont leave it blank.
     
  10. cbj4074

    cbj4074 Member

    Yes.

    For Mod-PHP, couldn't we just use the "Apache Directives" box with something like

    Code:
    php_value open_basedir "/var/www/example.com/web"
    
    thus rendering the "PHP open_basedir" field unnecessary? I realize that this puts the onus on the system administrator to enter all of the paths required for ISPConfig to function out-of-the-box, which is why I propose a different approach in my next point.

    It bears mention that with Mod-PHP, open_basedir paths from parent directories seem not to be inherited automatically: http://www.howtoforge.com/forums/showthread.php?t=55405

    That said, I'm not sure if open_basedir definitions are inherited properly with other PHP modes, either.

    I see your point here. But why not add the "default" ISPConfig open_basedir directories to the configuration elsewhere, e.g., in the auto-generated .vhost file?

    (Of course, this would not be a practical alternative if I am correct in that open_basedir inheritance is broken in Apache and/or PHP.)

    That is a useful tip, thank you. But I don't want to disable it; I just don't want it managed in the "PHP open_basedir" field.
     
  11. till

    till Super Moderator Staff Member ISPConfig Developer

    Yes, thats the normal behaviour of PHP. Thats why you define the open basedir defaults in ISPConfig under System > Server config so that ispconfig can add them automatically to the open basedir fields in the websites.

    Each php method requires a different place for the open_basedir settings, e.g. only mod_php can read them from the vhost file while they get passed as parameter to the php interpreter for fastcgi.

    It is not intended to create a custom php.ini if no other settings are required as a custom php.ini has always the drawback that changes in the main.php ini will get ignored. php does not support it to include additional configuration files from a custom directory, so the custom ini has to be a copy of the main php.ini from the time where you did the last modification in the php.ini field plus the changes that were set there.

    As you can not enherit php settings, you will have to add all default paths to your custom settings as well and as the default paths conatin the domain name, you will break your setup if you rename the domain name.

    I understand that you like this to be handled in a different way on your server but this would cause a huge drawback for the majority of users which are not even aware of the different options for open_basedir and the php modes.
     
  12. cbj4074

    cbj4074 Member

    To elaborate as to why setting the "PHP open_basedir" field value to "/" as a stop-gap solution in not an option for me:

    Code:
    [Thu Dec 15 10:23:07 2011] [warn] [client XXX.XXX.XXX.XXX] mod_fcgid: stderr: PHP Warning:  curl_setopt(): CURLOPT_FOLLOWLOCATION cannot be activated when in safe_mode or an open_basedir is set
    
    A Joomla feed component triggers this warning, and the feed content cannot be fetched. Obviously, the problem is that open_basedir is still defined, even though it's set to allow all directories.

    Is that really the normal behavior of PHP when using Mod-PHP? If so, why might the PHP manual state:

    Isn't the implication that one should be able to define a set of "default" base paths for, say, the /var/www directory, and also define additional site-specific paths for /var/www/example.com/web? Or am I reading that incorrectly and the implication is that open_basedir values are "inherited" but cannot be modified?

    It seems that this is one of the more confusing aspects of ISPConfig for new users. I love that ISPConfig supports all of the different PHP modes, but it may be worth noting next to the "PHP open_basedir" field, "Applies to CGI and Fast-CGI PHP modes only". I think this would reduce the number of "Help me!" threads.

    I didn't realize that PHP does not support inheritance for directives defined in *.ini configuration files. Thank you for the clarification.

    For those seeking confirmation of this claim, look to https://bugs.php.net/bug.php?id=44526&edit=1 :

    This is one more reason to use Mod-PHP over the other PHP modes; PHP configuration directives can be overridden using php_[admin_][value|flag] = ....

    This comment in the PHP manual addresses this subject at length, too: http://us2.php.net/manual/en/configuration.changes.php#88816

    This makes sense. Given your explanation, the current interface seems to be the best implementation.

    That said, it couldn't hurt to add a note next to the "PHP open_basedir" field, as described above. (I realize that ISPConfig supports itself via Manual sales, so if this info is already in the Manual and was omitted from the interface intentionally, that seems sufficient.)
     
    Last edited: Dec 15, 2011
  13. till

    till Super Moderator Staff Member ISPConfig Developer

    I havent seen this behaviour yet on a server. Maybe its too ew and the functionality is not available yet in the apache and php versions delivered by the linux distributions.

    The php modes and which option is available for which mode is described in the manual. But we can add a info text in the interface too.

    The major drawback that I see with mod_php is security and thats why I dont use it anymore on my systems. With php-fcgi + suexec php, scripts are running fast and under the user and group of the website. I'am aware of the itk patch for apache that spawns a apache instance for every vhost, but thats quite heavy and uses a lot of resources. So its only a option for servers with only a small number of sites in my opinion.

    My wishlist for php would be :)

    1) config variable inheritance.
    2) A include statement that can be used inside the config fils to include other comnfig snippets.
    3) A php_[admin_][value|flag] = statement that makes it possible to set a separate php.ini for each vhost for mod_php

    These three options would make it much esaier to build custom php cnfigurations that are better maintainable.

    I like to thank you for your help here in the forum!
     
  14. cbj4074

    cbj4074 Member

    You're right; it doesn't exist :). I posted an update to one of my other threads to explain the behavior. http://www.howtoforge.com/forums/showthread.php?p=269789

    That would be most appreciated.

    Ahh, that's right... Mod-PHP is not the only option for implementing vhost-specific Apache configurations. Fast-CGI + SuPHP Apache module allows one to take advantage of vhost-specific Apache configurations and improve security at the same time.

    Thank you for your willingness to discuss and for the valuable insights!
     
    Last edited: Dec 19, 2011

Share This Page