Toolbox: اضبط مسار المنزل

عادةً ما أقوم فقط بعمل HOME=/home/user1/container1 قبل إنشاء الحاويات واستخدم اسمًا مستعارًا لفتحها. ( alias toolbox1='HOME=/home/user1/container1/toolbox "$@"' )

نعم ، يعد تجاوز $HOME إحدى طرق القيام بذلك.

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

لكن هذا لم ينجح تمامًا كما توقعت. بينما يحافظ Toolbox على نظام التشغيل المضيف نظيفًا ، فإنه لا يحافظ على نظافة الدليل الرئيسي على الإطلاق. لا يزال هذا ملوثًا تمامًا. على سبيل المثال ، باستخدام حاوية رميّة لبناء شيء يستخدم rust ، انتهى بيتي إلى التغيير بعدة طرق:

• تم إنشاء دليل ~/.cargo بصمت ، يحتوي على العديد من الثنائيات ذات الصلة بالصدأ ، وحزم المصدر ، وما إلى ذلك بإجمالي 123 ميجا بايت.
• تم إنشاء دليل ~/.rustup بصمت ، يحتوي على العديد من الثنائيات ذات الصلة بالصدأ ، بإجمالي 683 ميجابايت.
• تم تغيير ملف ~/.bash_profile الخاص بي بصمت لإضافة دليل ~/.cargo/bin إلى المسار $ PATH الخاص بي قبل كل شيء آخر.
• تم تغيير ملف ~/.profile الخاص بي بصمت لإضافة دليل ~/.cargo/bin إلى المسار $ PATH الخاص بي قبل كل شيء آخر.
• من يعرف ماذا ايضا.

ييكيس. ما كان من المفترض أن يكون نظامًا مؤقتًا ورميًا وسهل الإهمال أدى إلى إجراء العديد من التغييرات الدائمة بصمت على دليل منزلي. أدرك الآن من التعليقات أعلاه أنه يمكنني تجاوز متغير البيئة $ HOME يدويًا لمحاولة حل هذا الأمر ، لكن هذا لم يكن بديهيًا أو متوقعًا بالنسبة لي. نظرًا لأنه من المفترض أن يكون Toolbox (أو على الأقل كما أفهمها) طريقة مبسطة وسهلة الاستخدام للوصول إلى الحاويات ، سأكون ممتنًا لو أمكن التعامل مع هذا بطريقة أفضل.

رأيي هو أنه من المحتمل أن يكون لـ Toolbox دليل مستخدم فريد ودليل رئيسي خاص به. ولكن إذا كان هذا معقدًا للغاية بحيث يتعذر تنفيذه ، فربما يكون هناك على الأقل وسيطة -h أو --home عند إنشاء مربع أدوات جديد ، لتعيين $ HOME الافتراضي الخاص به؟ لذلك عند دخولك إلى مربع الأدوات في المستقبل ، سيتم تعيين قيمة $ HOME تلقائيًا. على سبيل المثال ، شيء على غرار toolbox create -c temp-myproject -h ~/Toolboxes/temp-myproject .

بشكل أساسي ، أعتقد أنه سيكون من الرائع أن يكون لدى Toolbox طريقة سهلة الاستخدام لإعداد حاوية في أحد الأوضاع الثلاثة:

1. الوضع السلس: كيف يعمل الآن. يتصرف مستخدم الحاوية كما لو كان مستخدمًا مضيفًا حقيقيًا ، ويشارك دليلك الرئيسي.
2. الوضع شبه المعزول: يمكن للحاوية الوصول إلى ملفات المستخدم المضيف ، ولكن لديها دليل رئيسي خاص بها للبرنامج لاستخدامه افتراضيًا. ستحتاج إلى الوصول يدويًا إلى الدليل الرئيسي للمستخدم المضيف إذا كنت تريد القراءة / الكتابة إليه. سيكون بشكل أساسي مثل الوضع السلس أعلاه ، ولكن مع دليل العمل المنفصل الخاص به.
3. الوضع المعزول بالكامل (غير موثوق به): سيكون للحاوية دليل مستخدم ودليل رئيسي منفصل ، مع عدم وجود وصول مطلقًا إلى الدليل الرئيسي للمستخدم المضيف. سيكون هذا مفيدًا لتشغيل البرامج غير الموثوق بها ، والتي لا تريد السماح لها بقراءة كل شيء في دليل منزلك.

هذا يبدو معقولا جدا بالنسبة لي. ما رأيكdebarshiray ؟؟

أنا أدعم هذا JaneSmith ، كل ما أحتاجه - ضع بلطف!

أنا أؤيد الفكرة أيضًا. ولكن حتى يتم تنفيذه ، يمكنك استخدام direnv . إنها أداة يدوية تسمح للشخص بتحديد متغيرات البيئة على أساس كل دليل. يمكنك استخدام تدفق العمل التالي

- install direnv and hook it to your shell
- create a temporary directory eg. ~/somedev
- add a .envrc file with the environment variables you want (in this case HOME=/home/user/somedev

الآن في كل مرة تدخل فيها إلى الدليل somedev ، ستفترض أنه الدليل الرئيسي وستعيد تعيينه عند الخروج منه. يمكنك القيام بجميع الخطوات بعد تثبيت direnv بأمر واحد مثل:

"" باش
mkdir ~ / somedev && echo export HOME = / home / user / somedev> ~ / somedev / .envrc
""
أنا حاليا أستخدم تدفق عمل مماثل.

أوافق على أنه يجب أن يكون هناك على الأقل خيار لعدم تركيب دليل المنزل (راجع https://github.com/containers/toolbox/issues/183#issuecomment-623103780). في الواقع ، سأكون على ما يرام إذا كان يستخدم - على غرار flatpak - بعض dir في ~/.var/app ، ربما أفضل ~/.var/toolbox أو نحو ذلك ، حيث يتم حفظ جميع الملفات في home dir بشكل افتراضي.
يعجبني نموذج flatpak هذا تمامًا ، لأن لديك جميع البيانات من حاوية واحدة في مكان واحد ، وإذا قمت بحذف الحاوية ، يمكنك أيضًا حذف جميع بيانات التطبيق. (أو قم بقياس المساحة التي استهلكها مشروعك الجديد "لقد جربت الصدأ") ، على سبيل المثال (كما حدث في مركز التحكم في جنوم)

بعد ذلك ، للراحة ، من المحتمل أن يتم تثبيته دائمًا في $ PWD الحالي ، إذا قمت ببدء تشغيله من مجلد مشروع ، فمن المحتمل أن تتوقع أن يكون لديك الملفات هناك. فقط ، لا يحتاج مجلد ~/rust-project الخاص بك إلى أي وصول إلى ~/Pictures/private/… وما إلى ذلك.

على أي حال ، بالطبع يجب أن يكون المرء قادرًا على التثبيت في المنزل اختياريًا للقراءة فقط أو حتى قابل للكتابة ، لكنني لا أعتقد أن هذا مطلوب حقًا لمعظم التطبيقات.
ويجب أن يكون المرء قادرًا على عدم تحميل $PWD الحالي.

لذلك سيكون لديك "حل وسط" هنا كإعداد افتراضي جديد.

يحتوي tlbx fork على خيار -n لعدم ربط الدليل الرئيسي.

نسخة مكررة من https://github.com/containers/toolbox/issues/183

Noooo ... لا يزال بإمكانك الحصول على حالات / أسباب استخدام أخرى لامتلاك $ HOME مختلف ثم "بيئات تطوير معزولة للحماية من الأخطاء والبرامج الضارة في التعليمات البرمجية قيد التطوير" ...

IMHO ، لا تزال هذه ميزة يجب أن يمتلكها صندوق الأدوات.

لا أفهم سبب إغلاق هذه المشكلة. إنها ليست نسخة مكررة من ذلك. هذا لا يتعلق فقط بالأمن. آمل حقًا إعادة النظر في هذا الأمر لأنني أحب Fedora Silverblue وأحب أن يحتوي على أداة مدمجة لإعداد حاويات للحيوانات الأليفة ، لكنها لا تؤدي المهمة حاليًا. لا أريد أن أضطر إلى استخدام شوكة من أجل ذلك فقط ... أستخدم صندوق الأدوات لحاويات الحيوانات الأليفة للتعامل مع مشاريع البرمجة المختلفة ، ولا أريد أن يشوش دليل منزلي بالحاويات. لا علاقة له بالأمن.

JaneSmith لماذا لا تستخدم شوكة إذا كانت تحتوي على الميزات التي تحتاجها؟

أفضل استخدام Toolbox بدلاً من fork ، لأن Toolbox مدعومة بشكل أفضل مع المزيد من المطورين ، ويتم تضمينها مع Fedora خارج الصندوق. عندما أنتقل من آلة إلى أخرى ، يكون Toolbox موجودًا بالفعل ، دون الحاجة إلى تثبيت مفترقات. جزء من سبب استخدام Toolbox في المقام الأول هو تجنب ازدحام نظامي بتثبيتات البرامج العشوائية!

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

JaneSmith أوافق على جميع النقاط. أتوقع أن يتم تنفيذ الميزة في المرة الأولى التي يتم فيها الإعلان عن التصميم غير الآمن الحالي للعب دور في خرق أمني ، إن لم يكن قبل ذلك.

الجملة الأولى في المستندات تقول أنها تعمل _ بامتياز _. تبدو آمنة ، أليس كذلك؟

أيضًا في الوصف الرئيسي: _الهدف من هذه الأنظمة هو تثبيط تثبيت البرنامج على المضيف ، وبدلاً من ذلك تثبيت البرامج على أنها (أو في) حاويات. _ كما يجب أن يضيف هذا المشروع أمانًا كبيرًا.

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

الوضع الحالي ليس فقط غير آمن ، ولكنه مضلل للإبلاغ عن أن استخدام حاويات مثل هذه يوفر أمانًا كبيرًا ، في حين أنه من الصعب أن تتمكن الحاويات من الوصول إلى جميع ملفاتك!

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

أريد هذا أيضا. حل وسط (يمكن الوصول إليه من المنزل ، ولكن لم يتم تعريفه على أنه HOME) ، ووضع غير موثوق به (لا يمكن الوصول إلى المنزل على الإطلاق).

عادةً ما أقوم فقط بعمل HOME=/home/user1/container1 قبل إنشاء الحاويات واستخدم اسمًا مستعارًا لفتحها. ( alias toolbox1='HOME=/home/user1/container1/toolbox "$@"' )

إذا كان الحل الوسطي بهذه البساطة ... فلماذا لا يمكن تنفيذه في Toolbox كخيار؟ ما عليك سوى اتخاذ مسار المنزل كوسيطة عند إنشاء صندوق الأدوات وحفظه في مكان ما ، ربما بنفس طريقة حفظ اسم الحاوية. ثم اقرأ هذا المسار وقم بتعيينه عند دخول الحاوية ...

لجعل الأمور أكثر واقعية:

• --new-home والذي من شأنه أن يخبر صندوق الأدوات بعدم تحميل المضيف $ HOME (أو تثبيته في مكان آخر في الحاوية ليس $ HOME)
• --from-home path1:path2:pathN والذي من شأنه أن يخبر صندوق الأدوات بإدخاله لتحميل مسارات معينة من المضيف $ HOME إلى منزل الحاوية

لذلك على سبيل المثال ، إذا كان لدي أدلة مصدر في ~ / Projects ، فأنا بحاجة إلى تسجيل الأشياء باستخدام gpg وأحتاج إلى ssh للاتصال بخادم و git config الخاص بي ، يمكنني إنشاء صندوق أدوات مثل هذا:

toolbox create --new-home --from-home Projects:.ssh:.gnupg:.gitconfig

فهل هذا شيء سيتم قبوله في المنبع؟ حتى أنني سأعمل على هذا إذا كانت الخطة منطقية.