ispconfig 2.2.21 and roundcubemail

Discussion in 'Installation/Configuration' started by daveb, Apr 5, 2008.

  1. daveb

    daveb Member

    @hans yea the old suphp.conf date appended
    Code:
    [handlers]
    ;Handler for php-scripts
    x-httpd-php=php:/usr/bin/php5-cgi
    
    ;Handler for CGI-scripts
    x-suphp-cgi=execute:!self
    vs new suphp.conf
    Code:
    [handlers]
    ;Handler for php-scripts
    x-httpd-php=php:/home/admispconfig/ispconfig/tools/suphp/usr/bin/php-wrapper
    
    ;Handler for CGI-scripts
    x-suphp-cgi=execute:!self
    What does your suphp.conf use for the handler

    @toolish I also believe ${DOCUMENT_ROOT} is an Apache environment variable, set in Vhosts_ispconfig.conf But I dont believe you could change that for just one webs vhost using ispconfig without significant code rewriting.
     
  2. toolish

    toolish ISPConfig Developer ISPConfig Developer

    Quick fix in the meantime if you don't mind altering php-wrapper.

    So in /home/admispconfig/ispconfig/tools/suphp/usr/bin/php-wrapper
    change it to look like this
    Code:
    #!/bin/sh
    PATH="/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/libexec"
    
    BASEDIR=`dirname ${DOCUMENT_ROOT}`
    TMPDIR=${BASEDIR}/phptmp
    SESSDIR=${TMPDIR}
    
    if [ X"${php_safe_mode}" != X"On" ]; then
    SAFE_MODE="Off"
    else
    SAFE_MODE="On"
    fi
    
    if [ X"${php_custom_ini}" = X"On" ]; then
    exec php-cgi -d upload_tmp_dir=${TMPDIR} -d session.save_path=${SESSDIR} -d safe_mode=${SAFE_MODE}
    else
    exec php-cgi -d open_basedir=${BASEDIR} -d upload_tmp_dir=${TMPDIR} -d session.save_path=${SESSDIR} -d safe_mode=${SAFE_MODE}
    fi
    Then in the ISPConfig control panel add this to the custom apache directives.
    Code:
    SetEnv php_custom_ini On
    suPHP_ConfigPath /var/www/webX/path/to/php.ini
    
    In the php.ini referred to add the line
    Code:
    open_basedir = /var/www/webX:/etc/postfix/
    Now any web that you add this to will be able to have a custom open_basedir set in it own php.ini, and the php-wrapper will still add the standard open_basedir value for none custom php.ini webs.

    Edit: Quick warning the custom php.ini should be below the web root and be owned by root, and only readable by the webs owner so 644 should be ok.
     
    Last edited: Apr 9, 2008
  3. Hans

    Hans Moderator ISPConfig Developer

    @Daveb,

    I have the following lines within /etc/suphp.conf:

    [handlers]
    ;Handler for php-scripts
    x-httpd-php=php:/home/admispconfig/ispconfig/tools/suphp/usr/bin/php-wrapper

    ;Handler for CGI-scripts
    x-suphp-cgi=execute:!self
     
  4. daveb

    daveb Member

    That works but still something is weird. Let me explain, before I noticed anything ever changed prior to 2.2.20 I could log into rcmail with [email protected]. now after the wrapper change as above and updating rcmail to stable branchs. I can no longer login with [email protected] except for 1 user, the others I always receive a failed login attempt. but I can login with web#_user with no problems.
     
  5. toolish

    toolish ISPConfig Developer ISPConfig Developer

    That sounds like it could be to do with email aliases and the Roundcube auto_create_user function. I noticed that if I had set up some aliases of an email address in ISPConfig that Roundcube would'nt necessarily pick up the main email address.
    I guess its because it will just use the first alias it finds in virtusertable and then adds that to the Roundcube database.
    If you take a look in the Roundcube database and browse the user table it could be that the one email address that was working was one that had the main email address in the alias column.
    I noticed I could login using an email address whilst having the open_basedir problems if the alias was correct and in the database already.
     
  6. Hans

    Hans Moderator ISPConfig Developer

    If that's true try to change the following line within your RC config/main.inc.php configuration file from:

    $rcmail_config['auto_create_user'] = TRUE;

    into:

    $rcmail_config['auto_create_user'] = FALSE;
     
  7. daveb

    daveb Member

    @toolish if I cp virtusertable back to /var/www/web#/virtusertable and set RC config/main.inc.php to read from their I can login with [email protected] and web#_user for all users I can test but if set to read from /etc/postfix/virtusertable I can only login via web#_user for just about every user I can test except 1 [email protected]. So even with the open_basedir fix you posted I am personally still having a weird problem I would like to resolve.
     
  8. toolish

    toolish ISPConfig Developer ISPConfig Developer

    Can you verify that your open_basedir values have changed when you are using the fix?
    Make a file called anything.php in the web root and add this code (you may already know this but just incase):
    Code:
    <?php
    phpinfo()
    ?>
    Point your browser to the file.
    You should see the open_basedir values in the first table headed PHP Core.
    also worth a look is the Environment Variables right down at the bottom, have a check that PHPRC is set to the path of the custom php.ini created in the fix.
     
  9. daveb

    daveb Member

    heres relevant php info
    Code:
    Configuration File (php.ini) Path 	/var/www/web#/php.ini 
    Code:
    open_basedir	/var/www/web#:/etc/postfix	/var/www/web#:/etc/postfix
    Code:
    _SERVER["PHPRC"]	/var/www/web#/php.ini
    Code:
    _ENV["PHPRC"]	/var/www/web#/php.ini
    Your fix works great for a individual php.ini for webs and as far as being able to get contents of virtusertable from /etc/postfix/virtusertable but like I said and you also noted that their is a problem with [email protected] vs. web#_user logins. What I have tested is if I cp virtusertable to the say /var/www/web#/virtusertable and make change to rcmail config to reflect the change and without changeing anything else just coping the file their all the users that I couldnt login with [email protected] I now can login with no problems but if I change config to read from /etc/postfix/virtusertable I again cannot login with [email protected] but have to use web#_user.
     
  10. toolish

    toolish ISPConfig Developer ISPConfig Developer

    The only problem I was having was not being able to login using any email address, giving the same PHP Warning you gave in your first post. The fix above sorted that for me so that I can now login with any valid email address.
    Are you still getting the same PHP Warning?
    Your setup looks like it should be correct from your info. The only difference I can see is that you don't have a trailing slash after /etc/postfix, in mine I have it as /etc/postfix/.
    I'm confused though, you say that you can get the contents of the virtusertable from /etc/postfix/ but are still unable to login using email, is that correct?
    One other thing to check, is magic_quotes_gpc set to off in your phpinfo?

    Sidenote: Regarding the custom php.ini it is possible to have a custom php.ini for most/any of the rest of the PHP settings, its only open_basedir that can only be set once, which is why the change to php-wrapper is necessary in this case. You can just add a suPHP_ConfigPath directive and it will work for other settings.
     
  11. daveb

    daveb Member

    I had the trailing / but removed it during the testing but either way still no change. magic_quotes_gpc is set to off. Regarding the custom php.ini I was using them already for a few webs I was mainly referring to your fix for the php wrapper.
    if I am parsing /etc/postfix/virtusertable and try to login with a email addy I get this in log.
    Code:
    [10-Apr-2008 03:34:28 -0500] IMAP Error: Authentication for [email protected] failed (LOGIN): "a001 NO Login failed." in  on line 0
    but if I am parsing /var/www/web#/virtusertable and try to login with a email addy I Login with no errors. So I seem to still have a issue.
     
  12. toolish

    toolish ISPConfig Developer ISPConfig Developer

    I'm fairly stumped at this stage daveb, the only way I can get the same error as you is if I put a typo in the email address, the error seems to be coming from the IMAP server.
    It would be worth taking a look in your mail.log and just seeing if the email address is looking right in there for the failed logins.
    Its also worth browsing the database with phpmyadmin and having a look at the user table to see if anything looks strange in there.
    All I can suggest really is to try and do a clean install of Roundcube, I will keep trying though to see if I can recreate your problem.
     
  13. daveb

    daveb Member

    @toolish your stumped haha I am very stumped cause this worked for many months before. I am just glade I have this site to throw my problems around :D
    I dont understand whats going on I dont have any errors in any logs except for failed login, apache logs for site, mod security logs, mail logs ect..

    Like I said if I copy and set config to /var/www/web#/virtusertable works like a charm. I notice it converts the [email protected] to web#_user and logs in and everything is great.
    mail.log
    Code:
    Apr 11 11:28:33 srv01 imapd: Connection, ip=[::ffff:127.0.0.1]
    Apr 11 11:28:33 srv01 imapd: LOGIN, user=web#_user, ip=[::ffff:127.0.0.1], protocol=IMAP
    Apr 11 11:28:33 srv01 imapd: LOGOUT, user=web#_user, ip=[::ffff:127.0.0.1], headers=0, body=0, rcvd=25, sent=180, time=0
    Apr 11 11:28:34 srv01 imapd: Connection, ip=[::ffff:127.0.0.1]
    Apr 11 11:28:34 srv01 imapd: LOGIN, user=web#_user, ip=[::ffff:127.0.0.1], protocol=IMAP
    Apr 11 11:28:34 srv01 imapd: LOGOUT, user=web#_user, ip=[::ffff:127.0.0.1], headers=0, body=0, rcvd=97, sent=697, time=0
    Apr 11 11:28:36 srv01 imapd: Connection, ip=[::ffff:127.0.0.1]
    Apr 11 11:28:36 srv01 imapd: LOGIN, user=web#_user, ip=[::ffff:127.0.0.1], protocol=IMAP
    Apr 11 11:28:36 srv01 imapd: LOGOUT, user=web#_user, ip=[::ffff:127.0.0.1], headers=0, body=0, rcvd=301, sent=1799, time=0
    Apr 11 11:29:36 srv01 imapd: Connection, ip=[::ffff:127.0.0.1]
    Apr 11 11:29:36 srv01 imapd: LOGIN, user=web#_user, ip=[::ffff:127.0.0.1], protocol=IMAP
    Apr 11 11:29:36 srv01 imapd: LOGOUT, user=web#_user, ip=[::ffff:127.0.0.1], headers=0, body=0, rcvd=176, sent=1634,
    And even with the fix for open_basedir for this web If I set config to original /etc/postfix/virtusertable only web#_user user names are allowed for all but 1 account.
    mail.log
    Code:
    Apr 11 11:27:33 srv01 imapd: Connection, ip=[::ffff:127.0.0.1]
    Apr 11 11:27:33 srv01 imapd: LOGIN FAILED, [email protected], ip=[::ffff:127.0.0.1]
    Apr 11 11:27:38 srv01 imapd: Disconnected, ip=[::ffff:127.0.0.1], time=5
    Apr 11 11:27:47 srv01 imapd: Connection, ip=[::ffff:127.0.0.1]
    Apr 11 11:27:47 srv01 imapd: LOGIN FAILED, [email protected], ip=[::ffff:127.0.0.1]
    Apr 11 11:27:52 srv01 imapd: Disconnected, ip=[::ffff:127.0.0.1], time=5
    rcmail error.log
    Code:
    [11-Apr-2008 11:27:38 -0500] IMAP Error: Authentication for [email protected] failed (LOGIN): "a001 NO Login failed." in  on line 0
    [11-Apr-2008 11:27:52 -0500] IMAP Error: Authentication for [email protected] failed (LOGIN): "a001 NO Login failed." in  on line 0
    I am very stumped.
     
  14. daveb

    daveb Member

    ok I have made a change to the php-wrapper and set my config back to /etc/postfix/virtusertable and all seems to be working well again, but only time will actually tell.
    php-wrapper: I removed the -d safe_mode=${SAFE_MODE}
    Code:
    #!/bin/sh
    PATH="/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/libexec"
    
    BASEDIR=`dirname ${DOCUMENT_ROOT}`
    TMPDIR=${BASEDIR}/phptmp
    SESSDIR=${TMPDIR}
    
    if [ X"${php_safe_mode}" != X"On" ]; then
    SAFE_MODE="Off"
    else
    SAFE_MODE="On"
    fi
    
    if [ X"${php_custom_ini}" = X"On" ]; then
    exec php-cgi -d upload_tmp_dir=${TMPDIR} -d session.save_path=${SESSDIR}
    #exec php-cgi -d upload_tmp_dir=${TMPDIR} -d session.save_path=${SESSDIR} -d safe_mode=${SAFE_MODE}
    else
    exec php-cgi -d open_basedir=${BASEDIR} -d upload_tmp_dir=${TMPDIR} -d session.save_path=${SESSDIR} -d safe_mode=${SAFE_MODE}
    fi
    
    #exec php-cgi -d open_basedir=${BASEDIR} -d upload_tmp_dir=${TMPDIR} -d session.save_path=${SESSDIR} -d safe_mode=${SAFE_MODE}
    
    So thanks for all the help guys.
    Dave
     
  15. toolish

    toolish ISPConfig Developer ISPConfig Developer

    Glad you got it sorted daveb, that would explain the difference in our setups.
    I had safe mode disabled in my ISPConfig for that web, maybe you had yours enabled?
    If so you could try disabling it in there rather than globally in the php-wrapper.
    Good to hear its working.
     
  16. Hans

    Hans Moderator ISPConfig Developer

    In the mean time i did some tests and i can confirm that the file /home/admispconfig/ispconfig/tools/suphp/usr/bin/php-wrapper is the reason that the error "PHP Warning: is_file() [<a href='function.is-file'>function.is-file</a>]: open_basedir restriction in effect. File(/etc/postfix/virtusertable) is not within the allowed path(s): (/var/www/web#) in /var/www/web#/web/program/include/main.inc on line 680" occurs.

    I tried RC 0.1.1 also with php5mod instead of php5-cgi+suPHP.
    By using php5mod, there are no problems at all during login sessions.

    Now I consider to use php5mod for RC, because i don't like to change the content of /home/admispconfig/ispconfig/tools/suphp/usr/bin/php-wrapper everytime i need to update ISPConfig.
     
    Last edited: Apr 22, 2008

Share This Page