as requested, follow-on to:

https://www.drupal.org/node/1559116#comment-10851950

@bugsonly you are right that should probably be taken care of but it's not the code this patch was touching.

Could you open a new follow-up issue for #73. The error you are reporting is due to file_save_htaccess(), and may be permissions related problem actually because I think we are saving that .htaccess file regardless.

This issue is about install alerts and that is file saving permissions related.

I just installed Drupal 8.0.3 on linux64 + nginx 1.9.10 + php-fpm (PHP 7.0.4-dev)

Generating a make file

    drush make-generate /tmp/example.make \
     --include-versions \
     --exclude-versions=drupal \
     --format=yaml

does work (makefile is created), but not before reporting

    Security warning: Couldn't write .htaccess file. Please create a .htaccess file in[error]
    your
    sites/default/files/config_9brXZQdu_xEwEnHiwVL7LRAZiem4PF0tqPK8r5QTgCUHFxusHgZYgkK2nOb6IovuaJhtbAZyuw//sync
    directory which contains the following lines:
        # Deny all requests from
        Apache 2.4+.
        <IfModule mod_authz_core.c>
          Require all denied
        </IfModule>

        # Deny all requests from Apache 2.0-2.2.
        <IfModule !mod_authz_core.c>
          Deny from all
        </IfModule>
        # Turn off all options we don't need.
        Options -Indexes -ExecCGI -Includes -MultiViews

        # Set the catch-all handler to prevent scripts from being executed.
        SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
        <Files *>
          # Override the handler again if we're run later in the evaluation list.
          SetHandler Drupal_Security_Do_Not_Remove_See_SA_2013_003
        </Files>

        # If we know how to do it safely, disable the PHP engine entirely.
        <IfModule mod_php5.c>
          php_flag engine off
        </IfModule>
        Wrote .make file /tmp/example.make                                               [ok]

checking installed source,

    cat core/modules/file/file.install
    ...
      // Check the server's ability to indicate upload progress.
      if ($phase == 'runtime') {
        $description = NULL;
        $implementation = file_progress_implementation();
        $server_software = \Drupal::request()->server->get('SERVER_SOFTWARE');

        // Test the web server identity.
        if (preg_match("/Nginx/i", $server_software)) {
          $is_nginx = TRUE;
          $is_apache = FALSE;
          $fastcgi = FALSE;
        }
    ...

Is the continuing Apache report an issue of Drupal core? Or, specifically of drush?

Comments

Anonymous’s picture

Anonymous (not verified) commented

bugsonly created an issue. See original summary.

joelpittet’s picture

joelpittet
he/him
Primary language English
Location Vancouver
commented
Version: 8.0.3 » 8.0.x-dev
Status: Active » Postponed (maintainer needs more info)

Thank you for creating this follow-up!

So this actually has nothing to do with nginx/fpm, IMO. You are using drush so it's using CGI from the command line.

Security warning: Couldn't write .htaccess file. Please create a .htaccess file in[error]
your
sites/default/files/config_9brXZQdu_xEwEnHiwVL7LRAZiem4PF0tqPK8r5QTgCUHFxusHgZYgkK2nOb6IovuaJhtbAZyuw//sync

This looks like you have write permission issues with the public:// files.
Which means maybe the command line user you are using doesn't have write access to that folder.

If you agree, maybe a quick check to go to that folder and try to make a new file in that directory from the command line and see what happens. I could be wrong but that's what it sounds like.

If you can't create files, please change the title of this issue around command line user permissions or something along those lines.

Anonymous’s picture

Anonymous (not verified) commented

@joelpettit

No, perms are fine. Either in the default folder, and or any redirected public/private folders.

I don't entirely agree about this "not being an nginx issue"...

nginx does not use .htaccess, it's an apache-ism. Also, the error's clearly 'complaining' about Apache config.

I don't have/use Apache on my box -- just nginx.

The basic premise here should be -- if there's no Apache, then there should be no complaint about Apache anything. At best, perms etc for Nginx-specific setup should be exec'd.

Whatever is doing that check is the 'culprit' here -- it's checking for Apache, and complaining about it, when it's not involved in the sligthest. If not en outright 'error', it's misleading.

joelpittet’s picture

joelpittet
he/him
Primary language English
Location Vancouver
commented

You mentioned in your summary that you were using drush make-generate. What user is that running as?

The error points to not having permission to save. The error message is inside file_save_htaccess() in file
/includes/file.inc:371

Which is checking if a folder is there and writable... so looks like a permission issue to me.

Oh heads up use the dreditor.org browser extension and it can do lots of nice stuff for you in the issue queue (including autocompleting @ mention names;)

Reason why I say it's not an nginx issue is because just because it doesn't use those .htaccess files doesn't mean we shouldn't create them (consider the case where your local dev environment uses different web server from your live or staging)

Anonymous’s picture

Anonymous (not verified) commented

Thanks for the link to the extension. Though, the add'l reading on Mozilla's latest add-on signing idiocy is depressing.

> Reason why I say it's not an nginx issue is because just because it doesn't use those .htaccess files doesn't mean
> we shouldn't create them (consider the case where your local dev environment uses different web server from
> your live or staging)

I'll disagree with this too. I don't want my env peppered with non-useful files -- ESPECIALLY not those that are ACL-related, and inappropriate for my env.

At the very least I'd appreciate the option to specify the SERVER_VENDOR (or some such ...) in settings.php, etc. Files/flags/checks could be exec'd for ONLY those envs specified. For those not, the noise would vanish. DEFAULT could remain "populate for everything", tho I think that's bad design.

In the end, this whining of mine is becoming irrelevant. I'm moving to drush-less install, using Composer-only. THAT's still buggy, but seems to have been declared "the future" way of things. Well, irrelevant until if/when I can't get that to work reliably, and return to drush ...

joelpittet’s picture

joelpittet
he/him
Primary language English
Location Vancouver
commented
Category: Bug report » Feature request
Status: Postponed (maintainer needs more info) » Active

Feel free to disagree, I'm trying to solve the bug/problem you are having explicitly. The change required to avoid writing these files may be wide spread and actually won't solve the explicit problem you are having with writing to the generated public folder from your CLI...

If you want to make the issue about "not writing those types of files for your environment" because of philosophical opinion, feel free to do so, it's sounds like a good idea to me even. I just don't think I can really help with that so I'll leave that up to the install system maintainer to discuss with you.

Moving this to "feature request" because I don't believe that is a bug and I'm pretty sure it was already like that in D7. The bug is write permissions but if you don't want to resolve that, that's fine.

Anonymous’s picture

Anonymous (not verified) commented

> because I don't believe that is a bug

I don't have a perms problem.

The drush make-gen causes an error as reported -- one that's incorrect and inappropriate for the env it's exec'd in. That's not a "philosphical opinion", that's simply a fact.

If that's 'ok', Up to you & fine with me.

I'm simply trying to help the project clean up its mess; I don't need the feature implemented.

Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Closed (won't fix)
joelpittet’s picture

joelpittet
he/him
Primary language English
Location Vancouver
commented

Am I wrong was this the error message you are reporting about?

Security warning: Couldn't write .htaccess file. Please create a .htaccess file in[error]

If I'm not wrong, look at where that error message is being written out in the file I referenced in #4.

If you didn't have permission problems (it may not be your problem it may be how the install is writing and setting permissions on the generated folders), I don't expect you would get the issue summary reported message.