Ho uno script che eseguo utilizzando php artisan (con utente root ) e talvolta provoca la creazione del file di registro giornaliero prima che lo faccia l'utente apache www-data , il che significa che quando un utente reale utilizza la mia applicazione web, ottengo l'errore di autorizzazione della cartella:

Impossibile aprire il flusso: autorizzazione negata

Cambio i permessi di nuovo in www-data ogni volta, ma voglio risolverlo creando il file di log sempre con i permessi corretti.

Ho preso in considerazione la creazione di un cron job che crei il file o lo tocchi per assicurarmi che abbia i giusti permessi ogni giorno, ma sto cercando una soluzione migliore che non si basi su un altro script.

Abbiamo anche considerato di avvolgere php artisan in un altro script per assicurarci che venga sempre eseguito con le credenziali www-data , ma qualcosa che vogliamo fare sono in realtà procedure di root che apache non dovrebbe essere autorizzato a fare.

Altri suggerimenti?

Cominciamo con ciò che è costante.

Hai un php artisancomando, gestito da root.

È lecito ritenere che questo comando venga eseguito quotidianamente.

Soluzione No 1:

Dato che l'utente che crea i file è quello che ha il permesso di scrivere su di esso per impostazione predefinita, possiamo separare i log per utente in quanto tali:

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');

Se il www-data utente dovesse creare un registro degli errori, che si tradurrebbe in: storage/logs/laravel-www-data-2015-4-27.log.

Se il principale utente dovesse creare un registro degli errori, che si tradurrebbe in: storage/logs/laravel-root-2015-4-27.log.

Soluzione No 2:

Cambia il log usato dal tuo comando artisan, nel tuo script php.

Nella tua run()funzione, aggiungi questa riga all'inizio:

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

Se il nome della tua classe è ArtisanRunner, il tuo file di registro sarà:

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

Conclusione: la soluzione numero 1 è migliore, dato che delinea i registri per utente e quindi non si verificheranno errori.

EDIT: come sottolineato da jason, get_current_user()restituisce il nome del proprietario dello script. Quindi, per applicare la soluzione n. 1, la chowntua classe artigiana file con il nome utente richiesto.

Laravel versione 5.6.10 e successive supporta un permissionelemento nella configurazione ( config/logging.php) per singlee il dailydriver:

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

Non c'è bisogno di destreggiarsi con Monolog nello script bootstrap.

In particolare, il supporto è stato aggiunto in https://github.com/laravel/framework/commit/4d31633dca9594c9121afbbaa0190210de28fed8 .

Per Laravel 5.1 utilizzo quanto segue verso la fine di bootstrap/app.php(come menzionato nei documenti ):

/**
 * 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);
});

Ci sono molti altri gestori che puoi usare invece, ovviamente.

A tal fine, è necessario utilizzare ACL avanzato su file e directory. setfaclsarebbe la tua risposta qui. Se vuoi dare all'utente www-data i permessi per scrivere sui file di root in una directory specifica, puoi farlo in questo modo:

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

Dopo aver emesso questo, stai impostando le autorizzazioni rwxper l' utente www-data su tutti i file /my/folder/indipendentemente da chi li ha creati. Per favore, guarda questa e questa domanda come riferimento. Inoltre, puoi controllare i documenti persetfacl .

Fammi sapere se questo aiuta.

Ho funzionato in modo molto semplice:

Ho riscontrato lo stesso problema su Laravel 5.6

In config/logging.phpHo appena aggiornato il valore del percorso del canale giornaliero con php_sapi_name()esso.

Questo crea una durectory separata per diversi php_sapi_name e inserisce il file di log con il timestamp nella loro directory perticolare.

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

Quindi per me

• I file di registro vengono creati nella fpm-fcgidirectory: Log dal sito Web,owner: www-data
• I file di registro vengono creati nella clidirectory: dal comando artisan (cronjob).owner: root

Maggiori informazioni sulla registrazione di Laravel 5.6: https://laravel.com/docs/5.6/logging

Ecco il mio config/logging.phpfile:

<?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',
        ],
    ],
];

Per me questo problema era molto più che autorizzazioni di registro ... Ho avuto problemi con qualsiasi cosa relativa alle cartelle bootstrap / cache e archiviazione in cui un utente creava un file / cartella e l'altro non sarebbe stato in grado di modificare / eliminare a causa dello standard Autorizzazioni 644 e 755.

Gli scenari tipici sono:

• Il file bootstrap / cache / compiled.php creato dall'utente apache ma non modificabile dall'utente del compositore durante l'esecuzione del comando di installazione del compositore

• L'utente apache che crea la cache che non può essere cancellata utilizzando l'utente compositore

• Le temute condizioni di gara del registro descritte sopra.

Il sogno è che, indipendentemente dall'utente che crea il file / cartella, gli altri utenti che devono accedere hanno esattamente le stesse autorizzazioni dell'autore originale.

TL; DR?

Ecco come si fa.

Dobbiamo creare un gruppo di utenti condiviso chiamato laravel, il gruppo è composto da tutti gli utenti che hanno bisogno di accedere alle directory di archiviazione e bootstrap / cache. Quindi dobbiamo assicurarci che i file e le cartelle appena creati abbiano rispettivamente il gruppo laravel e le autorizzazioni 664 e 775.

È facile farlo per file / directory esistenti, ma è necessaria un po 'di magia per modificare le regole di creazione di file / cartelle predefinite ...

## 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

Puramente per scopi di debug, ho trovato che dividere i log in entrambi gli utenti cli / web + era vantaggioso, quindi ho modificato leggermente la risposta di Sam Wilson. Il mio caso d'uso è stato la coda eseguita con il proprio utente, quindi ha aiutato a distinguere tra l'utente del compositore che utilizzava il cli (ad es. Unit test) e il demone della coda.

$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

Nel nostro caso volevamo creare tutti i file di registro in modo che tutto nel deploygruppo avesse i permessi di lettura / scrittura. Pertanto, dovevamo creare tutti i nuovi file con 0664autorizzazioni, contrariamente a quelle 0644predefinite.

Abbiamo anche aggiunto un formattatore per aggiungere nuove righe per una migliore leggibilità:

$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);
});

Inoltre è possibile combinare questo con la risposta accettata

$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);
});

Un modo non Laravel per far funzionare questo è semplicemente eseguire il cronjob come www-data.

ad es. /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

Aggiungi questo codice a 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);
});

• Memorizzerà file come questo: laravel-2018-01-27-cli-raph.loge laravel-2018-01-27-fpm-cgi-raph.logche è più leggibile.
• Le nuove linee vengono mantenute (come del comportamento predefinito di Laravel)
• Funziona con Laravel Log Viewer

Laravel 5.6

Devi creare una classe per il tuo logger:

<?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;
    }
}

Quindi, devi registrarlo in config/logging.php:

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

Stesso comportamento della 5.5:

• Memorizzerà file come questo: laravel-2018-01-27-cli-raph.loge laravel-2018-01-27-fpm-cgi-raph.logche è più leggibile.
• Le nuove linee vengono mantenute (come del comportamento predefinito di Laravel)
• Funziona con Laravel Log Viewer

Aggiungi qualcosa di simile all'inizio del tuo app/start/artisan.phpfile (questo è con 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);
}

Regola il percorso se il file di registro giornaliero menzionato non è il file di registro Laravel standard. Potresti anche non voler cambiare il gruppo o impostare le autorizzazioni come sto facendo qui. Quanto sopra imposta il gruppo su www-datae imposta i permessi di scrittura del gruppo. Ho quindi aggiunto il mio utente normale al www-datagruppo in modo che l'esecuzione di comandi artisan come utente normale possa ancora scrivere nel registro.

Un tweak correlato consiste nell'inserire quanto segue all'inizio del app/start/global.phpfile:

umask(0002);

Se lo fai, la chmodriga sopra diventa discutibile. Con umask impostato su questo, tutti i nuovi file PHP (e quindi Laravel) avranno i loro permessi mascherati solo in modo che gli "altri" utenti non abbiano i permessi di scrittura. Ciò significa che le directory inizieranno come rwxrwxr-xe i file come rw-rw-r--. Quindi, se www-dataè in esecuzione PHP, qualsiasi cache e file di registro che crea sarà scrivibile per impostazione predefinita da chiunque nel gruppo principale di quell'utente, ovvero www-data.

(Laravel 5.6) Recentemente ho riscontrato lo stesso problema e ho semplicemente impostato un comando programmato per l'esecuzione /app/Console/Kernel.php.

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

So che è un po 'eccessivo, ma funziona come un fascino e da allora non ha avuto problemi.

Laravel 5.4

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

aggiungi alla bootfunzione inAppServiceProvider

Laravel 5.8

Laravel 5.8 ti consente di impostare il nome del log in config/logging.php .

Quindi, usando risposte e commenti precedenti, se vuoi dare un nome accedi usando sia il nome utente posix effettivo CHE il file php_sapi_name() valore, devi solo cambiare il nome del log impostato. L'utilizzo del driver giornaliero consente la rotazione del registro che viene eseguita per combinazione utente / api che garantirà che il registro sia sempre ruotato da un account in grado di modificare i registri.

Ho anche aggiunto un controllo per le funzioni posix che potrebbero non esistere nel tuo ambiente locale, nel qual caso il nome del registro è semplicemente quello standard.

Supponendo che tu stia utilizzando il canale di log predefinito "giornaliero", puoi modificare la chiave dei "canali" in questo modo:

# 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,
    ],
    ...

Ciò risulterà in un nome di registro che dovrebbe essere univoco per ciascuna combinazione, ad esempio laravel-cli-sfscs-2019-05-15.logo in laravel-apache2handler-apache-2019-05-15.logbase al punto di accesso.

Puoi semplicemente modificare il permesso del file di registro nel tuo comando artisan:

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

dove get_current_user () restituirà l'utente dello script corrente.

In altre parole, daily.logavrà sempre www-datacome proprietario, anche se si inizializza lo script come rootutente.

Se stai usando Laravel Envoyer , ecco una possibile soluzione usando ACL in Linux:

1. Innanzitutto, esegui il seguente script con le rootautorizzazioni sul server:

In entrambi gli script dovrai sostituire le variabili come indicato di seguito:

• {{MASTER_PATH}} : il percorso della directory degli host virtuali (ad es. La cartella> contenente le applicazioni).
• {{WEB_SERVER_USER}} : l'utente utilizzato dal tuo server web.
• {{DEPLOYMENT_USER}} : l'utente da cui viene eseguito lo script di distribuzione.

#!/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. Impostare il seguente hook di distribuzione su envoyer in "Attiva nuova versione"> "Prima di questa azione

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. Ridistribuire l'applicazione

Ora ridistribuisci la tua applicazione e dovrebbe funzionare in futuro.

Nota: lo script definito in 1. deve essere eseguito ogni volta che si aggiunge un nuovo progetto alla macchina.

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

Il modo migliore che ho trovato è che fideloper suggerisce, http://fideloper.com/laravel-log-file-name , puoi impostare la configurazione del log di laravel senza toccare la classe Log. Avere nomi diversi per i programmi della console e i programmi Http, penso, sia la soluzione migliore.

Questa soluzione funzionerà sicuramente su Laravel V5.1 - V6.x

Motivi di questo errore:

• Ci sono principalmente cause dovute a problemi di autorizzazione
• Variabili d'ambiente non trovate o .envfile non trovato nella directory principale
• Problema con le estensioni PHP
• Problema del database

fix:

• Imposta le autorizzazioni corrette:
  • Esegui questi comandi (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

• Se il file .env non esiste, creane uno touch .enve incolla le tue variabili di ambiente, quindi esegui

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