การติดตามโปรแกรม

เมื่อฉันติดตั้งโปรแกรมอย่างง่ายมันมักจะใช้make && make installและไม่ได้มีเป้าหมายในการถอนการติดตั้ง

หากฉันต้องการอัพเกรดโปรแกรมเป็นโปรโตคอลมาตรฐานหรือไม่ที่จะสมมติว่ามันเขียนทับโปรแกรมเก่าได้อย่างราบรื่นหรือไม่?

ฉันจะติดตามโปรแกรมเหล่านี้ได้อย่างไร ทำคนส่วนใหญ่เพียง 'ไฟและลืม' และหากไม่มีการกำหนดเป้าหมายการถอนการติดตั้งฉันต้องลบทุกอย่างด้วยตนเองหรือไม่

ติดตั้งแต่ละโปรแกรมในแผนผังไดเรกทอรีเฉพาะและใช้StowหรือXStowเพื่อทำให้โปรแกรมทั้งหมดปรากฏในลำดับชั้นทั่วไป Stow สร้างลิงก์สัญลักษณ์จากไดเร็กทอรีเฉพาะโปรแกรมไปยังแผนผังทั่วไป

/usr/local/stowในรายละเอียดมากขึ้นเลือกไดเรกทอรีระดับบนสุดเช่น /usr/local/stow/PROGRAM_NAMEติดตั้งแต่ละโปรแกรมภายใต้ ตัวอย่างเช่นจัดเรียงไฟล์ปฏิบัติการที่จะติดตั้งใน/usr/local/stow/PROGRAM_NAME/binman page ของมัน/usr/local/stow/man/man1และอื่น ๆ หากโปรแกรมใช้ autoconf ./configure --prefix /usr/local/stow/PROGRAM_NAMEเรียกใช้แล้ว หลังจากที่คุณทำงานmake installแล้วให้เรียกใช้stow:

./configure --prefix /usr/local/stow/PROGRAM_NAME
make
sudo make install
cd /usr/local/stow
sudo stow PROGRAM_NAME

และตอนนี้คุณจะมีลิงก์สัญลักษณ์เช่นนี้:

/usr/local/bin/foo -> ../stow/PROGRAM_NAME/bin/foo
/usr/local/man/man1/foo.1 -> ../../stow/PROGRAM_NAME/man/man1/foo.1
/usr/local/lib/foo -> ../stow/PROGRAM_NAME/lib/foo

คุณสามารถติดตามว่าคุณติดตั้งโปรแกรมใดโดยการแสดงรายการเนื้อหาของstowไดเรกทอรีและคุณรู้ว่าโปรแกรมใดเป็นไฟล์อยู่เนื่องจากเป็นลิงก์สัญลักษณ์ไปยังตำแหน่งภายใต้ไดเรกทอรีของโปรแกรมนั้น ถอนการติดตั้งโปรแกรมโดยเรียกใช้stow -D PROGRAM_NAMEแล้วลบไดเรกทอรีของโปรแกรม คุณสามารถทำให้โปรแกรมไม่สามารถใช้งานได้ชั่วคราวโดยการเรียกใช้stow -D PROGRAM_NAME(เรียกใช้stow PROGRAM_NAMEเพื่อให้พร้อมใช้งานอีกครั้ง)

หากคุณต้องการสลับระหว่างเวอร์ชันเดียวกันของโปรแกรมเดียวกันอย่างรวดเร็วให้ใช้/usr/local/stow/PROGRAM_NAME-VERSIONเป็นไดเรกทอรีโปรแกรม การอัพเกรดจากรุ่น 3 ถึง 4 รุ่น, ติดตั้งรุ่นที่ 4 stow -D PROGRAM_NAME-3; stow PROGRAM_NAME-4แล้วเรียกใช้

รุ่นเก่าของ Stow ไม่ได้ไปไกลเกินกว่าพื้นฐานที่ฉันได้อธิบายไว้ในคำตอบนี้ รุ่นใหม่เช่นเดียวกับ XStow (ซึ่งยังไม่ได้รับการบำรุงรักษาเมื่อเร็ว ๆ นี้) มีคุณสมบัติขั้นสูงเช่นความสามารถในการละเว้นไฟล์บางไฟล์จัดการกับ symlink ที่มีอยู่นอกไดเรกทอรี stow (เช่นman -> share/man) จัดการความขัดแย้งบางอย่างโดยอัตโนมัติ โปรแกรมให้ไฟล์เดียวกัน) ฯลฯ

~/software/stowหากคุณไม่ได้หรือไม่ต้องการที่จะใช้การเข้าถึงรากคุณสามารถเลือกไดเรกทอรีภายใต้ไดเรกทอรีบ้านของคุณเช่น ในกรณีนี้เพิ่มที่คุณ~/software/bin PATHหากmanไม่ได้โดยอัตโนมัติพบหน้าคนเพิ่มที่คุณ~/software/man MANPATHเพิ่ม~/software/infoที่คุณINFOPATH, ~/software/lib/pythonที่คุณPYTHONPATHและอื่น ๆ ตามความเหมาะสม

คุณสามารถใช้checkinstallเพื่อสร้างแพ็คเกจ (RPM, Deb หรือ Slackware ที่เข้ากันได้) ด้วยวิธีนี้คุณสามารถใช้ distros package manager ของคุณเพื่อเพิ่ม / ลบแอปพลิเคชัน (แต่ไม่อัปเดต)

คุณใช้checkinstallแทนmake installคำสั่ง (ใช้พารามิเตอร์ -D สำหรับ Deb; -R คือ RPM และ -S คือ Slackware):

root@nowhere# ./configure
root@nowhere# make
root@nowhere# checkinstall -D

checkinstall จะสร้างและติดตั้งแพ็คเกจตามค่าเริ่มต้นหรือคุณสามารถสร้างได้เฉพาะแพ็คเกจโดยไม่ต้องติดตั้ง

checkinstall มีอยู่ในที่เก็บ distros ส่วนใหญ่

ส่วนใหญ่นี่คือเหตุผลที่อยู่เบื้องหลังแพ็กเกจพอร์ตและผู้จัดการประเภทอื่น ๆ เพื่อป้องกันไม่ให้เกิดเหตุการณ์เช่นนี้

ฉันจะบอกว่าการลบด้วยตนเองเป็นวิธีเดียวสำหรับการติดตั้งด้วยตนเองเว้นแต่มีคนอื่นมีคำตอบที่ดีกว่าในจุดนั้นที่ฉันอาจไม่ทราบ

อีกทางเลือกหนึ่งมาจากคำแนะนำจาก Linux จาก Scratch :

ควบคุมและจัดการบรรจุภัณฑ์ได้มากขึ้นโดยใช้แพ็คเกจผู้ใช้

3 ผู้ใช้แพ็คเกจ
3.1 บทนำ

แนวคิดพื้นฐานของโครงร่างนี้อธิบายได้ง่าย ทุกแพ็คเกจเป็นของ "ผู้ใช้แพ็คเกจ" อย่างแน่นอน เมื่อคุณติดตั้งแพคเกจคุณสร้างและติดตั้งแพคเกจเป็นผู้ใช้แพคเกจนี้ทำให้ไฟล์ทั้งหมดที่ติดตั้งให้เป็นเจ้าของโดยผู้ใช้แพคเกจ ดังนั้นภารกิจการจัดการแพ็กเกจตามปกติทั้งหมดสามารถทำได้อย่างสะดวกสบายผ่านการใช้ยูทิลิตีบรรทัดคำสั่งมาตรฐาน ตัวอย่างง่าย ๆls -l <file>จะบอกคุณว่าแพคเกจใด <file>เป็นของและfind -user ...คำสั่งช่วยให้คุณสามารถดำเนินการกับไฟล์ทั้งหมดที่เป็นของแพ็คเกจเช่นลบออกเพื่อถอนการติดตั้งแพคเกจ

แต่การจัดการแพ็คเกจไม่ใช่ทั้งหมดที่ผู้ใช้แพ็คเกจดีสำหรับ เนื่องจากผู้ใช้แพ็คเกจไม่มีสิทธิ์รูทการติดตั้งแพ็กเกจจึงถูก จำกัด ในสิ่งที่สามารถทำได้ สิ่งหนึ่งที่ผู้ใช้แพ็คเกจไม่ได้รับอนุญาตให้ทำเช่นการเขียนทับไฟล์จากผู้ใช้แพ็คเกจอื่น การปะทะกันระหว่างแพ็คเกจต่าง ๆ ที่ต้องการติดตั้งไบนารีไลบรารีหรือไฟล์ส่วนหัวที่มีชื่อเดียวกันนั้นเป็นเรื่องธรรมดามากกว่าที่คุณคิด ด้วยผู้ใช้งานแพ็คเกจคุณจะไม่เสี่ยงกับการติดตั้งแพ็คเกจ B ทำลายไฟล์จากแพ็คเกจ A โดยไม่ต้องแจ้งให้ทราบล่วงหน้า ทุกครั้งที่พยายามทำสิ่งนี้ในระหว่างการติดตั้งแพ็กเกจ B จะทำให้เกิดข้อผิดพลาด "การอนุญาตที่ถูกปฏิเสธ" หรือ "การดำเนินการที่ไม่ได้รับอนุญาต" เพื่อให้คุณมีโอกาสทำตามขั้นตอนที่เหมาะสม อีกสิ่งที่ผู้ใช้แพ็คเกจไม่ได้รับอนุญาตให้ทำคือติดตั้งไบนารีรูทของ setuid การตัดสินใจสร้างรูทไบนารีของ setuid ก็เป็นสิ่งที่ผู้ดูแลระบบที่ชาญฉลาดไม่ต้องการทิ้งผู้สร้างแพ็คเกจซอฟต์แวร์

โดยทั่วไปแล้วบัญชีผู้ใช้แพคเกจจะไม่มีรหัสผ่านที่ถูกต้องเพื่อให้su ผู้ใช้แพ็คเกจสามารถรูทได้เท่านั้นซึ่งจะทำให้แน่ใจว่าผู้ใช้แพ็กเกจจะไม่เปิดวิธีเพิ่มเติมในระบบและทำลายความปลอดภัย แต่คุณอาจตั้งรหัสผ่านเพื่ออนุญาตให้ผู้ดูแลระบบร่วมที่คุณต้องการสามารถติดตั้งและบำรุงรักษาแพคเกจซอฟต์แวร์บางอย่างให้ทำโดยไม่ต้องเข้าถึงบัญชีรูทจริง ผู้ดูแลร่วมนี้สามารถติดตั้งลบเปลี่ยนห้องสมุดเพิ่มเติมซึ่งอาจจำเป็นสำหรับเวิร์กกรุ๊ปของเขา แม้ว่าเขาจะไม่สามารถลบหรือแก้ไขไลบรารีที่ไม่ได้เป็นของเขา / เธอเช่น libc

หลังจากคำแนะนำที่หยาบคายครั้งแรกนี้ฉันพบตัวแปรที่เปลี่ยนแปลง:

crablfs - ระบบการจัดการแพ็กเกจผู้ใช้

นี่crablfsคือตัวอย่างล่าสุดของการจัดการบรรจุภัณฑ์โดยใช้ uids และ gids ที่ไม่ซ้ำกันสำหรับการจัดการบรรจุภัณฑ์ แต่บนแหล่งที่มามันมีการพัฒนาอีกครั้งใน ulfs:

uLFS: Linux ที่สามารถจัดการและนำกลับมาใช้ใหม่ได้ตั้งแต่เริ่มต้น

สำหรับผู้ใช้ที่เป็นสาเหตุของแพ็คเกจที่ติดตั้งฉันคิดว่า LFS "ผู้ใช้แพ็คเกจ" เป็นโซลูชันที่เบาและไม่รุกรานและสวยงาม ในระยะสั้นที่คุณติดตั้งแพคเกจใน/usr/localหรือ/home/user/localและติดตามไฟล์โดยใช้ UIDs GIDS ไม่ซ้ำกันและสำหรับแต่ละแพคเกจ แต่ใส่ไฟล์ทั้งหมดในสถานที่แบบดั้งเดิมไดเรกทอรีที่พบบ่อย/usr/local/bin, /usr/local/libเหมือนมันอยู่ในลินุกซ์หลักทั้งหมด ... อุดไฟล์และไฟล์ที่ไม่ต้องการเขียนทับหรือลบ หลีกเลี่ยงได้ด้วยเคล็ดลับลีนุกซ์ที่เรียบร้อยซึ่งอธิบายโดย Matthias S. Benkmann ใน more_control_and_pkg_man.txt ซึ่งต้องการเพียงการจัดการสิทธิ์ไฟล์และไดเรกทอรีปกติเท่านั้นเช่นการอนุญาตบิตเหนียวสำหรับไดเรกทอรีเพื่อหลีกเลี่ยงการเขียนทับไฟล์ที่ไม่ต้องการ:

3.3 กลุ่ม

ผู้ใช้แพ็คเกจทุกคนเป็นสมาชิกอย่างน้อย 2 กลุ่ม หนึ่งในกลุ่มเหล่านี้คือกลุ่ม "ติดตั้ง" ซึ่งเป็นผู้ใช้แพ็คเกจทั้งหมด (และผู้ใช้แพ็คเกจเท่านั้น) ไดเรกทอรีทั้งหมดที่ได้รับอนุญาตให้ติดตั้งสิ่งต่าง ๆ เป็นของกลุ่มการติดตั้ง ซึ่งรวมถึงไดเรกทอรีเช่น / bin และ / usr / bin แต่ไม่รวมไดเรกทอรีเช่น / root หรือ / ไดเร็กทอรีที่กลุ่มการติดตั้งเป็นเจ้าของนั้นสามารถเขียนเป็นกลุ่มได้เสมอ นี่จะเพียงพอสำหรับด้านการจัดการแพ็คเกจ แต่หากไม่มีการเตรียมการเพิ่มเติมจะไม่ให้ความปลอดภัยหรือการควบคุมที่เพิ่มขึ้นเนื่องจากทุกแพ็คเกจสามารถแทนที่ไฟล์จากแพ็คเกจอื่น (การเปลี่ยนแปลงจะปรากฏในผลลัพธ์จากls -lแม้ว่า) ด้วยเหตุนี้ไดเรกทอรีการติดตั้งทั้งหมดจะได้รับคุณลักษณะที่ยึดติด สิ่งนี้อนุญาตให้ผู้ใช้สร้างไฟล์ใหม่และลบหรือแก้ไขไฟล์ของตนเองในไดเรกทอรี แต่ไฟล์จากผู้ใช้อื่นไม่สามารถแก้ไขหรือลบออกได้ ในส่วนที่เหลือของคำใบ้นี้เมื่อใดก็ตามที่คำว่า "ติดตั้งไดเรกทอรี" ถูกใช้มันหมายถึงไดเรกทอรีที่เป็นของการติดตั้งกลุ่มคือกลุ่มที่เขียนได้และเหนียว IOW เพื่อเปลี่ยน<dir>เป็นไดเรกทอรีการติดตั้งที่คุณจะทำ

chgrp ติดตั้ง && chmod g + w, o + t

สำหรับฉันมันดูเหมือนเป็นทางออกที่ง่ายและฉลาด! ฉันใช้ชุดรูปแบบนี้ในการสร้าง LFS ของฉันและเป็นวิธีแก้ปัญหาในการทำงาน ...

1. คุณสามารถทำ RPM เปล่าเพื่อเป็นการเตือน
2. คุณสามารถตรวจสอบการห่อซอฟต์แวร์ได้อย่างถูกต้องใน RPM
3. คุณสามารถเก็บสำเนาของtarไฟล์ไว้จากการติดตั้ง/usr/src/non-rpmsเพื่อเตือนคุณ (นั่นคือสิ่งที่ฉันมักจะทำ)