J'ai un script que j'exécute en utilisant php artisan (avec l' utilisateur root ), et parfois cela provoque la création du fichier journal quotidien avant que l'utilisateur apache www-data ne le fasse - ce qui signifie que lorsqu'un utilisateur réel utilise mon application Web, j'obtiens l'erreur d'autorisation de dossier:

Échec de l'ouverture du flux: autorisation refusée

Je change les permissions en www-data chaque fois, mais je veux résoudre ce problème en créant toujours le fichier journal avec les autorisations appropriées.

J'ai envisagé de créer un travail cron qui crée le fichier ou le touche pour m'assurer qu'il dispose de la bonne autorisation tous les jours, mais je recherche une meilleure solution qui ne repose pas sur un autre script.

Nous avons également envisagé d'encapsuler php artisan dans un autre script pour nous assurer qu'il est toujours exécuté avec les informations d' identification www-data , mais certaines choses que nous voulons faire sont en fait root procédures qu'apache ne devrait pas être autorisé à faire.

D'autres suggestions?

Commençons par ce qui est constant.

Vous avez une php artisancommande, exécutée par root.

Il est prudent de supposer que cette commande est exécutée quotidiennement.

Solution n ° 1:

Étant donné que l'utilisateur qui crée les fichiers est celui qui a l'autorisation d'y écrire par défaut, nous pouvons séparer les journaux par utilisateur en tant que tels:

App/start/global.php

/*
|--------------------------------------------------------------------------
| Application Error Logger
|--------------------------------------------------------------------------
|
| Here we will configure the error logger setup for the application which
| is built on top of the wonderful Monolog library. By default we will
| build a basic log file setup which creates a single file for logs.
|
*/

Log::useDailyFiles(storage_path().'/logs/laravel-'.get_current_user().'.log');

Si votre www-data utilisateur devait créer un journal d'erreur, il se traduirait par: storage/logs/laravel-www-data-2015-4-27.log.

Si votre racine utilisateur devait créer un journal d'erreur, il se traduirait par: storage/logs/laravel-root-2015-4-27.log.

Solution n ° 2:

Modifiez le journal utilisé par votre commande artisan, dans votre script php.

Dans votre run()fonction, ajoutez cette ligne au début:

Log::useFiles(storage_path().'/logs/laravel-'.__CLASS__.'-'.Carbon::now()->format('Y-m-d').'.log');

Si le nom de votre classe est ArtisanRunner, votre fichier journal sera:

storage/logs/laravel-ArtisanRunner-2015-4-27.log.

Conclusion: La solution numéro 1 est meilleure, étant donné qu'elle délimite vos journaux par utilisateur et qu'aucune erreur ne se produira.

EDIT: Comme indiqué par jason, get_current_user()renvoie le nom du propriétaire du script. Par conséquent, pour que la solution n ° 1 s'applique, chownvos fichiers de classe artisan au nom d'utilisateur requis.

Laravel version 5.6.10 et ultérieure prend en charge un permissionélément dans la configuration ( config/logging.php) pour le singleet le dailypilote:

    'daily' => [
        'driver' => 'daily',
        'path' => storage_path('logs/laravel.log'),
        'level' => 'debug',
        'days' => 7,
        'permission' => 0664,
    ],

Pas besoin de jongler avec Monolog dans le script bootstrap.

Plus précisément, la prise en charge a été ajoutée dans https://github.com/laravel/framework/commit/4d31633dca9594c9121afbbaa0190210de28fed8 .

Pour Laravel 5.1, j'utilise ce qui suit vers le bas de bootstrap/app.php(comme mentionné dans la documentation ):

/**
 * Configure Monolog.
 */
$app->configureMonologUsing(function(Monolog\Logger $monolog) {
    $filename = storage_path('logs/laravel-'.php_sapi_name().'.log');
    $handler = new Monolog\Handler\RotatingFileHandler($filename);
    $monolog->pushHandler($handler);
});

Il existe bien sûr de nombreux autres gestionnaires que vous pouvez utiliser à la place.

À ces fins, vous devez utiliser l'ACL avancée sur vos fichiers et répertoires. setfaclserait votre réponse ici. Si vous souhaitez donner à l' utilisateur www-data des autorisations d'écrire sur les fichiers root dans un répertoire spécifique, vous pouvez le faire comme ceci:

setfacl -d -m default:www-data:you-chosen-group:rwx /my/folder

Après avoir émis cela, vous définissez des autorisations rwxpour l' utilisateur www-data sur tous les fichiers, /my/folder/peu importe qui les a créés. Veuillez lire ceci et cette question pour référence. Vous pouvez également consulter les documents poursetfacl .

Faites-moi savoir si cela vous aide.

J'ai fait fonctionner cela de manière très simple:

J'ai rencontré le même problème sur Laravel 5.6

Dans config/logging.phpJe viens de mettre à jour la valeur du chemin de la chaîne quotidienne avec php_sapi_name().

Cela crée une durée distincte pour différents php_sapi_name et place le fichier journal avec l'horodatage dans leur répertoire correspondant.

'daily' => [
            'driver' => 'daily',
            'path' => storage_path('logs/' . php_sapi_name() . '/laravel.log'),
            'level' => 'debug',
            'days' => 7,
        ]

Alors pour moi,

• Les fichiers fpm-fcgijournaux sont créés sous le répertoire: Journaux du site Web,owner: www-data
• Les fichiers clijournaux sont créés sous le répertoire: à partir de la commande artisan (cronjob).owner: root

Plus d'informations sur la journalisation Laravel 5.6: https://laravel.com/docs/5.6/logging

Voici mon config/logging.phpdossier:

<?php

return [
    /*
    |--------------------------------------------------------------------------
    | Default Log Channel
    |--------------------------------------------------------------------------
    |
    | This option defines the default log channel that gets used when writing
    | messages to the logs. The name specified in this option should match
    | one of the channels defined in the "channels" configuration array.
    |
    */
    'default' => env('LOG_CHANNEL', 'stack'),
    /*
    |--------------------------------------------------------------------------
    | Log Channels
    |--------------------------------------------------------------------------
    |
    | Here you may configure the log channels for your application. Out of
    | the box, Laravel uses the Monolog PHP logging library. This gives
    | you a variety of powerful log handlers / formatters to utilize.
    |
    | Available Drivers: "single", "daily", "slack", "syslog",
    |                    "errorlog", "custom", "stack"
    |
    */
    'channels' => [
        'stack' => [
            'driver' => 'stack',
            'channels' => ['daily'],
        ],
        'single' => [
            'driver' => 'single',
            'path' => storage_path('logs/laravel.log'),
            'level' => 'debug',
        ],
        'daily' => [
            'driver' => 'daily',
            'path' => storage_path('logs/' . php_sapi_name() . '/laravel.log'),
            'level' => 'debug',
            'days' => 7,
        ],
        'slack' => [
            'driver' => 'slack',
            'url' => env('LOG_SLACK_WEBHOOK_URL'),
            'username' => 'Laravel Log',
            'level' => 'critical',
        ],
        'syslog' => [
            'driver' => 'syslog',
            'level' => 'debug',
        ],
        'errorlog' => [
            'driver' => 'errorlog',
            'level' => 'debug',
        ],
    ],
];

Pour moi, ce problème était bien plus que les autorisations de journal ... J'avais des problèmes avec tout ce qui concernait les dossiers d'amorçage / cache et de stockage où un utilisateur créerait un fichier / dossier et l'autre ne pouvait pas modifier / supprimer en raison de la norme 644 et 755 autorisations.

Les scénarios typiques sont:

• Le fichier bootstrap / cache / compiled.php en cours de création par l'utilisateur apache mais non modifiable par l'utilisateur composer lors de l'exécution de la commande d'installation de composer

• L'utilisateur apache créant un cache qui ne peut pas être effacé à l'aide de l'utilisateur composer

• Les redoutables conditions de course des journaux décrites ci-dessus.

Le rêve est que quel que soit l'utilisateur qui crée le fichier / dossier, les autres utilisateurs qui doivent y accéder ont exactement les mêmes autorisations que l'auteur d'origine.

TL; DR?

Voici comment procéder.

Nous devons créer un groupe d'utilisateurs partagé appelé laravel, le groupe se compose de tous les utilisateurs qui ont besoin d'accéder aux répertoires de stockage et de bootstrap / cache. Ensuite, nous devons nous assurer que les fichiers et dossiers nouvellement créés disposent respectivement du groupe laravel et des autorisations 664 et 775.

C'est facile de faire cela pour les fichiers / répertoires existants, mais un peu de magie est nécessaire pour modifier les règles de création de fichiers / dossiers par défaut ...

## create user group
sudo groupadd laravel

## add composer user to group
sudo gpasswd -a composer-user laravel

## add web server to group
sudo gpasswd -a apache laravel

## jump to laravel path
sudo cd /path/to/your/beautiful/laravel-application

## optional: temporary disable any daemons that may read/write files/folders
## For example Apache & Queues

## optional: if you've been playing around with permissions
## consider resetting all files and directories to the default
sudo find ./ -type d -exec chmod 755 {} \;
sudo find ./ -type f -exec chmod 644 {} \;

## give users part of the laravel group the standard RW and RWX
## permissions for the existing files and folders respectively
sudo chown -R :laravel ./storage
sudo chown -R :laravel ./bootstrap/cache
sudo find ./storage -type d -exec chmod 775 {} \;
sudo find ./bootstrap/cache -type d -exec chmod 775 {} \;
sudo find ./storage -type f -exec chmod 664 {} \;
sudo find ./bootstrap/cache -type f -exec chmod 664 {} \;


## give the newly created files/directories the group of the parent directory 
## e.g. the laravel group
sudo find ./bootstrap/cache -type d -exec chmod g+s {} \;
sudo find ./storage -type d -exec chmod g+s {} \;

## let newly created files/directories inherit the default owner 
## permissions up to maximum permission of rwx e.g. new files get 664, 
## folders get 775
sudo setfacl -R -d -m g::rwx ./storage
sudo setfacl -R -d -m g::rwx ./bootstrap/cache

## Reboot so group file permissions refresh (required on Debian and Centos)
sudo shutdown now -r

## optional: enable any daemons we disabled like Apache & Queues

À des fins de débogage, j'ai trouvé que la division des journaux entre les utilisateurs cli / web + était bénéfique, j'ai donc légèrement modifié la réponse de Sam Wilson. Mon cas d'utilisation était la file d'attente exécutée sous son propre utilisateur, ce qui a aidé à faire la distinction entre l'utilisateur compositeur utilisant le cli (par exemple les tests unitaires) et le démon de file d'attente.

$app->configureMonologUsing(function(MonologLogger $monolog) {
     $processUser = posix_getpwuid(posix_geteuid());
     $processName= $processUser['name'];

     $filename = storage_path('logs/laravel-'.php_sapi_name().'-'.$processName.'.log');
     $handler = new MonologHandlerRotatingFileHandler($filename);
     $monolog->pushHandler($handler);
}); 

Laravel 5.1

Dans notre cas, nous voulions créer tous les fichiers journaux afin que tout dans le deploygroupe ait des autorisations de lecture / écriture. Par conséquent, nous devions créer tous les nouveaux fichiers avec des 0664autorisations, par opposition à la 0644valeur par défaut.

Nous avons également ajouté un formateur pour ajouter des nouvelles lignes pour une meilleure lisibilité:

$app->configureMonologUsing(function(Monolog\Logger $monolog) {
    $filename = storage_path('/logs/laravel.log');
    $handler = new Monolog\Handler\RotatingFileHandler($filename, 0, \Monolog\Logger::DEBUG, true, 0664);
    $handler->setFormatter(new \Monolog\Formatter\LineFormatter(null, null, true, true));
    $monolog->pushHandler($handler);
});

Il est également possible de combiner cela avec la réponse acceptée

$app->configureMonologUsing(function(Monolog\Logger $monolog) {
    $filename = storage_path('/logs/laravel-' . php_sapi_name() . '.log');
    $handler = new Monolog\Handler\RotatingFileHandler($filename, 0, \Monolog\Logger::DEBUG, true, 0664);
    $handler->setFormatter(new \Monolog\Formatter\LineFormatter(null, null, true, true));
    $monolog->pushHandler($handler);
});

Une manière non-Laravel de faire ce travail est d'exécuter simplement votre cronjob en tant que www-data.

par exemple /ubuntu/189189/how-to-run-crontab-as-userwww-data

/etc/crontab

*/5 * * * * www-data php /var/www/public/voto_m/artisan top >/dev/null 2>&1

Laravel 5.5

Ajoutez ce code à bootstrap/app.php:

$app->configureMonologUsing(function (Monolog\Logger $monolog) {
    $filename = storage_path('logs/' . php_sapi_name() . '-' . posix_getpwuid(posix_geteuid())['name'] . '.log');
    $monolog->pushHandler($handler = new Monolog\Handler\RotatingFileHandler($filename, 30));
    $handler->setFilenameFormat('laravel-{date}-{filename}', 'Y-m-d');
    $formatter = new \Monolog\Formatter\LineFormatter(null, null, true, true);
    $formatter->includeStacktraces();
    $handler->setFormatter($formatter);
});

• Il stockera des fichiers comme celui-ci: laravel-2018-01-27-cli-raph.loget laravel-2018-01-27-fpm-cgi-raph.logqui est plus lisible.
• Les nouvelles lignes sont conservées (à partir du comportement par défaut de Laravel)
• Cela fonctionne avec Laravel Log Viewer

Laravel 5.6

Vous devez créer une classe pour votre enregistreur:

<?php

namespace App;

use Monolog\Logger as MonologLogger;

class Logger {
    public function __invoke(array $config)
    {
        $monolog = new MonologLogger('my-logger');
        $filename = storage_path('logs/' . php_sapi_name() . '-' . posix_getpwuid(posix_geteuid())['name'] . '.log');
        $monolog->pushHandler($handler = new \Monolog\Handler\RotatingFileHandler($filename, 30));
        $handler->setFilenameFormat('laravel-{date}-{filename}', 'Y-m-d');
        $formatter = new \Monolog\Formatter\LineFormatter(null, null, true, true);
        $formatter->includeStacktraces();
        $handler->setFormatter($formatter);
        return $monolog;
    }
}

Ensuite, vous devez l'enregistrer dans config/logging.php:

'channels' => [
    'custom' => [
        'driver' => 'custom',
        'via' => App\Logging\CreateCustomLogger::class,
    ],
],

Même comportement que pour 5.5:

• Il stockera des fichiers comme celui-ci: laravel-2018-01-27-cli-raph.loget laravel-2018-01-27-fpm-cgi-raph.logqui est plus lisible.
• Les nouvelles lignes sont conservées (à partir du comportement par défaut de Laravel)
• Cela fonctionne avec Laravel Log Viewer

Ajoutez quelque chose comme ce qui suit au début de votre app/start/artisan.phpfichier (c'est avec Laravel 4):

// If effectively root, touch the log file and make sure it belongs to www-data
if (posix_geteuid() === 0) {
    $file = storage_path() . '/logs/laravel.log';
    touch($file);
    chown($file, 'www-data');
    chgrp($file, 'www-data');
    chmod($file, 0664);
}

Ajustez le chemin si le fichier journal quotidien que vous mentionnez n'est pas le fichier journal standard de Laravel. Vous pouvez également ne pas vouloir changer le groupe ou définir les autorisations comme je le fais ici. Ce qui précède définit le groupe sur www-dataet définit les autorisations d'écriture du groupe. J'ai ensuite ajouté mon utilisateur régulier auwww-data groupe afin que l'exécution de commandes artisanales en tant qu'utilisateur régulier puisse toujours écrire dans le journal.

Un ajustement connexe consiste à mettre ce qui suit au début de votre app/start/global.phpfichier:

umask(0002);

Si vous faites cela, la chmodligne ci-dessus devient sans objet. Avec umask réglé sur this, tous les nouveaux fichiers créés par PHP (et donc Laravel) verront leurs permissions masquées uniquement pour que les "autres" utilisateurs n'aient pas les permissions d'écriture. Cela signifie que les répertoires démarreront en tant que rwxrwxr-xet les fichiers en tant que rw-rw-r--. Donc, si www-dataPHP exécute, tout cache et tous les fichiers journaux qu'il crée seront inscriptibles par défaut par n'importe qui dans le groupe principal de cet utilisateur, qui est www-data.

(Laravel 5.6) J'ai récemment rencontré le même problème et j'ai simplement défini une commande planifiée à exécuter /app/Console/Kernel.php.

$schedule->exec('chown -R www-data:www-data /var/www/**********/storage/logs')->everyMinute();

Je sais que c'est un peu exagéré, mais cela fonctionne comme un charme et n'a pas eu de problèmes depuis.

Laravel 5.4

\Log::getMonolog()->popHandler(); \Log::useDailyFiles(storage_path('/logs/laravel-').get_current_user().'.log');

ajouter à la bootfonction dansAppServiceProvider

Laravel 5.8

Laravel 5.8 vous permet de définir le nom du journal dans config/logging.php .

Donc, en utilisant les réponses et les commentaires précédents, si vous souhaitez nommer, vous connectez à la fois le nom d'utilisateur posix réel ET le php_sapi_name() valeur, il vous suffit de modifier le jeu de noms de journal. L'utilisation du pilote quotidien permet une rotation des journaux qui s'exécute par combinaison utilisateur / api, ce qui garantira que le journal est toujours tourné par un compte qui peut modifier les journaux.

J'ai également ajouté une vérification pour les fonctions posix qui peuvent ne pas exister sur votre environnement local, auquel cas le nom du journal par défaut est simplement le standard.

En supposant que vous utilisez le canal de journal par défaut «tous les jours», vous pouvez modifier votre clé «canaux» comme ceci:

# config/logging.php
'channels' => [
    ...
    'daily' => [
        'driver' => 'daily',
        'path'   => storage_path(
            function_exists('posix_getpwuid') 
            && function_exists('posix_geteuid')
                ? 'logs/laravel'
                    . '-' . php_sapi_name()
                    . '-' . posix_getpwuid(posix_geteuid())['name'] 
                    . '.log'
                : 'logs/laravel.log'),
        'level'  => 'debug',
        'days'   => 15,
    ],
    ...

Cela se traduira par un nom de journal qui doit être unique pour chaque combinaison, comme laravel-cli-sfscs-2019-05-15.logou en laravel-apache2handler-apache-2019-05-15.logfonction de votre point d'accès.

Vous pouvez simplement modifier l'autorisation du fichier journal dans votre commande artisan:

$path = storage_path('log/daily.log');
chown($path, get_current_user());

où get_current_user () retournera l'utilisateur du script courant.

En d'autres termes, daily.logaura toujours www-datacomme propriétaire, même si vous initialisez le script en tant rootqu'utilisateur.

Si vous utilisez Laravel Envoyer , voici une solution possible en utilisant ACL sous Linux:

1. Tout d'abord, exécutez le script suivant avec les rootautorisations sur le serveur:

Dans les deux scripts, vous devrez remplacer les variables comme indiqué ci-dessous:

• {{MASTER_PATH}} : Le chemin vers votre répertoire d'hôtes virtuels (par exemple le dossier> contenant votre (vos) application (s)).
• {{WEB_SERVER_USER}} : l'utilisateur utilisé par votre serveur Web.
• {{DEPLOYMENT_USER}} : l'utilisateur par lequel votre script de déploiement est exécuté.

#!/bin/bash

DIRS="storage current/bootstrap/cache"
MASTER_PATH={{MASTER_PATH}}

if [ -d $MASTER_PATH ]; then 
    cd $MASTER_PATH
    for p in `ls $MASTER_PATH`; do 
        if [ -d $MASTER_PATH/$p ]; then     
        cd $MASTER_PATH/$p
            echo "Project: $p -> $MASTER_PATH/$p"
            for i in $DIRS; do 
                echo "- directory: $i" 
                if [ -d $i ]; then 
                    echo "-- checking ACL..."
                    HAS_ACL=`getfacl -p $i | grep "^user:{{WEB_SERVER_USER}}:.*w" | wc -l`
                    if [  $HAS_ACL -eq 0 ]; then 
                        echo "--- applying $i"
                        setfacl -L -R -m u:{{WEB_SERVER_USER}}:rwX -m u:{{DEPLOYMENT_USER}}:rwX $i
                        setfacl -dL -R -m u:{{WEB_SERVER_USER}}:rwX -m u:{{DEPLOYMENT_USER}}:rwX $i
                    else
                        echo "--- skipping $i"
                    fi
                fi
            done
        echo "--------------"
        fi
    done
else
    echo "No $MASTER_PATH - skipping overall"
fi

2. Configurez le hook de déploiement suivant sur envoyer sous "Activer la nouvelle version"> "Avant cette action

PROJECT_DIRS="storage"
RELEASE_DIRS="bootstrap/cache"
 
cd {{ project }}
 
for i in $PROJECT_DIRS; do
  if [ -d $i ]; then
    HAS_ACL=`getfacl -p $i | grep "^user:{{WEB_SERVER_USER}}:.*w" | wc -l`
    if [  $HAS_ACL -eq 0 ]; then
      echo "ACL set for directory {{project}}/$i"
      setfacl -L -R -m u:{{WEB_SERVER_USER}}:rwX -m u:{{DEPLOYMENT_USER}}:rwX $i
      setfacl -dL -R -m u:{{WEB_SERVER_USER}}:rwX -m u:{{DEPLOYMENT_USER}}:rwX $i
    fi
  fi
done
 
cd {{ release }}
 
for i in $RELEASE_DIRS; do
  if [ -d $i ]; then
    HAS_ACL=`getfacl -p $i | grep "^user:{{WEB_SERVER_USER}}:.*w" | wc -l`
    if [  $HAS_ACL -eq 0 ]; then
      echo "ACL set for directory {{project}}/$i"
      setfacl -L -R -m u:{{WEB_SERVER_USER}}:rwX -m u:{{DEPLOYMENT_USER}}:rwX $i
      setfacl -dL -R -m u:{{WEB_SERVER_USER}}:rwX -m u:{{DEPLOYMENT_USER}}:rwX $i
    fi
  fi
done

3. Redéployez votre application

Maintenant, redéployez votre application, et cela devrait fonctionner à l'avenir.

Remarque: Le script défini en 1. doit être exécuté chaque fois que vous ajoutez un nouveau projet à la machine.

cd /path/to/project
chown -R www-data:root .
chmod -R g+s .

Le meilleur moyen que j'ai trouvé est que fideloper suggère, http://fideloper.com/laravel-log-file-name , vous pouvez définir la configuration du journal laravel sans toucher la classe Log. Avoir des noms différents pour les programmes Console et les programmes Http, je pense, est la meilleure solution.

Cette solution fonctionnera définitivement sur Laravel V5.1 - V6.x

Raisons de cette erreur:

• Il y a principalement des causes dues à des problèmes d'autorisation
• Variables d'environnement introuvables ou .envfichier introuvable dans votre répertoire racine
• Problème d'extensions PHP
• Problème de base de données

Réparer:

• Définissez les autorisations appropriées:
  • Exécutez ces commandes (Ubuntu / Debian)

find /path/to/your/root/dir/ -type f -exec chmod 644 {} \;
find /path/to/your/root/dir/ -type d -exec chmod 755 {} \;

chown -R www-data:www-data /path/to/your/root/dir/

chgrp -R www-data storage bootstrap/cache
chmod -R ug+rwx storage bootstrap/cache

• Si le fichier .env n'existe pas, créez-en un touch .envet collez vos variables d'environnement, puis exécutez

   php artisan key:generate
   php artisan cache:clear
   php artisan config:clear
   composer dump-autoload
   php artisan migrate //only if not already migrated