Каталог статей
Когда я открыл его, как обычноСерверная часть 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Просто добавьте две строки кода в файл.
// 修复 BackWPup / AWS SDK open_basedir 警告
putenv('AWS_CONFIG_FILE=/tmp/aws_config');
putenv('AWS_SHARED_CREDENTIALS_FILE=/tmp/aws_credentials');加在/* That's all, stop editing! Happy publishing. */Просто поднимитесь выше этой линии.
Всего эти две строчки.
Ушел.
Подробное объяснение принципа перенаправления путей конфигурации AWS с помощью Putenv.
Подумайте сами, по сути, эти две строки кода говорят AWS SDK: «Не просматривайте мои каталоги, перейдите в...»/tmpНайдите файл конфигурации в указанной директории.
/tmpВ этом каталоге находятся почти все серверы.open_basedirОно находится в белом списке, потому что изначально это временный каталог системы.
Заглянув в AWS SDK, я обнаружил, что файл конфигурации находится.../tmpТогда иди./tmpНайдите его. Он идеально обходит ограничения безопасности и ни на что не влияет.
И вам на самом деле не обязательно туда идти./tmpЧто нужно создать в директории?aws_configФайлы. Поскольку вы, скорее всего, вообще не использовали конфигурационные файлы AWS, все эти конфигурации содержат пустые значения по умолчанию. (AWS SDK...)/tmpПосле поисков я ничего не нашел, поэтому просто воспользуюсь конфигурацией по умолчанию; это ничего не изменит.
Это как обмануть кошку, сказав, что кошачий корм находится в соседней комнате. Кошка подбегает, ничего не находит, возвращается, и ничего не происходит.
Подтверждение эффективности восстановления: журналы резервного копирования BackWPup вернулись в нормальное состояние.
После внесения изменений вернитесь в административную панель WordPress, откройте BackWPup и нажмите «Запустить сейчас».
Проверьте журналы после завершения выполнения.
Ярко-желтые предупреждения исчезли, их заменили зеленые сообщения «Успешно завершено».
Всё очень гладко.
Две строчки кода, нулевой риск, менее 10 секунд на доработку, и проблема была полностью решена.
Такие «не фатальные, но раздражающие» проблемы на самом деле отнимают больше всего времени. Потому что вы не знаете, не усугубится ли ситуация после обновления, и не знаете, повлияет ли это на другие плагины.
Если что-то можно полностью исключить с помощью двух строк кода, то не оставляйте это на пути.
На этом статья заканчивается.
Поскольку этот вопрос несложен, мне не нужно предоставлять вам какие-либо базовые знания, анализ отрасли или прогнозы будущих тенденций.
Это всего лишь небольшое предупреждение в панели администратора WordPress, которое можно исправить всего двумя строками кода.
Надеюсь, в следующий раз, когда вы увидите это желтое предупреждение, вы вспомните эту статью.
Блог Хоуп Чен Вейлян ( https://www.chenweiliang.com/ Статья "Как решить проблему с плагином WordPress BackWPup is_readable(): open_basedir restriction in effect. AWS path warning?", размещенная здесь, может оказаться вам полезной.
Добро пожаловать, чтобы поделиться ссылкой на эту статью:https://www.chenweiliang.com/cwl-34455.html
