Reverse Cache - Varnish — منتديات الفريق العربي للبرمجة

#129 يوليو 2009 في 02:41 صاحب الموضوع

Varnish عبارة عن reverse proxy يوضع أمام الخادمات لتوفير خاصية caching مما سيخفف العبئ على خادمات المواقع وقواعد البيانات في المؤخرة، ناهيك عن زيادة الأمان. فعوضا من زيادة عدد خادمات المواقع وقواعد البيانات ممكن حل هذه المشكلة بواسطة هذه الطريقة.

تم تصميمه منذ البداية ليكون reverse proxy فهو تخصصي أكثر، بينما squid-cache تم تصميمه كـforward cache ولاحقا أضافوا خاصية الـreverse caching. كذلك الـsoftware archeticture للـVarnish مختلف جذريا مقارنة بـsquid-cache مما يؤدي إلى سرعة تفوقه بعدة أضعاف. لمزيد من تفاصيل التصميم راجعوا هذه الصفحة.

يستخدم لغة خاصة بها في ملف الإعدادات، مسماة بـVCL - Varnish Config Language. هذه اللغة مرنة وتسمح بالتحكم بتفاصيل الـcaching. هذه اللغة تشبه لغات الإسكريبتينج، داخليا يستخدمه Varnish بعد اجراء عملية compile للـVCL file.

هناك عدة خواص مدعومة كلغة ESI - Edge Side Includes. هذه اللغة تم انشاؤها بواسطة مجموعة شركات عملاقة، وتم تقديمها إلى W3C للموافقة عليها كـstandard. حتى الآن لم تصدر الموافقة لكن نظرا لفائدتها الجلية نجد العديد قام بتوفيرها. مثلا Big IP WebAccelerator يقوم بتوفير ESI إضافة إلى Squid-Cache.

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

تمهيد:

بما أن معظم الناس لا يعلمون ماذا أقول، سأدخل قليلا في آلية عمل صفحات الـweb والـserver-side script و قواعد البيانات. وبعدما يكون الأساس راسخا سأبدا في صلب الموضوع، وهو Varnish وطريقة عمله كـReverse Cache لتخفيف الضغط على الخادمات لزيادة سرعة تصفح الزائر عبر الشبكة.

السيناريو:

لدينا خادم يعرض صفحة ديناميكية. لذا، فالخادم لا يضع last modified time stamp في الـhttp header، لأنه لا يدري متى تم تحديث الصفحة. حيث أن الصفحة تستمد معلوماتها من قاعدة البيانات ومصادر أخرى ديناميكية. وكنتيجة لهذا، متصفحات الإنترنت (كفايرفوكس) لن تقوم بتخزين نسخة محلية للزيارات اللاحقة (لا يوجد caching). ونفس الشيء ينطبق على البروكسيات (forward proxies) في المنتصف، كتلك المستخدمة في مزودات خدمة الإنترنت أو الشركات أو الجامعات، لن تستخدم الكاش.

المشكلة:

بما أنه لا أحد يستخدم الكاشينج، ستأتي مشكلة، وهي أن كل يزور شخص الصفحة، حتى لو زائر سابق وإن لم تتغير الصفحة، سيتطلب الأمر execute لكود الـserver side script كـPerl أو PHP أو ASP..الخ. وفي فترة الـexecute سيتم إرسال SQL query لقاعدة بيانات في المؤخرة لإستخراج البيانات المطلوبة، وثم إرسال المعطيات إلى العميل.

الحلول التقليدية:

المشكلة المذكورة بالأعلى، مقبولة في البيئات الديناميكية الصغيرة، لكن في البيئات الديناميكية الأكبر قد يظهر بطئ شديد على الموقع، وعنق الزجاجة سيكون الـscript execution أو الـsql query أو الإثنين، قبل أن يكون الـbandwidth.

أحد الحلول أن نستخدم (مثلا) php caching، و mysql caching. صحيح أن هذه الطرق ستخفف كثيرا من التأخير، لكنها لن تخفف كالـhttp cache. والسبب ببساطة أن (مثلا) mysql cache سيعتمد في النهاية على إرسال بكت query packet وثم استقبال reply packet.

بينما الـhttp caching سيكون مباشرة من الكاش نفسه دون اي query لاي جهة أخرى. السرعة ستكون كبيرة وشبه لحظية. هذه وظيفة reverse cache يوضع أمام الموقع ليواجه طلبات الزوار من الإنترنت. من خلاله ممكن نقول له "قم بكاشينج لكل صفحة مدة 5 دقائق". هكذا سيخف الضغط بشكل ملحوظ على خادم الموقع وقاعدة البيانات. لكن هناك مشكلة، بل عدة مشاكل، وهي:

هذا قد يصلح للمواقع التي تتجدد كل 5 دقائق، لكن ماذا عن مواقع الدردشة والمنتديات؟
ربما محتوى الموقع يتجدد كل سنة مرة، لكن الموقع يحتوي على هيدر مفصل به رسالة ترحيبيه للعضو الذي قام بـlogin. هنا مصيبة، فبهذا الكاش سيقوم أي زائر بمشاهدة اسم الزائر الذي دخل قبله مع الكوكيز الخاصة به. وإذا قلنا للبروكسي بمسح الكوكيز، فحينها مشكلة أخرى وهي أنه لا يستطيع أحد عمل Login على حسابه بالكلية!

طريقة كاشين أخرى وهي من خلال استخدام IMS - If Modified Sinse لكن عيبها صعوبة التطبيق. كما أن الفائدة منها ستقل كلما زاد معدل تحديث الصفحة.

الحل مع ESI:

لو تأملنا قليلا في المشكلة السابقة بالأعلى، مع الـcaching خمسة دقائق، سيتبين لنا أن المشكلة الحقيقية هي أن كل صفحة html هي عبارة عن single object. وكذالك فأي cache engine في المنتصف سيتعامل معه كقطعة واحدة، وهذا سيشمل عدم التمييز بين أجزائه: يعني إما يكون الـcache ttl خمسة دقائق للكل، أو لا يكون للكل. all or none.

الذي يفعله ESI، هو تقسيم كل صفحة html إلى عدة object منفصلة. وهكذا ممكن نقول للـreverse cache أن يقوم بـكاشينج لكل object ويعطيه ttl يتلائم معه. فالـهيدر سيكون object منفصل مع ttl=0، بينما المحتوى سيكون object آخر مع ttl=5min. وهذا التقسيم _فقط_ بين الخادم وبين الـReverse Cache server. زائر الصفحة لا يحس بشيء اطلاقا ويرى كل شيء كأنه صفحة html واحدة.

تم تعديل هذه المشاركة بواسطة eech55 في 8 سبتمبر 2009 في 14:20

إذا نفعتك أحد مشاركاتي فأدع بظهر الغيب لوالداي بالصحة والسلامة والسعادة وطول العمر وأن يكون هذا زيادة لهما في كل خير.

before asking: smart questions how-to

#229 يوليو 2009 في 11:23

السلام عليكم

شكرا على الموضوع

اعتقد ان اسمه المتداول وهو cache engine

ولكن في الجامعة التي كنت اعمل بها قام قسم isp بتركيب هذا الجهاز, وصراحة حسينا بفرق كبير في سرعة الانترنت (كتصفح)

واعتقد انه مهم للشركات الكبيرة لانه يخفف الضغط على استهلاك خط الانترنت bandwidth كما انه يسرع من تصفح المواقع التي يتردد عليها الموظفون كثيرا

فانه جهاز يستحق دفع ثمنه

تم تعديل هذه المشاركة بواسطة ammarroza في 29 يوليو 2009 في 11:24

#330 يوليو 2009 في 05:08

وعليكم السلام يا سيدي،،

الـCache Engine أو أحيانا Content Cache Engine أو Proxy (مندوب) وصف عام ينقسم لقسمين:

- Forward: هذا الكاش يكون قريب من الكلاينت ويستخدم في عمل كاشينج لجميع المواقع التي يقوم الكلاينت بزيارتها (طبعا ممكن تحدد المواقع إذا شئت)

- Reverse: هذا الكاش يكون قريب من الخادمات، ويستخدم لعمل كاش لمحتوى ذلك الخادم فقط. والهدف منه ليس الحفاظ على الباندويذ بقدر ما هو زيادة السرعة من خلال تخفيف الضغط على الخادم والذي بدوره يخفف الضغط على قاعدة البيانات في المؤخرة. الحفاظ على الباندويذ ليس الهدف الأساسي هنا. هناك خواص مثل IMS Not Modified کما هو في معيار HTTP، أو gzip/deflate للضغط ممكن تحافظ على الباندويذ لكن هذا النوع لا يستطيع الحفاظ كالـForward فهما شيئين مختلفين.

هذا الدرس سيكون عن Reverse caching. و البرنامج Varnish من أحد الرواد في هذا المجال. ليس لأنه مفتوح الشفرة، بل من أجل كفائته العالية جدا.

مزودي خدمات الإنترنت والجامعات يستخدمون Forward caching فيما يتعلق بتصفح المواقع في فضاء الإنترنت. ولكن هذا ليس موضوعنا.

أشكرك جزيلا على مشاركتك فلولاها لما قمت بتوضيح هذه النقطة لأنني اعتبرته من البديهيات لكن لم أكن مصيبا.

تم تعديل هذه المشاركة بواسطة eech55 في 30 يوليو 2009 في 05:13

إذا نفعتك أحد مشاركاتي فأدع بظهر الغيب لوالداي بالصحة والسلامة والسعادة وطول العمر وأن يكون هذا زيادة لهما في كل خير.

before asking: smart questions how-to

#431 يوليو 2009 في 09:14

طريقة التثبيت مع FreeBSD

cd /usr/ports/www/varnish
make
make install

وهكذا ينزل لك البرامج من الإنترنت، يقوم بإعاده، compile وثم تثبيته تلقائيا.

Debian & Ubunto

ونفس الشيء ينطبق على توزيعات اللينوكس كل واحدة لها طرقها الديناميكية الخاصة، مثلا ubuntu أو debian

apt-get install varnish

سيقوم بالتنزيل وتثبيت الـbinary. أسهل من هذا؟ يجيني حد ويقولي اليونكس أو اللينوكس صعب :unsure:

التثبيت بطريقة يدوية

تقريبا كل نظام شبيه باليونكس يستخدم نظام لإدارة هذه العمليات بالسهولة التي رأيتموها بالأعلى. اذا كان حظك سيئ ولم يتوفر البرنامج على توزيعتك أو نظامك، ممكن تقوم بطريقة يدوية:

حمل الملف من موقع sourceforge، م فك الضغط بالأمر tar -xzf file_name_here

./configure
make
make check
make install

ملفات الإعدادات (فقط حتى تعلم أين مكانها للدرس اللاحق)

ملفات الإعدادات مع نظام FreeBSD ستكون في

/usr/local/etc/varnish

بالنسبة لـUbuntu ستكون في

/etc/varnish

بالنسبة للطريقة اليدوية ستكون في

/usr/local/etc

في الحقيقة، هو "ملف" اعدادات، وليس "ملفات". الملف اسمه default.vcl وبه اعدادات بسيطة هي عبارة عن default values _إذا_ لم نذكرها.

في الرد التالي بإذن الله سأتحدث عن الجمال الذي بإمكان أصابعنا أن تحيكه من خلال الـVarnish Configuration Language والذي سيكون في default.vcl.

إذا نفعتك أحد مشاركاتي فأدع بظهر الغيب لوالداي بالصحة والسلامة والسعادة وطول العمر وأن يكون هذا زيادة لهما في كل خير.

before asking: smart questions how-to

#54 أغسطس 2009 في 21:03

طريقة الإعداد:

لغة VCL شبيهة بلغات البرمجة، لكن طبعا بسيطة جدا ولا تتطلب أي دراية بالبرمجة. هناك عدة functions أو subroutines موجودة في ملف الـVCL. من أهمهم التالي:

vcl_recv

عندما يقوم الـclient بـhttp request، سيستقبله varnish ويمرره إلى function اسمه "vcl_recv". بداخل هذا الـfunction نحدد كيفية التعامل مع الطلبات المستقبلة. مثلا: هل ننظر إلى الكاش أولا؟ أم نرسله مباشرة إلى الخادم المسؤول متجاهلين الكاش؟ أم نعدل في الهيدر وثم نتابع؟)

vcl_fetch

اعتمادا على حصيلة vcl_recv، إذا تم تمرير الطلب إلى الخادم في المؤخرة، وقام الخادم بإرسال الرد، هنا سيستقبل varnish من خلال "vcl_fetch". وهنا بإمكاننا تحديد ماذا سنفعله بالرد العائد من الخادم (هل نخزنه في الكاش؟ أم نمسح الكوكي وثم نخزنه؟ أم نرسله فقط للعميل دون كاشينج؟).

غيرهم

هناك تسعة functions آخرين لكن لن اذكرهم من باب التبسيط، خاصة أن معظم الإستخدامات تكتفي بـvcl_recv و vcl_fetch.

مثال 1:

vcl_recv {

if (req.url ~ ".php"){

//صفحة ديناميكية لا تستحق حتى مضيعة الوقت في النظر إلى الكاش

return (pass); //هكذا سيتم تمريره إلى الخادم، دون حتى النظر داخل الكاش.لا فائدة في النظر داخل الكاش فهي قطعا ديناميكية ليست موجودة

}

return (lookup); //أي ملف آخر سيتم النظر للحصول عليه داخل الكاش. إذا لم يتوفر سيتم تلقائيا بإرساله إلى الخادم المصدر.

}

vcl_fetch {

if (req.url ~ ".php"{

return (pass); //بعد استقبال الرد من الخادم، أيضا ارسله إلى العميل. لا داعي لتخزينه في الكاش من باب الحفاظ على المساحة

}

set obj.ttl = 2h; //أي ملف آخر سيتم اعطائه عمر ساعتين داخل الكاش الزاميا

return (deliver); //هنا يقوم فعليا بتخزينه في الكاش و ارساله إلى العميل

}

مثال ESI

صفحة الـ index.html أو Index.php مافرقت. لا تحتوي على الموقع، إنما تحتوي على كود ESI وبداخله روابط لصفحات ديناميكية أخرى، وهكذا سنقوم بتقسيم single html object إلى multiple objects. مما سيتيح للreverse cache proxy التعامل مع كل واحد بالأسلوب الأنسب. هذا المثال بسيط جدا. فكل الذي نقوم بطباعته هو الوقت الحالي. الهدف من طباعة الوقت الحالي هو من باب التجربة لمعرفة كم قدم الجزء الذي نراه من الكاش حتى نتأكد أن الـttl بالضبط كما نريده.

هذه صفحة الـindex.html:

<HTML>

<HEAD>

<TITLE>Modular Page Test</TITLE>

</HEAD>

<BODY>

Hi, Welcome to my 1st ESI site powered by Varnish.

This timestamp is updated lively:

<esi:include src="stamp1.cgi"/>

<hr>

This timestamp is updated every 10sec:

<esi:include src="stamp2.cgi"/>

<hr>

This timestamp is updated every 20sec:

<esi:include src="stamp3.cgi"/>

<hr>

</BODY>

</HTML>

لاحظ لغة الـESI واستخدام الـinclude. هناك أوامر أخرى مختلفة عن الـinclude، لكن هذا هو أهمها. هذا ليس HTML وغير صالح للإرسال إلى العميل، بل يجب إرساله إلى الـreverse cache server حتى يقوم بالمعالجة والتركيب تباعا. ملفات الـCGI المذكورة في الـinclude بالأعلى هي ثلاث ملفات بالأسماء المذكورة سابقا، لكن محتواها نفس الشيء وهو:

#!/usr/bin/perl

print "Content-type: text/html\n\n";

sleep 5; //تعمدت ادخال تأخير خمسة ثواني حتى نشعر بزيادة السرعة بطريقة أكبر بواسطة الكاشينج. في البيئات العملية سيكون هناك تاخير ناتج من نالضغط على قاعدة البيانات او خادم الموقع، ولخلق تأخير شبيه وضعت هذا التأخير

print `date`;

والإعدادات من طرف الخادم ستكون:

vcl_recv { // الطلبات المستقبلة من الكلاينت تأتي هنا

return (lookup);// قم بسؤا ل الكاش فيما إذا كان هناك نسخة لم ينقضي عمرها. لكن إذا لم تكن النسخة المطلوبة موجودة، فحينها انتقل إلى فانكشن في إل سي_فيتش

}

vcl_fetch { // في حال قام الفنكشن بالأعلى عملية لوكب ولم يجد في الكاش مايريد، حينها سيأدي دور هذا الفنكشن لسحب الأبجكت مباشرة من الخادم

if (req.url == "index.html"){ // عندما يكون اليو آر إل المطلوب هذا، سيتم تطبيق ما بالأسفل

esi; // تم تفعيل خاصية إي إس آي. فبالتالي سيقوم البروكسي بقراءة ممحتوى الموقع وتطبيق أوامر إي إس آي

set obj.ttl=24h; // سنضع عمر هذا الملف في الكاش مدة يوم كامل، لأننا نادرا ما نقوم بتغيير محتوى الملف الأساسي من باب تخفيف الضغط على الخادم

return (deliver); // بعدما قمنا بإعطائه عمر 24 ساعة، سيقوم هذا بتخزينه في الكاش مع ذلك العمر، وبعدها سيتم تمريره للعميل بعدما تتم معالجة محتواه بـإي إس آي

}

if (req.url == "stamp1.cgi"){ // عندما يكون اليو آر إل المطلوب هذا، والذي سيطلبه ليس العميل، بل الخادم نفسه، بواسطة تطبيقه لأوامر إي إس آي الموجودة في ملف الإندكس بالأعلى

return (pass); //سيقوم بتمريره إلى المستخدم مباشرة دون حتى تخزينه بالكاش

}

if (req.url == "stamp2.cgi"){ // عندما يكون اليو آر إل المطلوب هذا، والذي سيطلبه ليس العميل، بل الخادم نفسه، بواسطة تطبيقه لأوامر إي إس آي الموجودة في ملف الإندكس بالأعلى

set obj.ttl=10s; //هذا الجزء ديناميكي وشديد التغيير. سنجعل عمره 10ثوانی

return (deliver); //بعدما تم تغيير عمره بالأعلى، سيقوم الآن بتخزينه بالكاش، وثم تمريره للعميل

}

if (req.url == "stamp3.cgi"){ // عندما يكون اليو آر إل المطلوب هذا، والذي سيطلبه ليس العميل، بل الخادم نفسه، بواسطة تطبيقه لأوامر إي إس آي الموجودة في ملف الإندكس بالأعلى

set obj.ttl=20s; //كسابقه، لكن معدل تغييره اقل، لذا سنخفف الضغط على الخادم وقاعدة البيانات من خلال استخدام نسخة الكاش 20 ثانية

return (deliver); //بعدما تم تحديد الزمن على هذا الأبجك، سيتم تخزينه بالكاش مع عمر يعادل عشرين ثانية، وثم تمريره للزائر

}

return (deliver); //أي شيء آخر لا تقم بتغيير عمره، قم بتخزينه إذا قابل للتخزين (صفحة ثابتة) وثم قم بتمريره

}

ملاحظة: عند تفعيل خاصيةESI سيقوم الخادم بمعاينة اكواد ESI بطريقة recursive إلى خمسة مستويات حسب الإعدادات الإفتراضية.

وعند الزائر، لن يحس بأي شيء سوا زيادة سرعة التصفح، والصفحة التي سيشاهدها ستكون كالتالي:

<HTML>

<HEAD>

<TITLE>Modular Page Test</TITLE>

</HEAD>

<BODY>

Hi, Welcome to my 1st ESI site powered by Varnish.

This timestamp is updated lively:

Tue Aug 4 21:40:20 UTC 2009

<hr>

This timestamp is updated every 10sec:

Tue Aug 4 21:40:21 UTC 2009

<hr>

This timestamp is updated every 20s:

Tue Aug 4 21:40:22 UTC 2009

<hr>

</BODY>

</HTML>

عندما يقوم الزائر بـrefresh سيجد أن الtimestamp الأول يتغير في كل مرة (ليست في الكاش) بينما الثاني والثالث لن يتغير. إذا انتظر 10 ثواني وثم ريفريش، سيتغير الأول والثاني (الثالث لن يتغير لأنه مازال بالكاش)، واذا انتظر 20، وثم ريفريش، سيتغيرون جميعا. فكرة استخدام الـtimestamp فقط من أجل اختبار أن الآلية تعمل 100% بالضبط كما نتوقعها.

ونحن كإداريين على الخادم سنلاحظ تخفيف الضغط على قاعدة البيانات وخادم الموقع لأنه بات يعالج فقط الأجزاء شديدة التغيير، وليس دائما الصفحة كاملة حيث أنه لا يوجد داعي. هذه الخاصية أيضا متوفرة مع Big IP WebAccelerator و Squid-Cache v3 لكن الأخير تطبيقه مازال experimental.

تم تعديل هذه المشاركة بواسطة eech55 في 15 سبتمبر 2009 في 03:37

إذا نفعتك أحد مشاركاتي فأدع بظهر الغيب لوالداي بالصحة والسلامة والسعادة وطول العمر وأن يكون هذا زيادة لهما في كل خير.

before asking: smart questions how-to

#64 أغسطس 2009 في 21:33

طريقة التشغيل

بعدما تم الإعداد كما هو بالأعلى، يبقى علينا تشغيل الـبرنامج.

تلقائيا

من خلال rc script، تاتي جاهزة مع freeBSD، كل ماعليك هو تعديل ملف

/etc/rc.conf

وإضافة التالي:

varnishd_enable="YES"
varnishd_flags="-P /var/run/varnishd.pid -a :80 -u www -g www -f /path/to/my/config/vcl

-u هو المستخدم الذي من خلاله سيكون فعالا. سيستمع على المنفذ 80 على جميع أرقام الـIPs، طبعا ممكن تحديد رقم معين بكتابته قبل علامة النقطتين. وأخيرا ملف يتم كتابة الـprocess ID فيه. الملف varnishd.pid ماهو إلى ASCII file يحتوي على رقم معادل للـprocess ID ليسهل عملية غلق البرنامج بواسطة اسكربتات أخرى.

يدويا:

ممكن تمرر نفس الإعدادات بالأعلى ويكون شكله كالتالي:

varnishd -P /var/run/varnishd.pid -a :80 -u www -g www -f /path/to/my/config.vcl

أو ممكن تشيل بعض الأوامر من باب التبسيط، لأننا عادة بالتشغيل اليدوي نقوم بالتجارب ولا داعي للتفاصيل الزائدة، فممكن نصغره إلى

varnishd -a :80 -f /path/to/my/config.vcl

وطبعا الـvarnishd هو binary قابل للوصول إليه حسبما هو مذكور في الـPATH env variable.

العميل:

العميل يكتب في متصفح الإنترنت رقم الـIP او domain المشيرين إلى varnishd.

ماذا بعد؟

هناك احتمالات أخرى ممكن تجربوها إذا احتجتموها. من أحد الإختيارات المسلية هو أن varnish يحتوي على back end health check وممكن تختار الآلية الذي من خلاله سيتم توزيع الضغط كالـround robin أو بناءا على weight معينة.

مجموعة أوامر هنا: http://varnish.projects.linpro.no/wiki/VCL

تم تعديل هذه المشاركة بواسطة eech55 في 4 أغسطس 2009 في 21:30

إذا نفعتك أحد مشاركاتي فأدع بظهر الغيب لوالداي بالصحة والسلامة والسعادة وطول العمر وأن يكون هذا زيادة لهما في كل خير.

before asking: smart questions how-to

#713 سبتمبر 2009 في 04:55

مشكور اخي الكريم على الموضوع القيم جدااً ..

وعندي استفسار بسيط اذا الخادم عليه بيانات بعضها سريع التغير والبعض الاخر بطئ التغير .. هل يمكن فقط عمل الكاش لسريعة التغير واهمال الأخرى ؟؟

#813 سبتمبر 2009 في 11:05

alshalawy كتب:
مشكور اخي الكريم على الموضوع القيم جدااً ..
وعندي استفسار بسيط اذا الخادم عليه بيانات بعضها سريع التغير والبعض الاخر بطئ التغير .. هل يمكن فقط عمل الكاش لسريعة التغير واهمال الأخرى ؟؟

طبعا ممكن. القضية مرنة جدا.

إذا نفعتك أحد مشاركاتي فأدع بظهر الغيب لوالداي بالصحة والسلامة والسعادة وطول العمر وأن يكون هذا زيادة لهما في كل خير.

before asking: smart questions how-to

#914 سبتمبر 2009 في 03:24

الذي تريده موجود ومشروح في الدرس.

أظن أنك لم تقرأه لأن التنسيق لم يتوافق جيدا مع ملف القوالب الجديد للمنتدى.

لذا قمت بتعديل التنسيق في شرحي السابق تماشيا مع القالب الحالي.

إذا نفعتك أحد مشاركاتي فأدع بظهر الغيب لوالداي بالصحة والسلامة والسعادة وطول العمر وأن يكون هذا زيادة لهما في كل خير.

before asking: smart questions how-to

#1014 سبتمبر 2009 في 23:20

أشكرك بشدة

لم أكمل قراءة الدرس

لكن هل لي بسؤال بسيط .. لماذا تعتمد في معظم دورسك على التوزيعات المبنية على ديبيان ؟

ربما لأن معظم تجاربي أفضلها على توزيعات مبنية على الريدهات .. فيدورا أو غيرها مما يستخدم الـ rpm فأنا أفتقد تلك الجزئية .

تحياتي ،،

System Administrator

#1115 سبتمبر 2009 في 03:00

لا شكر على واجب يا سيدي..

اقتباس
لكن هل لي بسؤال بسيط .. لماذا تعتمد في معظم دورسك على التوزيعات المبنية على ديبيان ؟

لماذا تشتمني؟ :lol:

دبيان واحدة منهم، حتى الآن تطرقت لـ:

1- FreeBSD وهذا شخصيا افضله فوق اللينكس. لكن ليس منتشرا بين العرب (شريحة هذا المنتدى).

2- Debian ومشتقاته. كنموذج للينكس.

3- Gentoo آحیانا فی بعض الدروس. شخصيا افضله فوق دبيان لكن المستخدم العربي لا يستخدمه،

4- الطريقة اليدوية والتي معظم الأحيان تعمل عند الجميع.

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

تم تعديل هذه المشاركة بواسطة eech55 في 15 سبتمبر 2009 في 03:01

إذا نفعتك أحد مشاركاتي فأدع بظهر الغيب لوالداي بالصحة والسلامة والسعادة وطول العمر وأن يكون هذا زيادة لهما في كل خير.

before asking: smart questions how-to

#1229 فبراير 2012 في 20:32

شرح رائع اخي الكريم

جزاك الله خيرا

بالنسبة لعمليه التنزيل علي الريدهات او السنتوس يتم استخدام ال yum

و يختلف مسار ملف الاعداد او قد يكون مثل الاوبنتو

و محتويات ملف الاعداد تكون مثل ما هي موجودة بالموضوع بالاعلي

لك تحياتي

Linux System Admin

Reverse Cache - Varnish

مواضيع مشابهة