it-swarm.asia

لا يمكن تثبيت مكونات إضافية جديدة بسبب الخطأ "تعذر إنشاء دليل"

عضو هيئة التدريس يواجه صعوبات في تثبيت وورد التعليمية. لقد تم حل مشاكل الإذن الفردي وتخطيها ، وأصبحت من الألم الدائم ، لذلك سأطلبها هنا. ماذا يمكنني أن أفعل لجعل WP مجرد عمل؟ أنواع الأخطاء التي يحصلون عليها:

تثبيت المكون الإضافي: Lightbox 2 2.9.2 تنزيل حزمة التثبيت من http://downloads.wordpress.org/plugin/lightbox-2.2.9.2.Zip ... تفريغ الحزمة ... تعذر إنشاء الدليل. /home/CIM140/public_html/wordpress/wp-content/upgrade/lightbox-2.tmp

عندما أقوم بتطبيق www-data (يعمل المستخدم Apache كما هو الحال في Ubuntu) ، يمكنني جعل هذا الدليل جيدًا. يعمل مثيل اختبار wp الخاص بي على تثبيت هذا المكون الإضافي على ما يرام ، لذا فأنا في حيرة بسبب إخفاقه في ذلك.

4
jldugger

pwnguin ،

واجهت نفس المشكلات في تشغيل mod_php مع WordPress وأخيراً اكتشفت ذلك.

# chown www-data:www-data  /home/CIM140/public_html/wordpress/ -R

طالما أنك تتحكم في الصندوق ، فلن يتسبب ذلك في أي مشكلات أمنية.


تصحيح:

قد تحتاج أيضًا إلى تغيير umask الخاص بك إلى 022 بحيث يكون للدلائل الجديدة التي أنشأتها WordPress 755 إذنًا وستحتوي الملفات على 644 الأذونات.

خيار آخر هو تجاوز أذونات الملفات الافتراضية في wp-config.php:

define('FS_CHMOD_DIR', (0755 & ~ umask()));
define('FS_CHMOD_FILE', (0644 & ~ umask()));

يمكنك أيضًا فرض طريقة نظام الملفات للحصول على التحديثات.

  • (التفضيل الأساسي) "Direct" يفرض عليه استخدام طلبات إدخال/إخراج الملف المباشر من داخل PHP ، وهذا محفوف بفتح مشاكل الأمان على المضيفين سيئة التكوين ، ويتم اختيار هذا تلقائيًا عند الاقتضاء.
  • (التفضيل الثانوي) "ssh" هو فرض استخدام SSH PHP الامتداد.
  • (التفضيل الثالث) "ftpext" هو فرض استخدام FTP PHP ملحق لـ FTP Access ، وأخيرا
  • (التفضيل الرابع) "ftpsockets" تستخدم PHP Sockets Class للوصول إلى FTP.

يمكن تعريفها في wp-config.php باستخدام: define('FS_METHOD', 'ftpext');

يمكنك الحصول على جميع الثوابت المعرفة حاليًا عن طريق تنفيذ الأمر print_r(@get_defined_constants()); في php.

5
Chris_O

بالنسبة لي (على Ubuntu) اضطررت إلى إضافة umask 002 إلى /etc/Apache2/envvars من أجل الحصول على وورد لتحميل الإضافات/الصور مع أذونات 775 بدلاً من 755 (أي السماح لأي شخص إلى جانب Apache والجذر بتغيير الملفات التي تم تحميلها)

0
willbradley

من أجل فهم سبب مواجهتك لهذه المشكلات ، تحتاج إلى فهم المفاهيم الأساسية للملكية.

في الأساس ، أنت تعرف أن Apache يعمل كمستخدم www-data. هذا هو السبب في تعيين كل شيء ليكون مملوكًا لهذا المستخدم ، لأن WordPress يتحقق من أنه يمكنه إنشاء ملفات كمستخدم يمتلك ملفاته الخاصة. لذا ، ما تفعله هو جعل كل شيء يمتلكه المستخدم الذي يمتلك الملفات.

إذا كان لديك تحكم كامل وكامل بالجهاز ، فهذا جيد. من ناحية أخرى ، إذا كان خادم استضافة مشتركًا ، فقد قمت بإنشاء ثغرة أمنية.

عادة ، تعمل خوادم الويب كمستخدم (مثل www-data) يقوم بعد ذلك بتشغيل التعليمات البرمجية بواسطة مستخدمين آخرين (مثل "otto" ، حساب المستخدم الخاص بي). في هذه الحالة ، لن يتمكن خادم الويب من إنشاء ملفات باسم "أوتو" ، وبالتالي لن يكون قادرًا على إنشاء ملفات بشكل صحيح كحسابي. وبالتالي ، فإن هذا التحقق بواسطة WordPress لإنشاء ملفات مملوكة بشكل صحيح وبالتالي القدرة على تثبيت المكونات الإضافية أو تحديث الملفات قد يفشل ، بشكل صحيح ، لأن وجود ملفاتي التي يملكها مستخدم مشترك خادم الويب سيكون مخاطرة أمنية .

في مثل هذه الحالة ، يجب أن يطالبك WordPress بشكل صحيح ببيانات اعتماد FTP أو أي شيء بهذا المعنى. ستكون هذه طريقة للتغلب على مشكلة حساب المستخدم عن طريق المصادقة كمستخدم الذي يجب أن يكتب الملفات ، ثم كتابتها كمستخدم.

أنت الآن تحاول حل هذه المشكلة عن طريق تغيير جميع ملفات WordPress لتكون مملوكة لنفس الحساب الذي يكتب عليه خادم الويب. الطريقة الأكثر طبيعية لهذا هي تغيير كيفية كتابة خادم الويب للملفات ، للسماح لـ PHP بأن تكون العملية "مملوكة" بواسطة حساب المستخدم الذي يقوم بتشغيل الملفات عليه.

الجواب العام على هذا هو "suphp". يعيّن هذا الإصدار من PHP المستخدم أن العملية PHP تعمل بنفس المستخدم مثل مالك PHP الملفات التي يعمل بها. يعد هذا أكثر أمانًا في إعدادات الاستضافة المشتركة ، لأنه يضمن تشغيل عملية PHP يتم تشغيلها بواسطة خادم الويب المشترك كمالك لملفات PHP ، وبالتالي لا يمكن قراءة المستخدمين الآخرين حسابات وما شابه ذلك.

على أوبونتو ، أعتقد أن هذه هي الطريقة العامة للقيام بذلك:

تثبيت suphp:

$ Sudo apt-get install libapache2-mod-suphp

تعطيل mod_php القديم

$ Sudo a2dismod php5 

أعد تشغيل Apache

$ Sudo /etc/init.d/Apache2 restart

وفويلا. الآن ، تملك ملفات WordPress PHP التي يملكها Normal مالكها. لا الحيل الخاصة ، لا تغيير الأذونات أو الملكية أو أي شيء من هذا القبيل. نظرًا لأن العملية PHP ستعمل كمالك لتلك الملفات ، فستتمكن من الكتابة إليها كمالك. يجب أن تكون الدلائل 755 ، ويجب أن تكون الملفات 644 (ملاحظة ، لا يحب suphp عندما تكون الملفات قابلة للكتابة حسب المجموعة ، لذا 755/644 هي مجموعة الأذونات الصحيحة).

0
Otto