Journal quotidien Laravel créé avec de mauvaises autorisations

112

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?

NiRR
la source
Configurez un crontravail dans touchun nouveau fichier journal à minuit tous les jours (sous le bon utilisateur, bien sûr).
Ben Harold
@BenHarold Merci, nous avons considéré cela mais je préfère ne pas impliquer plus de scripts.
NiRR
2
Dans ce cas, vous devrez exécuter en php artisantant qu'utilisateur pour lequel vous souhaitez créer le fichier journal.
Ben Harold
@BenHarold Encore une fois merci, nous avons également considéré cela, ce qui est probablement la meilleure façon de procéder, mais j'ai mis à jour la question pour expliquer pourquoi ce n'est pas non plus idéal.
NiRR
2
Ce qui a fonctionné pour moi était d'exécuter le cron en tant qu'utilisateur www-data avecsudo crontab -u www-data -e
Nil Llisterri

Réponses:

67

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.

Mysteryos
la source
12
Veuillez noter que get_current_user()renvoie le propriétaire du script PHP actuel (selon php.net) et non l'utilisateur qui exécute actuellement le script. J'utilise à la php_sapi_name()place, qui donne le nom du gestionnaire php (apache ou cli, par exemple) qui aura tendance à être exécuté en tant qu'utilisateurs différents.
Jason
1
Puis-je suggérer d'utiliser à la fois le nom d'utilisateur exécutant le script et le nom_php_sapi en combinaison car il est possible pour de nombreux utilisateurs d'exécuter Laravel à partir de la CLI, par exemple, quelques DBA accèdent à votre serveur ou vous pouvez souhaiter que Laravel CRON s'exécute en tant qu'apache. obtenir le nom du processus exécutant ce script en utilisant posix_getpwuid (posix_geteuid ()) ['name']; Voir mon article complet ci-dessous.
Andrew le
Cela doit être mis à jour pour les dernières versions de Laravel: v5 +
Andrew
107

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 .

Crishoj
la source
9
cela devrait être dans la doc officielle!
odupont
3
les apostrophes manquent dans cette réponse. Ce devrait être 'permission' => '0664'. Alors cette réponse est parfaitement bien!
Phil
2
@Phil Nope - c'est juste un wrapper pour le gestionnaire de flux Monologs qui accepte un int pour les autorisations. Monolog enveloppe php.net/manual/en/function.chmod.php - notez qu'un 0 en tête est requis pour s'assurer qu'il s'agit d'une valeur octale
Chris
7
'permission' => 0664fonctionne pour moi (sans guillemets)
Syclone
2
@Friedrich si votre fichier journal est créé avec `` root '' comme propriétaire du fichier, cela indique probablement que vous avez des problèmes plus importants en termes de configuration de votre serveur Web
kjones
62

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.

Sam Wilson
la source
1
J'aime vraiment cette réponse car 1) elle est mise à jour vers 5.1 et 2) utilise une méthode dans la documentation pour étendre le comportement du journal.
Dylan Pierce
Excellent, le flash avant supplémentaire n'est pas nécessaire mais fonctionne toujours. Il devrait lire ... $ filename = storage_path ('logs / laravel -'. Php_sapi_name (). '. Log');
Andrew
Puis-je suggérer d'utiliser à la fois le nom d'utilisateur en exécutant le script et le nom_php_sapi en combinaison car il est possible pour de nombreux utilisateurs d'exécuter Laravel à partir de la CLI, par exemple, quelques DBA accèdent à votre serveur ou vous pouvez souhaiter que Laravel CRON s'exécute en tant qu'apache. obtenir le nom du processus exécutant ce script en utilisant posix_getpwuid (posix_geteuid ()) ['name']; Voir mon article complet ci-dessous.
Andrew le
1
Comment l'utiliser dans Laravel 5.6? Parce que Laravel 5.6 a un tout nouveau système de journalisation.
Hamed Kamrava
26

À 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.

Paweł Tomkiel
la source
3
La commande suivante a fonctionné pour moi: setfacl -d -m g:www-data:rw /full/path/to/laravel/storage/logssuivie de php artisan cache:clearet composer dump-autoload.
Sawny
17

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',
        ],
    ],
];
Lahar Shah
la source
nice ... ur solution is clean .. im test it now
Sina Miandashti
1
Comme cela a été souligné dans un autre commentaire, les journaux ne sont qu'une partie de l'histoire. Il existe des vues compilées, des caches de données, du code source pré-mis en cache, dont chacun peut être créé en tant que fichiers locaux par le Web ou l'utilisateur cli.
Jason
2
Cela ne fonctionne pas si vous mettez en cache la configuration en utilisant artisan config:cache, car cela créera un cache de configuration en utilisant le cli SAPI qui sera utilisé à la fois pour les requêtes CLI et Web.
leeb
1
Cela fonctionne pour moi, essayé get_current_userne fonctionne pas, mais php_sapi_namefonctionne (même si cela semble plus laid)
Richard Fu
Je pense que c'est le moyen le plus rapide et le meilleur. Modifier la configuration ne modifie pas la structure de base de Laravel, juste la configuration.
William Prigol Lopes le
12

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);
}); 
Andrew
la source
C'est très bien. Votre configureMonologUsingcode est-il toujours nécessaire une fois que vous avez exécuté les setfaclcommandes?
jeff-h
7

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);
});
Artur Käpp
la source
6

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

user2662680
la source
5

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
rap-2-h
la source
Meilleure réponse! Kudos
Shahid Karimi
4

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.

tremby
la source
4

(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.

Ague Mort
la source
Ça marche ? Oui, mais est-ce que la meilleure pratique? Je crois que non.
Pablo Papalardo le
3

Laravel 5.4

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

ajouter à la bootfonction dansAppServiceProvider

StupidDev
la source
1

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.

sfscs
la source
0

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

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

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.

Adam
la source
0

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.

Emil Pedersen
la source
0
cd /path/to/project
chown -R www-data:root .
chmod -R g+s .
Eduardo
la source
-1

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.

Giacomo
la source
-1

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
Smit Patel
la source