Toolbox: टूलबॉक्स कंटेनर के अंदर sudo(8) पॉडमैन 2.0.5 . के साथ पासवर्ड मांगता है

मैंने फेडोरा वर्कस्टेशन 32 और फेडोरा वर्कस्टेशन 33 (वर्चुअल मशीनों पर) पर कुछ परीक्षण किया और मैं पुष्टि कर सकता हूं कि एफ 32 पर ठीक काम कर रहा था, लेकिन एफ 33 पर मुझे एक ही समस्या मिली।
तो, यह फेडोरा 33 के साथ ही एक मुद्दा है, न कि केवल सिल्वरब्लू संस्करण के साथ।

कुछ परीक्षण के बाद मैंने कुछ अंतर देखे:

• पॉडमैन का संस्करण अलग है।
  
  
  
  • F32 : 2.0.2
  
  
  • F33 : 2.1.0-dev
  
  
• फ़ाइलें /etc/group और /etc/shadow अलग हैं।

फेडोरा 33 में टूलबॉक्स कंटेनर में उपयोगकर्ता का अपना समूह नहीं है और यह समूह wheel ।
साथ ही, उपयोगकर्ता के पास /etc/shadow फ़ाइल में कोई प्रविष्टि नहीं है और root उपयोगकर्ता के पास पासवर्ड लॉक है।

फेडोरा 32 और फेडोरा 33 के बीच /etc/group फ़ाइल (कंटेनर के अंदर) के लिए अंतर। उपयोगकर्ता के लिए उपयोगकर्ता नाम vagrant :

--- f32-image-f33/group 2020-08-14 19:19:38.734363987 +0000
+++ f33-image-f33/group 2020-08-14 19:17:39.018504713 +0000
@@ -8,7 +8,7 @@
 lp:x:7:
 mem:x:8:
 kmem:x:9:
-wheel:x:10:vagrant
+wheel:x:10:
 cdrom:x:11:
 mail:x:12:
 man:x:15:
@@ -26,4 +26,3 @@
 utempter:x:35:
 ssh_keys:x:999:
 tcpdump:x:72:
-vagrant:x:1000:

/etc/shadow लिए अंतर:

--- f32-image-f33/shadow    2020-08-14 19:15:25.125242112 +0000
+++ f33-image-f33/shadow    2020-08-14 19:17:11.658920405 +0000
@@ -1,4 +1,4 @@
-root::18488:0:99999:7:::
+root:!locked::0:99999:7:::
 bin:*:18473:0:99999:7:::
 daemon:*:18473:0:99999:7:::
 adm:*:18473:0:99999:7:::
@@ -12,4 +12,3 @@
 ftp:*:18473:0:99999:7:::
 nobody:*:18473:0:99999:7:::
 tcpdump:!!:18481::::::
-vagrant::18488:0:99999:7:::

समस्या अभी भी रॉहाइड (F33SB) में मौजूद है, टूलबॉक्स में प्रवेश करने पर संदेश के अपवाद के साथ (/usr/bin/id: समूह आईडी 1000 के लिए नाम नहीं ढूंढ सकता) अब पॉप अप नहीं हो रहा है।

मैं पुष्टि करता हूं कि मैंने भी त्रुटि देखी थी (/usr/bin/id: समूह आईडी 1000 के लिए नाम नहीं ढूंढ सकता) इसलिए मैंने फेडोरा-टूलबॉक्स-33 छवि को हटा दिया और टूलबॉक्स को फिर से बनाया लेकिन अब मैं sudo कमांड का उपयोग नहीं कर सकता। मैं अब फंस गया हूँ।

मैं दूसरे दिन किए गए निष्कर्षों का पालन करता हूं और मैं sudo काम करने का प्रबंधन करता हूं।

कदम:

(यह सब फेडोरा वर्कस्टेशन 33 में एक वीएम में)

1. कंटेनर बनाएं।

[vagrant@ci-node-33 ~]$ toolbox create
Created container: fedora-toolbox-33
Enter with: toolbox enter

1. toolbox साथ कंटेनर में प्रवेश करें और sudo कमांड का प्रयास करें:

⬢[vagrant<strong i="18">@toolbox</strong> ~]$ sudo ls

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for vagrant: 

यह विफल रहा! :निराश:

1. podman साथ कंटेनर में प्रवेश करें:

[vagrant@ci-node-33 ~]$ podman exec -it fedora-toolbox-33 /bin/bash

1. चूंकि उपयोगकर्ता के पास सही समूह नहीं थे और यह shadow फ़ाइल में नहीं था (जैसा कि मैंने पिछली टिप्पणी में दिखाया था), मैंने उसी कमांड का उपयोग करने की कोशिश करते हुए उपयोगकर्ता को हटा दिया और फिर से बनाया और पैरामीटर जो toolbox करता है ( init-container कमांड पर):

# Delete the user
⬢[root<strong i="32">@toolbox</strong> /]# userdel --force vagrant

# Create the user
⬢[root<strong i="33">@toolbox</strong> /]# useradd --home-dir /home/vagrant/ --no-create-home --shell /bin/bash --uid 1000 --groups wheel vagrant

# Check the user groups (this time are OK)
⬢[root<strong i="34">@toolbox</strong> /]# id vagrant
uid=1000(vagrant) gid=1000(vagrant) groups=1000(vagrant),10(wheel)

# Delete the user password
⬢[root<strong i="35">@toolbox</strong> /]# passwd --delete vagrant
Removing password for user vagrant.
passwd: Note: deleting a password also unlocks the password.
passwd: Success

# Check that the user is at the file /etc/shadow (this is important for PAM authentication and sudo)
⬢[root<strong i="36">@toolbox</strong> /]# grep vagrant /etc/shadow
vagrant::18493:0:99999:7:::

# Logout from the container
⬢[root<strong i="37">@toolbox</strong> /]# exit
[vagrant@ci-node-33 ~]$ 

1. toolbox का उपयोग करके कंटेनर में प्रवेश करें और sudo कमांड का प्रयास करें:

[vagrant@ci-node-33 ~]$ toolbox enter
⬢[vagrant<strong i="44">@toolbox</strong> vagrant]$ sudo id

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

uid=0(root) gid=0(root) groups=0(root)

अब यह काम कर रहा है! :मुस्कुराओ:

निष्कर्ष

कुछ उपयोगकर्ता पीढ़ी पर गलत जाने के लिए, पर लगता है init-container आदेश (कहीं आसपास यहाँ )।

इसकी रिपोर्ट करने और अपराधी को खोजने का प्रयास करने के लिए धन्यवाद! ऐसा लगता है कि रॉहाइड में पॉडमैन ने कंटेनर बनाते समय --userns=keep-id विकल्प को संभालने के तरीके को बदल दिया। यह अब उपयोगकर्ता और समूह बनाता है। पहली समस्या इस कार्यक्षमता से संबंधित प्रतीत होती है क्योंकि उपयोगकर्ता समूह का सही GUID होने के बावजूद कोई नाम नहीं है (मैंने बताया कि अपस्ट्रीम: https://github.com/containers/podman/issues/7389)।

दूसरा भाग ( सुडो के लिए पासवर्ड टाइप करना) इस तथ्य के कारण होता है कि नहीं होता है। वह कोड उपयोगकर्ता बनाने, उसे सही समूहों में जोड़ने और उपयोगकर्ता और रूट के लिए पासवर्ड हटाने का ख्याल रखता है। मुझे लगता है कि init-container कमांड में कोड को थोड़ा पुनर्गठित करने की आवश्यकता है ताकि ऐसे मामलों को भी बुलाया जा सके।

ऐसा लगता है कि रॉहाइड में पॉडमैन ने रास्ता बदल दिया
यह बनाते समय --userns=keep-id विकल्प को संभालता है
कंटेनर। यह अब उपयोगकर्ता और समूह बनाता है। NS
पहली समस्या इस कार्यक्षमता से संबंधित प्रतीत होती है
स्वयं क्योंकि उपयोगकर्ता समूह का कोई नाम नहीं है
सही GUID होने के बावजूद (मैंने बताया कि अपस्ट्रीम:
कंटेनर/पॉडमैन#7389)।

ऐसा लगता है कि यह वास्तव में समूह नहीं बना रहा है। नहीं तो आपका एक नाम होता। यह सिर्फ उपयोगकर्ता बना रहा है।

मुझे आश्चर्य है कि क्या यह एक होम डायरेक्टरी भी बना रहा है। मुझे आशा नहीं है।

https://github.com/containers/podman/pull/6829 अपमानजनक पॉडमैन परिवर्तन था।

यह मेरे लिए अब सिल्वरब्लू 32 पर फेडोरा- टूलबॉक्स का उपयोग करके हो रहा है
टूलबॉक्स संस्करण: 0.0.93
पॉडमैन संस्करण: 2.0.5

यह मेरे लिए अब सिल्वरब्लू 32 पर फेडोरा- टूलबॉक्स का उपयोग करके हो रहा है
टूलबॉक्स संस्करण: 0.0.93
पॉडमैन संस्करण: 2.0.5

हाँ, मेरे पास सिल्वरब्लू 32 पर अब F32 के किसी भी नए टूलबॉक्स इंस्टेंस पर समस्या है। पुराने टूलबॉक्स इंस्टेंस के साथ, यह अभी भी काम करता है, लेकिन नई रचनाओं के साथ नहीं। तो, इसे "ठीक" करने के लिए जो कुछ भी किया गया था, उसे F32 पर तोड़ दिया।

फेडोरा 32 एसबी पर टूलबॉक्स 0.0.93 और पॉडमैन 2.0.5 के साथ इस मुद्दे की पुष्टि कर सकते हैं।

यह केवल फेडोरा से संबंधित या सीमित नहीं है, टूलबॉक्स 0.0.94 के साथ आर्क और पॉडमैन 2.0.5 में एक ही समस्या है।

यह मेरे लिए अब सिल्वरब्लू 32 पर फेडोरा- टूलबॉक्स का उपयोग करके हो रहा है
टूलबॉक्स संस्करण: 0.0.93
पॉडमैन संस्करण: 2.0.5

ऐसा इसलिए है क्योंकि पॉडमैन 2.0.5 फेडोरा 32 में फिसल गया।

क्या इस तरह के प्रतिगमन को पकड़ने के लिए पॉडमैन या टूलबॉक्स के लिए कुछ परीक्षण जोड़ना संभव है? सिल्वरब्लू वास्तव में किसी को टूलबॉक्स का उपयोग करने के लिए प्रोत्साहित करता है, और ऐसा होने के लिए टूलबॉक्स को ग्नोम-टर्मिनल जितना ही विश्वसनीय होना चाहिए।

क्या पॉडमैन या टूलबॉक्स के लिए कुछ परीक्षण जोड़ना संभव है
इस तरह प्रतिगमन पकड़ो? सिल्वरब्लू वास्तव में प्रोत्साहित करता है
टूलबॉक्स का उपयोग करने के लिए एक, और उसके लिए टूलबॉक्स की आवश्यकता है
ग्नोम-टर्मिनल की तरह ही विश्वसनीय होने के लिए।

यह आश्चर्यजनक रूप से कठिन लड़ाई साबित हुई है कि पॉडमैन टीम को पश्चगामी संगतता की देखभाल करने के लिए या यह जांचने के लिए कि कुछ परिवर्तन टूलबॉक्स को तोड़ता है या नहीं। @HarryMichal लगातार टूटने का पीछा कर रहा है और परीक्षणों पर जोर दे रहा है, लेकिन प्रगति धीमी है।

क्या पॉडमैन या टूलबॉक्स के लिए कुछ परीक्षण जोड़ना संभव है
इस तरह प्रतिगमन पकड़ो? सिल्वरब्लू वास्तव में प्रोत्साहित करता है
टूलबॉक्स का उपयोग करने के लिए एक, और उसके लिए टूलबॉक्स की आवश्यकता है
ग्नोम-टर्मिनल की तरह ही विश्वसनीय होने के लिए।

यह आश्चर्यजनक रूप से कठिन लड़ाई साबित हुई है कि पॉडमैन टीम को पश्चगामी संगतता की देखभाल करने के लिए या यह जांचने के लिए कि कुछ परिवर्तन टूलबॉक्स को तोड़ता है या नहीं। @HarryMichal लगातार टूटने का पीछा कर रहा है और परीक्षणों पर जोर दे रहा है, लेकिन प्रगति धीमी है।

मुझे लगता है कि इस समस्या से बचने का एक तरीका सिल्वरब्लू के लिए पॉडमैन के लिए एक अलग आरपीएम रेपो होना है और केवल उन अपडेट की अनुमति देना है जो टूलबॉक्स के खिलाफ रिग्रेशन टेस्ट पास कर रहे हैं।

इसे f32 अपडेट कब प्राप्त करना चाहिए?

जितनी जल्दी यह 3 सकारात्मक कर्मों तक पहुँचता है :)

आप इसे स्वयं ट्रैक कर सकते हैं -> https://bodhi.fedoraproject.org/updates/FEDORA-2020-306addaac0

यह कर्म प्रणाली मेरे लिए नई है, यह कैसे काम करती है?

बोधि सिस्टम में लॉग इन करने और अपडेट पर अपना वोट देने के लिए आपको FAS आईडी ( फेडोरा अकाउंट आईडी) की आवश्यकता होगी। देखें https://fedoraproject.org/wiki/Bodhi#Karma

सिल्वरब्लू पर, क्या मैं केवल दिए गए पैकेज को खींच सकता हूं और उसका परीक्षण कर सकता हूं? ऐसा लगता है कि पैकेज का परीक्षण करने के लिए इसे पुन: आधारित करने की आवश्यकता है। मेरे बेस सिस्टम को छूने की आवश्यकता के बिना पैकेज (कंटेनरों सहित, यदि संभव हो) का परीक्षण करने का कोई भी तरीका ठीक है।

सिल्वरब्लू पर, क्या मैं केवल दिए गए पैकेज को खींच सकता हूं और उसका परीक्षण कर सकता हूं?
ऐसा लगता है कि पैकेज का परीक्षण करने के लिए इसे पुन: आधारित करने की आवश्यकता है।
पैकेज के परीक्षण की कोई भी विधि (कंटेनरों सहित,
यदि संभव हो तो) मेरे आधार प्रणाली को छूने की आवश्यकता के बिना ठीक है।

rpm-ostree override replace और rpm-ostree override reset आपके मित्र हैं।

दुर्भाग्य से, आप कंटेनर के अंदर पॉडमैन और टूलबॉक्स जैसी चीजों का परीक्षण नहीं कर सकते।

समाधान @juanje . के लिए बहुत बहुत धन्यवाद

# Create the user
⬢[root<strong i="7">@toolbox</strong> /]# useradd --home-dir /home/vagrant/ --no-create-home --shell /bin/bash --uid 1000 --groups wheel vagrant

सिल्वरब्लू होस्ट पर मैंने अपने उपयोगकर्ता के लिए केवल एक ही परिवर्तन किया था, वह होम निर्देशिका /var/home/<user>

क्या इसे फिर से खोलना चाहिए? निश्चित रूप से अभी भी 0.0.95 के साथ हो रहा है। toolbox create ऐसा लगता है कि उपयोगकर्ता को अतिथि के /etc/passwd में डाल दिया गया है, लेकिन /etc/group प्रविष्टि की प्रतिलिपि बनाना भूल जाता है। कंटेनर में echo 'martin:x:1000' | sudo tee -a /etc/group जैसा कुछ इसे ठीक करता है।

https://github.com/containers/toolbox/issues/549#issuecomment -685740230 में एक ही अनुभव दर्ज किया है - वहां टिप्पणी की क्योंकि यह (आमतौर पर) सुडो को तोड़ता नहीं है।

निश्चित रूप से अभी भी 0.0.95 के साथ हो रहा है। टूलबॉक्स बनाने लगता है
उपयोगकर्ता को अतिथि के /etc/passwd में ठीक कर दें, लेकिन भूल जाता है
/etc/group प्रविष्टि की प्रतिलिपि बनाना। कुछ इस तरह
इको ' मार्टिन: एक्स : 1000' | कंटेनर में sudo tee -a /etc/group इसे ठीक करता है।

अभी भी क्या हो रहा है? आपका मतलब है कि कंटेनर में प्रवेश करते समय आपको यह त्रुटि दिखाई दे रही है:

/usr/bin/id: cannot find name for group ID 1000

वह है https://github.com/containers/podman/issues/7389

मैं टूलबॉक्स में समान वर्कअराउंड जोड़ने से कतराता हूं क्योंकि यह /etc/login.defs जैसी चीजों में सही ढंग से कारक नहीं होगा।

या मैंने गलत समझा?

@debarshiray : पॉडमैन इश्यू पॉइंटर के लिए धन्यवाद! यह वास्तव में मूल कारण की तरह दिखता है। इस बीच, ऊपर दिए गए वर्कअराउंड काफी आसान हैं।