Как устранить ошибку `is_readable(): open_basedir restriction in effect. AWS path warning` в плагине WordPress BackWPup?

Как обычно, открыв панель администратора WordPress , я был готов проверить журналы резервного копирования.

Затем я увидел множество жёлтых.

Предупреждение, предупреждение и ещё раз предупреждение.

警告: is_readable(): open_basedir restriction in effect. 
File(/home/admin/.aws/config) is not within the allowed path(s): (...)

Резервное копирование завершилось без перерывов, но строка состояния была полностью жёлтой, что было очень неприятно.

Знакомо это чувство? Как будто отправляешь запрос на слияние, все проверки CI пройдены успешно, но есть предупреждение линтера. Ты понимаешь, что это не повлияет на работу приложения, но всё равно чувствуешь себя некомфортно.

Я на мгновение задумался.

Можно ли полностью решить эту проблему?

Настоящая причина предупреждения BackWPup: AWS SDK превысил лимит open_basedir.

Честно говоря, сначала я подумал, что проблема в плагине резервного копирования BackWPup, так как предупреждение появилось в его логах.

Но при более внимательном рассмотрении выяснилось, что что-то не так.

В предупреждении упоминалась тропа./home/admin/.aws/configЭто AWS SDK, который автоматически ищет каталог конфигурации AWS по умолчанию у текущего пользователя во время инициализации.

Звучит немного запутанно, не правда ли?

По сути, это означает, что если вы установите в WordPress плагин, связанный с AWS, например, для хранилища S3 или CloudFront, все эти плагины будут использовать AWS SDK в своей основе. При запуске AWS SDK он автоматически проверит вашу домашнюю директорию на наличие инструментов установки AWS SDK..awsВ этой папке находятся файлы конфигурации и учетные данные.

Однако из соображений безопасности PHP-сервер открыл...open_basedirПо сути, это похоже на обозначение территории на сервере и указание PHP, что вы можете перемещаться только в пределах этой территории, а не свободно перемещаться по ней.

/tmpКаталог находится в белом списке, каталог веб-сайта находится в белом списке, но ваш каталог, к сожалению, нет.

Когда AWS SDK пытается получить доступ к вашему каталогу, доступ блокируется.

Затем появилось предупреждение.

Правильный подход к устранению предупреждений open_basedir: перенаправить путь к конфигурации AWS.

Честно говоря, моей первой реакцией было это изменить.open_basedirНастройте, введите/home/adminДобавьте это.

Но потом я снова об этом подумал и понял, что это неправильно.

Вы допустили ошибку. Неправильное форматирование. Вы пропустили косую черту и добавили лишний пробел. Это привело к ошибке 500, и весь сайт исчез.

иopen_basedirОно было открыто по соображениям безопасности. Если вы его откроете, вы, по сути, предоставите серверу лазейку, а это того не стоит.

Есть ли более безопасный способ?

Я немного подумал об этом, ведь для поиска нужно использовать AWS SDK.../home/admin/.aws/configМожно ли обмануть систему, заставив её искать этот файл в другом месте?

Отправляйтесь в одно из мест, уже включенных в белый список.

Исправить предупреждения WordPress BackWPup: добавьте две строки кода в файл wp-config.php

Решение на самом деле до смешного простое.

В WordPresswp-config.phpПросто добавьте две строки кода в файл.

// 解决 AWS open_basedir 警告的环境变量设置
putenv('AWS_CONFIG_FILE=' . __DIR__ . '/wp-content/uploads/.aws_config');
putenv('AWS_SHARED_CREDENTIALS_FILE=' . __DIR__ . '/wp-content/uploads/.aws_credentials');
putenv('AWS_EC2_METADATA_DISABLED=true');

/* That's all, stop editing! Happy publishing. */

добавить в/* That's all, stop editing! Happy publishing. */Просто поднимитесь выше этой линии.

Всего эти три строчки.

Ушел.

Подтверждение эффективности восстановления: журналы резервного копирования BackWPup вернулись в нормальное состояние.

После внесения изменений вернитесь в административную панель WordPress, откройте BackWPup и нажмите «Запустить сейчас».

Проверьте журналы после завершения выполнения.

Ярко-желтые предупреждения исчезли, их заменили зеленые сообщения «Успешно завершено».

Всё очень гладко.

Две строчки кода, нулевой риск, менее 10 секунд на доработку, и проблема была полностью решена.

Такие «не фатальные, но раздражающие» проблемы на самом деле отнимают больше всего времени. Потому что вы не знаете, не усугубится ли ситуация после обновления, и не знаете, повлияет ли это на другие плагины.

Если что-то можно полностью исключить с помощью двух строк кода, то не оставляйте это на пути.

На этом статья заканчивается.

Поскольку этот вопрос несложен, мне не нужно предоставлять вам какие-либо базовые знания, анализ отрасли или прогнозы будущих тенденций.

Это всего лишь небольшое предупреждение в панели администратора WordPress, которое можно исправить всего двумя строками кода.

Надеюсь, в следующий раз, когда вы увидите это желтое предупреждение, вы вспомните эту статью.