Results 1 to 4 of 4

Thread: Testing Drupal 6.17 - problem with apache mod_readwrite

Hybrid View

  1. #1

    Default Testing Drupal 6.17 - problem with apache mod_readwrite

    Have both Drupal 6.17 and 7.0-5 up and running on localhost

    Clean URL in drupal is not available on any of them
    Have been reading and reading troubleshooting,
    but obviously overlooking something
    and needs help.

    Environment:
    Linux 2.6.31.12-0.2
    openSUSE 11.2 (x86_64) (KDE 4.3.5)

    Mysql 5.1.36-6.8.8-x86_64

    apache 2.2.13-2.4.1-x86_64 (opensuse)
    apache2-mod_php5
    apache2-prefork
    apache2-utils

    php 5.3.2-1.1.1-x86_64
    register_global = off
    safe_mode = off
    pdo drivers = mysql, sqlite, sqlite2
    session.cache_delimiter = nocache
    session.auto_start = off

    Drupal 6.17 on localhost/drupal617

    In httpd.conf:
    # use .htaccess files for overriding,
    AccessFileName .htaccess
    # and never show them
    <Files ~ "^\.ht">
    Order allow,deny
    Deny from all
    </Files>

    # List of resources to look for when the client requests a directory
    DirectoryIndex index.html index.html.var

    in .htaccess
    # Various rewrite rules.
    <IfModule mod_rewrite.c>
    RewriteEngine on

    # If your site can be accessed both with and without the 'www.' prefix, you
    # can use one of the following settings to redirect users to your preferred
    # URL, either WITH or WITHOUT the 'www.' prefix. Choose ONLY one option:
    #
    # To redirect all users to access the site WITH the 'www.' prefix,
    # (Example Web Page... will be redirected to Example Web Page...)
    # adapt and uncomment the following:
    # RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
    # RewriteRule ^(.*)$ http://www.example.com/$1 [L,R=301]
    #
    # To redirect all users to access the site WITHOUT the 'www.' prefix,
    # (Example Web Page... will be redirected to Example Web Page...)
    # uncomment and adapt the following:
    # RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
    # RewriteRule ^(.*)$ http://example.com/$1 [L,R=301]

    # Modify the RewriteBase if you are using Drupal in a subdirectory or in a
    # VirtualDocumentRoot and the rewrite rules are not working properly.
    # For example if your site is at http://example.com/drupal uncomment and
    # modify the following line:
    RewriteBase /drupal617
    #
    # If your site is running in a VirtualDocumentRoot at Example Web Page,
    # uncomment the following line:
    # RewriteBase /

    # Rewrite URLs of the form 'x' to the form 'index.php?q=x'.
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_URI} !=/favicon.ico
    RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
    </IfModule>

    ***********************************
    linux-1ap4:~ # apache2ctl -M
    Loaded Modules:
    core_module (static)
    mpm_prefork_module (static)
    http_module (static)
    so_module (static)
    actions_module (shared)
    alias_module (shared)
    auth_basic_module (shared)
    authn_file_module (shared)
    authz_host_module (shared)
    authz_groupfile_module (shared)
    authz_default_module (shared)
    authz_user_module (shared)
    autoindex_module (shared)
    cgi_module (shared)
    dir_module (shared)
    env_module (shared)
    expires_module (shared)
    include_module (shared)
    log_config_module (shared)
    mime_module (shared)
    negotiation_module (shared)
    setenvif_module (shared)
    ssl_module (shared)
    userdir_module (shared)
    php5_module (shared)
    rewrite_module (shared)
    Syntax OK

    Please help!

  2. #2

    Default Re: Testing Drupal 6.17 - problem with apache mod_readwrite

    I'm not sure that I can help you - I didn't even realise that 6.17 had been released until I saw this thread. However

    - how did you install; last time I looked, it wasn't available from repos, so presumably you did something else. A packaged stack, or as individual components?

    The only thing that I saw on 6.17 itself that was worrying was this note:
    Session handling

    Drupal 6.17 changes the way session cookies are handled. Most people don't need to have this setting set, but if you have an explicit $cookie_domain set in settings.php, verify that it is set to a sensible value:
    'example.com' if you want sessions to apply to the example.com domain, and none of its sub-domains (especially not Example Web Page),
    'www.example.com' if you want sessions to apply to the Example Web Page domain, and none of its sub-domains nor parent domains (especially not example.com),
    '.example.com' if you want sessions to apply to the example.com domain and all its subdomains (Example Web Page, mydomain.example.com, etc.).
    it is unclear how that could have any impact at all on your problem, but there could be something odd in a module, I suppose.

    (quoted from Drupal 6.17 released | drupal.org )

    Did you have everything working on 6.16, or was it some earlier version. (Mind you, if it is some earlier version, it is a bit difficult to find the release notes using the obvious method of looking for it menus, although a consideration of the URL for 6.17 reveals that Drupal 6.16 and 5.22 released | drupal.org is likely to be the one (and it is) ).

  3. #3

    Default Re: Testing Drupal 6.17 - problem with apache mod_readwrite

    Hi markone - thanks for responding

    D 6.17 came jun 2.
    I am testing Drupal for the first time so I installed the package.
    I have also tried the same with D 7.0 alpha5 with the same result.

    But Apache loads the rewrite module.

    During hard work I restarts Apache and checking the log I find the following:
    When restarting Apache I get the following errors in log:

    [Thu Jul 08 14:30:48 2010] [notice] caught SIGTERM, shutting down
    [Thu Jul 08 14:30:54 2010] [warn] Init: Session Cache is not configured [hint: SSLSessionCache]
    PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php5/extensions/Zlib.so' - /usr/lib64/php5/extensions/Zlib.so: cannot open shared object file: No such file or directory in Unknown on line 0
    [Thu Jul 08 14:30:55 2010] [notice] Apache/2.2.13 (Linux/SUSE) mod_ssl/2.2.13 OpenSSL/0.9.8k PHP/5.3.2 configured -- resuming normal operations
    [Thu Jul 08 14:32:18 2010] [error] [client ::1] File does not exist: /srv/www/htdocs/drupal617/admin, referer: http://localhost/drupal617/?q=admin/settings/clean-urls[/I]

    The PHP Warning looks for the file Zlib.so and can not find it. The file name is zlib.so with lowercase z
    Dont know where to fix the this as I do not want to change the filename due to possible other dependencies.

  4. #4

    Default Re: Testing Drupal 6.17 - problem with apache mod_readwrite

    for 11.2, I see
    http://software.opensuse.org/search/...m&query=drupal (6.16)
    and
    http://software.opensuse.org/search/...m&query=drupal (6.14)
    (plus some modules, the versions of which don't really correlate with anything)

    for 11.1 (which I'm still using, pending the release of 11.3), I'm seeing 6.12 and 6.14

    6.17 did hit the Drupal site itself on 2-June, as you say, but there is normally a delay between hitting the Drupal site and being available from repositories on the SuSE site.

    If you got the software from SuSE we should be able to, more-or-less, eliminate (reduce to a small value) the possibility of an installation error; if you got it from Drupal site itself, or somewhere else, that probably isn't that certain. (I've tried the Bitnami stack, which makes installation pretty trivial, but, imho, is inimical with security; I haven't tried the Aquia stack.)

    The PHP Warning looks for the file Zlib.so and can not find it. The file name is zlib.so with lowercase z
    Dont know where to fix the this as I do not want to change the filename due to possible other dependencies.
    This shouldn't happen (err, obviously), but, if what you have has only been tested on windows, it would be quite possible that a case sensitivity issue could escape through testing without being noticed.

    What you could try, if only to test the hypothesis that this is the problem, is create a link from the name that is being emitted (upper case z) to the file that exists (lower case z) in the directory in which the file exists. This is a bit of a bodge, and I certainly wouldn't be suggesting that you try this on your production site, but it could prove the theory. Maybe this is only the first and most obvious issue and there is something else, too...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •