Як вырашыць праблему з памылкай `is_readable(): open_basedir' у плагіне WordPress BackWPup. Папярэджанне аб шляху AWS.

Калі я, як звычайна, адкрыў адміністрацыйную панэль WordPress , я быў гатовы праверыць журналы рэзервовага капіявання.

Потым я ўбачыў кучу жоўтых.

Папярэджанне, папярэджанне і яшчэ раз папярэджанне.

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

Рэзервовае капіраванне сапраўды завяршылася без перапынкаў, але радок стану быў цалкам жоўтым, што было вельмі непрыемна.

Знаёмае гэтае пачуццё? Быццам ты падаеш запыт на перапрацоўку, усе канфігурацыі зялёныя, але ёсць папярэджанне аб ворсе. Ты ведаеш, што гэта не паўплывае на працу, але ўсё роўна адчуваеш дыскамфорт.

Я на хвіліну падумаў пра гэта.

Ці можна цалкам вырашыць гэтую праблему?

Сапраўдная прычына папярэджання BackWPup: AWS SDK актываваў ліміт open_basedir.

Шчыра кажучы, спачатку я падумаў, што праблема ў плагіне рэзервовага капіявання BackWPup, бо ў яго журналах з'явілася папярэджанне.

Але пры больш уважлівым разглядзе нешта было не так.

У папярэджанні згадваўся шлях./home/admin/.aws/configГэта AWS SDK, які аўтаматычна шукае каталог канфігурацыі AWS бягучага карыстальніка па змаўчанні падчас ініцыялізацыі.

Гэта гучыць крыху заблытана, праўда?

Па сутнасці, гэта азначае, што калі вы ўсталюеце ў WordPress плагін, звязаны з AWS, напрыклад, S3 Storage або 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 і выпраўленне з дапамогай двух радкоў кода.

Спадзяюся, што наступным разам, калі вы ўбачыце гэтае жоўтае папярэджанне, вы ўспомніце гэты артыкул.