إلى أي مدى يمكن أن يساعد التحكم في الإصدار في إدارة النظام؟
https://stackoverflow.com/questions/453300
-
19-08-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
أقوم حاليًا بترقيع نظام OpenBSD بهدف بناء جدار حماية لنفسي وبعض الأجزاء والأجزاء الأخرى.
نظرًا لأن هذا تجريبي إلى حد ما (أنا OpenBSD n00b، وقد قمت بالفعل بتدمير نظامي 3 أو 4 مرات)، فأنا أتساءل ما هي الخبرة التي يتمتع بها الآخرون في إنشاء جزء من نظام الملفات أو كله (أفكر بشكل خاص في /etc) نسخة عمل من بعض VCS أو غيرها.
هل هذه فكرة جيدة؟
أنا مهتم بشكل خاص بمعرفة الأشخاص الذين استخدمهم VCS لهذا الغرض.أنا أفكر في التخريب والبازار والجيت؛لن يكون هذا مستودعًا مشتركًا، لذلك ربما أكون مهتمًا بوظيفة vcs الأساسية أكثر من الوسيطة الموزعة أو غير الموزعة.
أود أيضًا أن أسمع عن المخاطر المتخيلة أو الفعلية التي وجدها الأشخاص.أستطيع أن أتخيل أن الحفاظ على ملكية الملفات والأذونات يحتاج إلى تفكير متأني!
وبطبيعة الحال، أي أساليب بديلة لا تنطوي على VCS
نصائح أخرى
بالنسبة لما تفعله، أقترح عليك بدلاً من البدء من OpenBSD أن تبدأ من التوزيعة التي تم بالفعل إنجاز الكثير من العمل فيها مثل com.pfsense.
أما بالنسبة لـ VCS نفسها فقد ترغب في أخذها بعين الاعتبار زئبقي الذي يتم استخدامه بنجاح من قبل هذه المشاريع
لا أعتقد أن أحداً ذكر ذلك etckeeper حتى الآن.
يقوم بتخزين /etc في اتفاقيات إعادة الشراء (git (افتراضي) أو Mercurial أو bzr).فهو يحل مشاكل الحفاظ على ملكية الملفات والأذونات والأدلة الفارغة.يمكن أن يتكامل مع package managermnet (على الأقل مع apt) لتنفيذ التغييرات تلقائيًا على /etc التي تحدث أثناء تثبيت حزمة جديدة.جيد جدًا إذا كان التثبيت يخالف التغييرات التي أجريتها، فما عليك سوى التراجع.
لقد استخدمته بنجاح في Ubuntu لفترة من الوقت.
لقد قرأت شيئًا عن ذلك في "Gnu/Linux Magazine France".يستخدم الرجل rsync من /etc إلى الجذر/ ثم يخزنه عبر التخريب، دون إنشاء نسخة عمل.
سأقتبس قليلا من المجلة.
حسنًا، في المثال، يقوم الخادم بتشغيل freeBSD وهو "متألق"، في حين أن الجهاز الذي سيتم حفظه موجود تحت نظام دبيان وهو "نسخة طبق الأصل".إنشاء مستخدم "نسخة طبق الأصل".
في /usr/local/etc/ssh/sshd_config أضف:
Match User replica
X11Forwarding no
AllowTcpForwarding no
ForceCommand /usr/local/bin/svnserv -t -r /home/replica/svnrepo -tunnel-user=replica
إنشاء المستودع
Sparky # svnadmin create /home/replica/svnrepo
إصلاح الحقوق:
sparky # chown -R replica:nogroup /home/replica
sparky # chown -R o-rwx /home/replica
sparky # chown -R g-rwx /home/replica
جانب العميل:
تثبيت التخريب
replica # mkdir -p /root/scripts/svnrepo
replica # rsync -av /etc /root/scripts/svnrepo
export SVN_SSH ="ssh -i /root/.ssh/id_rsa"
svn import -m "replica config files" /root/scripts/svnrepos svn+ssh://replica@sparky/home/replica/svnrepo
الآن، مجلدنا ليس نسخة صالحة للعمل بعد، لذا يتعين علينا إنشاءه.هل يمكنك إنشاء ملف .svn؟لا يستطيع :)
cd /root/scripts
mv svnrepo svnrepo.old
svn checkout svn+ssh://replica@sparky/home/replica/svnrepo
حاول الآن تعديل ملف ما، مثل المضيفين على سبيل المثال.
رسينك مرة أخرى.يجب أن تحصل فقط على الملف المعدل، الذي تم نسخه /etc/hosts.
الآن يمكنك الالتزام بما يلي:
svn commit -m "backup 1" /root/scripts/svnrepo
هناك شيء أخير.إذا كنت تريد أن يتم الاستيلاء على ملف عن طريق التخريب، فيجب إضافته.لذلك، على سبيل المثال، إذا قمت بإنشاء ملف جديد في /etc، فلن يتم حفظه افتراضيًا.
ما الذي يجب فعله؟
svn status /root/scripts/svnrepo | grep -e '^!' | awk '{ print $2 }' | xargs -r svn delete
svn status /root/scripts/svnrepo | grep -e '^?' | awk '{ print $2 }' | xargs -r svn add
ثم عليك أن تصنع البرنامج النصي الخاص بك.
أتمنى أن يساعدك هذا.
(gtg، سأقوم بالتحرير لاحقًا لتعيين العناوين وبالتالي عنوان واحد إذا لم يفعل أحد ذلك)
كل شيء في /etc على كل خادم أديره (300+ وما زال العد) موجودًا تحت زئبقي.لماذا؟
- إنه سهل الاستخدام لأي شخص سبق له استخدام SVN أو CVS (إذا لم تقم بذلك، فلن يكون لديك عمل في / وما إلى ذلك على آلات الإنتاج الخاصة بي)
- إنه يجعل من السهل سحب التغييرات من تكوين خادم واحد إلى العديد من الخوادم الأخرى
- يمكنني التراجع بسرعة عندما يصاب المشرفون الآخرون بضرطة في الدماغ
كان Git مجرد قوة كبيرة جدًا مقابل القليل جدًا من المشكلة في هذه الحالة.نظرًا لأن HG عبارة عن DVCS، فإن عمليات الالتزام والتراجع تكون نظيفة وسهلة.أنا أيضا استخدم HG ل إدارة معظم مواقع الويب الخاصة بي.
لا يقتصر الأمر على الكود المصدري فقط :) هناك خيار أساسي آخر يتمثل في استخدام نوع ما من نظام ملفات الإصدار الذي يأخذ لقطات عند الكتابة (CoW)، وهو أسهل بكثير من DVCS.
تعليق:ما انتهى بي الأمر إلى فعله
(@Aif، شكرًا على التذكير اللطيف بأن أخلاقي الحميدة كانت مفقودة بعض الشيء)
لقد استخدمت /etc كمستودع git، ولكن بما أنني لا أزال غير مرتاح قليلاً مع هذا (أنا، وليس git)، فأنا أقوم بالعمل gitwork يدويًا.
كأثر جانبي، بدأت نفسي في مشروع صغير لتقييم، جنبًا إلى جنب، Subversion، git، bazaar، mercurial، monotone، darcs، وfossil، على الرغم من أنه في سياق إدارة إصدار أكثر عمومية (عمليات الدمج وما شابه).
ردود أفعالي على إجاباتك
شكرا لكم جميعا لمساعدتكم.لقد واجهت بعض الصعوبة في اختيار الإجابة التي سأقبلها، لذا إذا لم تكن إجابتك، فيرجى صدقني، فأنا أقدر إجابتك أيضًا.
@لويس ميلجراتي
لويس، شكرًا لك على بعض المراجع الممتازة.لقد قبلت إجابتك باعتبارها الأكثر فائدة.
@كونراد
كونراد، وأنا أقدر كل من اقتراحاتكم.
سأحقق بالتأكيد com.pfsense, ، على الرغم من أن أحد أهدافي في هذا هو جعل يدي متسخين حقًا، بالإضافة إلى بناء جدار حماية، لذا فإن "التصنيع بدلاً من الاكتساب" هو المهم.
أما بالنسبة لـ Mercurial، فلم أدرجه في قائمتي لأنني جربته (سابقًا)، وشعرت أنني "أحب" البازار أكثر، بينما يبدو git للوهلة الأولى وكأنه يتمتع بقدر كبير من القوة (وهذا ما أعترف به قد لا تحتاج).إن VCS "الرئيسي" الخاص بي في الوقت الحالي هو Subversion، على الرغم من أنني لست متأكدًا من أنها إجابة جيدة لهذه الحالة.ومن هنا جاءت قائمة الثلاثة.
(لقد ألقيت الآن نظرة على pfsense وقمت بتشغيله على شبكتي.جيد جدًا، لكنني لست متأكدًا على الإطلاق من أنني سأتسخ يدي ولو قليلاً...)
@عيف
شكرا، ايف.سأحاول بالتأكيد تجربة ذلك، على الرغم من أنني أظن أنني سأنتهي بـ git.
@tinkertim
شكرًا لك على أفكارك حول Mercurial، والتي أخطط الآن لزيارتها مرة أخرى، على الرغم من أنني سعيد جدًا بـ Bazaar.
@لكل ويكلاندر
شكرا لاقتراح مثير للاهتمام للغاية!سأقوم بالتأكيد بإلقاء نظرة على etckeeper، عندما أتمكن من الخروج من تحت كومة العمل الحالية.
