การเพิ่มไปยังเส้นทางเทียบกับการเชื่อมโยงจาก / bin


24

ผู้ดูแลระบบ sys ของเราติดตั้งแอปพลิเคชันซอฟต์แวร์ (Maven) บนเซิร์ฟเวอร์และบอกให้ทุกคนเพิ่ม/usr/local/maven/bin/โฟลเดอร์ลงในพา ธ ของพวกเขา

ฉันคิดว่ามันจะสะดวกกว่าที่จะเชื่อมโยงโปรแกรมบางอย่างในโฟลเดอร์นั้นจาก/binโฟลเดอร์ (หรือโฟลเดอร์อื่น ๆ ที่ทุกคนมีในเส้นทางของพวกเขา) เช่นนี้

ln -s /usr/local/maven/bin/* /bin

ถูกต้องหรือไม่ มีผลข้างเคียงที่ซ่อนอยู่กับคำแนะนำของฉันหรือไม่


2
ต่อLSB/optคุณควรเพิ่มแพคเกจภายนอกภายใต้
vonbrand

คำตอบ:


31

ในการเชื่อมโยง

โดยทั่วไปคุณไม่ได้เชื่อมโยง/usr/local/*กับ/binแต่นี่เป็นวิธีปฏิบัติทางประวัติศาสตร์มากกว่า โดยทั่วไปมีเหตุผล "เทคนิค" สองสามประการที่ทำให้คุณไม่สามารถทำสิ่งที่คุณแนะนำได้

การสร้างลิงก์ไปยังโปรแกรมเรียกทำงาน/binอาจทำให้เกิดปัญหา:

  1. อาจเป็นข้อแม้ที่ใหญ่ที่สุดถ้าระบบของคุณมีแพ็คเกจที่จัดการโดยตัวจัดการแพ็กเกจบางประเภทเช่น RPM, dpkg, APT, YUM, pacman, pkg_add เป็นต้นในกรณีนี้คุณมักจะต้องการให้แพ็กเกจนั้น ผู้จัดการทำงานและจัดการไดเรกทอรีเช่น/sbin, /bin, และ/lib /usrข้อยกเว้นประการหนึ่ง/usr/localคือโดยปกติแล้วจะเป็นสถานที่ที่ปลอดภัยที่จะทำตามที่เห็นสมควรในกล่องโดยไม่ต้องกังวลเกี่ยวกับตัวจัดการแพคเกจที่รบกวนไฟล์ของคุณ

  2. บ่อยครั้งที่ executables ที่สร้างขึ้นสำหรับ/usr/localจะมีเส้นทางนี้ฮาร์ดโค้ดลงใน executables ของพวกเขา อาจมีไฟล์กำหนดค่าที่รวมอยู่ใน/usr/localการติดตั้งแอปพลิเคชัน ดังนั้นการลิงก์ไปยังไฟล์ที่เรียกทำงานได้อาจทำให้เกิดปัญหากับแอพเหล่านี้ในการค้นหา.cfgไฟล์ในภายหลัง นี่คือตัวอย่างของกรณีดังกล่าว:

    $ strings /usr/local/bin/wit | grep '/usr/local'
    /usr/local/share/wit
    /usr/local/share/wit/
    
  3. ปัญหาเดียวกันกับที่ใช้กับการค้นหา.cfgไฟล์ยังสามารถเกิดขึ้นได้ด้วยไฟล์เรียกทำงาน "ตัวช่วยเหลือ" ที่แอปหลักต้องเรียกใช้ สิ่งเหล่านี้ก็จะต้องเชื่อมโยงเข้า/usr/binด้วยกันการรู้ว่านี่อาจเป็นปัญหาและจะปรากฏขึ้นเมื่อคุณพยายามเรียกใช้แอพที่เชื่อมโยงเท่านั้น

หมายเหตุ:โดยทั่วไปจะเป็นการดีที่สุดที่จะหลีกเลี่ยงการล่อลวงให้เชื่อมโยงกับแอพพลิเคชั่นที่/usr/binไม่ได้ใช้งาน

/etc/profile.d

แทนที่จะมีผู้ใช้ทั้งหมดที่ให้การจัดการนี้ผู้ดูแลระบบสามารถเพิ่มสิ่งนี้ลงในทุกคนได้อย่างง่ายดาย$PATHด้วยการเพิ่มไฟล์ที่เกี่ยวข้องใน/etc/profile.dไดเรกทอรี

ไฟล์เช่นนี้/etc/profile.d/maven.sh:

PATH=$PATH:/usr/local/maven/bin

โดยทั่วไปคุณทำสิ่งนี้ในฐานะผู้ดูแลระบบแทนการสร้างมลพิษให้กับการตั้งค่าของผู้ใช้ทั้งหมดด้วยสิ่งนี้

การใช้ทางเลือก

distros ที่สุดในขณะนี้ให้เป็นอีกเครื่องมือหนึ่งที่เรียกว่าalternatives(Fedora / CentOS) หรือupdate-alternatives(Debian / Ubuntu) ซึ่งคุณยังสามารถใช้ห่วงเข้าไปในเครื่องมือเครื่องใช้ที่อาจจะออกไปข้างนอก$PATH /binการใช้เครื่องมือเช่นนี้เป็นสิ่งที่ดีกว่าเนื่องจากเครื่องมือเหล่านี้จะยึดติดกับสิ่งที่ผู้ดูแลระบบส่วนใหญ่จะพิจารณาว่า "การปฏิบัติตามมาตรฐาน" และทำให้ระบบง่ายขึ้นในการส่งมอบจากผู้ดูแลระบบคนหนึ่งไปยังอีกคนหนึ่ง

เครื่องมือนี้ไม่ได้สิ่งที่คล้ายกันในการทำให้การเชื่อมโยงใน/bin; แต่มันจัดการการสร้างและการทำลายลิงค์เหล่านี้ดังนั้นจึงง่ายต่อการเข้าใจการตั้งค่าที่ต้องการของระบบเมื่อดำเนินการผ่านเครื่องมือเทียบกับทำโดยตรงตามที่คุณแนะนำ

ที่นี่ฉันใช้ระบบนั้นเพื่อจัดการ Java ของ Oracle ในกล่อง:

$ ls -l /etc/alternatives/ | grep " java"
lrwxrwxrwx. 1 root root 73 Feb  5 13:15 java -> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64/jre/bin/java
lrwxrwxrwx. 1 root root 77 Feb  5 13:15 java.1.gz -> /usr/share/man/man1/java-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64.1.gz
lrwxrwxrwx. 1 root root 70 Feb  5 13:19 javac -> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64/bin/javac
lrwxrwxrwx. 1 root root 78 Feb  5 13:19 javac.1.gz -> /usr/share/man/man1/javac-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64.1.gz
lrwxrwxrwx. 1 root root 72 Feb  5 13:19 javadoc -> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64/bin/javadoc
lrwxrwxrwx. 1 root root 80 Feb  5 13:19 javadoc.1.gz -> /usr/share/man/man1/javadoc-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64.1.gz

คุณสามารถเห็นผลของสิ่งนี้:

$ type java
java is /usr/bin/java

$ readlink -f /usr/bin/java
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64/jre/bin/java

ฉัน $ 0.02

/binแม้ว่าการเชื่อมโยงที่เชื่อถือได้นั้นน่าจะทำให้หมดกำลังใจมากโดย sysadmins ส่วนใหญ่:

  1. จะถูกขมวดคิ้วเนื่องจากมองว่าเป็นเรื่องที่กำหนดเองและอาจนำไปสู่ความสับสนได้หากผู้ดูแลระบบคนอื่นจำเป็นต้องหยิบกล่องขึ้นมา
  2. สามารถนำไปสู่ระบบที่จะแตกหักในสถานะในอนาคตอันเป็นผลมาจากการปรับแต่ง "เปราะบาง" นี้

@slm คุณอาจต้องการแก้ไขย่อหน้าแรกของคุณ มีเหตุผลทางเทคนิคหลายประการที่จะไม่ใช้ symlink
jlliagre

@jlliagre - ในการดู A ของคุณฉันไม่มั่นใจว่าผู้ดูแลระบบไม่ได้เป็นเจ้าของ/binไดเรกทอรี นี่คือตัวอย่าง ใน Red Hat distros ที่ใช้ RPM หากไฟล์ที่มีอยู่แล้วใน/binRPM จะไม่ติดตั้งที่ด้านบนของที่คุณได้อธิบายไว้เว้นแต่ว่า coxed จะทำเช่นนั้นโดยใช้--replacefilesสวิตช์ นั่นไม่ใช่เหตุผลทางเทคนิคจริงๆ เหมือนกับไดเรกทอรีอื่น ฉันเข้าใจสิ่งที่คุณพูดเกี่ยวกับระบบปฏิบัติการ "เป็นเจ้าของ" /binแต่มันก็ไม่ได้เป็นไปอย่างที่คุณต้องการ
slm

@jlliagre - ใน A ของฉันฉันไม่สนับสนุนให้ทุกคนสร้างลิงก์เพียงระบุว่าทำได้หากพวกเขาเลือกที่จะทำ ฉันเกลียดระบบที่ทำสิ่งต่าง ๆ เช่นนั้นและโดยทั่วไปแล้วสาปแช่งผู้ดูแลระบบที่ทำได้ 8-)
slm

@slm พวกเขาสามารถ (เนื่องจากพวกเขามีสิทธิ์เพียงพอ) แต่นั่นไม่ได้หมายความว่ามันจะทำงานได้ คะแนน # 2 และ # 3 ในคำตอบของฉันยังคงเป็นเหตุผลทางเทคนิคที่ถูกต้องไม่สร้างลิงก์ แต่ใช้ PATH ที่ถูกต้องโดยเฉพาะในกรณี OP ฉันขอแนะนำให้คุณพูดถึงพวกเขาในการตอบกลับของคุณ
jlliagre

@jlliagre - เพิ่มรายละเอียดตามความคิดเห็นของคุณ
slm

7

ตอบคำถามที่ถาม:

ถูกต้องหรือไม่

ไม่มันเป็นการปฏิบัติที่ไม่ดี

มีผลข้างเคียงที่ซ่อนอยู่กับคำแนะนำของฉันหรือไม่

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

มีเหตุผลที่สมเหตุสมผลที่จะไม่สร้างลิงก์สัญลักษณ์:

  • ผู้ดูแลระบบไม่ "เป็นเจ้าของ" /bin(ดูหมายเหตุ 1) เนื่องจากไดเรกทอรีนี้เป็นของผู้พัฒนาระบบปฏิบัติการ / ผู้จัดจำหน่าย ในทางตรงกันข้าม/usr/localเป็นตำแหน่งดั้งเดิมสำหรับซอฟต์แวร์ที่สร้างขึ้นโดยผู้ดูแลระบบท้องถิ่น/opt/<packagename>เป็นหนึ่งสำหรับซอฟต์แวร์ unbundled หากคุณสร้างไฟล์หรือลิงค์/binมีความเสี่ยงที่จะถูกเขียนทับโดยการติดตั้งแพคเกจในกรณีของคุณmavenแพคเกจสมมุติที่จัดทำโดยระบบปฏิบัติการซึ่งอาจนำไปสู่การถดถอยหากสร้างขึ้นในประเทศจะถูกสร้างขึ้นใหม่ รหัสที่มาว่ารุ่นของระบบปฏิบัติการ ตัวอย่างเช่น SVR4 pkgadd, debian dpkg, red-hat rpmและ slackware tarballs ทั้งหมดจะเขียนทับลิงค์สัญลักษณ์ของคุณ

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

  • อาจมีไบนารีอื่น ๆ อยู่/usr/local/maven/binและไม่เพิ่มไดเรกทอรีนี้ลงใน PATH ของคุณจะทำให้ไม่สามารถใช้งานได้ ลบออกเมื่อคุณคำนึงถึงคำสั่งของคุณแล้วโดยการเชื่อมโยงคำสั่งที่เป็นไปได้ทั้งหมด

  • หน้า Maven2บอกจะเพิ่มไดเรกทอรีนี้เพื่อเส้นทางของคุณ (อย่างแม่นยำ: เพิ่มตัวแปรสภาพแวดล้อม M2 ไปยังเส้นทางของคุณเช่นการส่งออก PATH = $ M2: $ PATH .) โดยใช้วิธีการที่แตกต่างกันของคุณจะหมดขั้นตอนนั้นจึงจะรับการสนับสนุน ทาง แน่นอนถ้าผู้ใช้ส่วนใหญ่ของระบบที่มีศักยภาพmavenผู้ใช้ก็จะทำให้รู้สึกมากขึ้นเพื่อตั้งทั่วโลกกว่าแทนในแต่ละและทุกPATH.profile

หมายเหตุ 1:

เอกสารประกอบ Slackware:

   The /bin directory usually doesn't receive modification
   after installation. If it does, it's usually in the form
   of package upgrades that we provide.

มาตรฐานลำดับขั้นของ Debian / Filesystem

/bin/
   Essential command executable (binaries) for all users (e.g., cat, ls, cp) 
   (especially files required to boot or rescue the system)
...
/opt/
   Add-on application software packages 
   Pre-compiled, non ".deb" binary distribution (tar'ed..) goes here.
/opt/bin/
   Same as for top-level hierarchy

เอกสาร Solaris:

/usr/bin
   Platform-dependent, user-invoked executables. These  are
   commands  users expect to be run as part of their normal
   $PATH. For executables that are different  on  a  64-bit
   system  than  on a 32-bit system, a wrapper that selects
   the  appropriate  executable   is   placed   here.   See
   isaexec(3C).  An approved installation location for bun-
   dled Solaris software. The analogous location for add-on
   system     software     or     for    applications    is
   /opt/packagename/bin.

การทดสอบอย่างง่าย ๆ ที่แสดงว่า Debian dpkgไม่ได้รักษาลิงก์ที่มีอยู่แม้ว่า--force-overwriteจะไม่ได้ใช้ตัวเลือก:

# ls -l /usr/bin/banner
lrwxrwxrwx 1 root root 11 Feb 25 21:37 /usr/bin/banner -> /tmp/banner
# dpkg -i sysvbanner_1.0.15_amd64.deb 
Selecting previously unselected package sysvbanner.
(Reading database ... 236250 files and directories currently installed.)
Unpacking sysvbanner (from sysvbanner_1.0.15_amd64.deb) ...
Setting up sysvbanner (1.0.15) ...
Processing triggers for man-db ...
# ls -l /usr/bin/banner
-rwxr-xr-x 1 root root 11352 May  7  2009 /usr/bin/banner

สำคัญอย่างแน่นอน มันค่อนข้างโชคร้ายที่คุณได้รับการยอมรับคำตอบที่ไม่ถูกต้องระบุว่ามันเป็นเพียงประวัติศาสตร์การปฏิบัติโดยไม่มีเหตุผลทางเทคนิคที่จะหลีกเลี่ยงการ ...
jlliagre

1
คุณพูดถูก แต่ฉันยอมรับคำตอบนั้นเพราะมันให้วิธีแก้ปัญหาเชิงปฏิบัติที่ฉันใช้ซึ่งก็คือบอกผู้ดูแลระบบ sys ให้ใส่คำสั่ง PATH การแก้ไขคำสั่งใน /etc/profile.d
Erel Segal-Halevi

ฉันเห็นด้วยเขาให้วิธีแก้ปัญหาที่ใช้ได้จริงและถูกต้อง แต่ไม่ใช่คำถามสองข้อที่คุณถาม ("ถูกต้องหรือไม่มีผลข้างเคียงหรือไม่")
jlliagre

1
jlliagre ถูกต้องครบถ้วน การปฏิบัตินี้ไม่ได้เป็นประวัติศาสตร์เลย มันค่อนข้างเป็นแนวทางปฏิบัติที่ดีที่สุดเมื่อเร็ว ๆ นี้ ในทางตรงกันข้ามเก่า Unixes ทุกคนที่ติดตั้งชิ้นส่วนของซอฟต์แวร์โดยตรงในหรือ/bin /usr/binจากการค้นพบปัญหาของไบนารีของระบบที่ซ่อนอยู่หรือถูกรบกวน (ที่โด่งดังที่สุดtest) วิธีที่ดีที่สุดในการติดตั้งไบนารีของระบบที่อื่นนั้นได้ถูกนำมาใช้อย่างก้าวหน้า
แดน

3

หากคุณต้องการ symlink มันจะดีกว่าที่จะ symlink /usr/local/binไป บนเซิร์ฟเวอร์ของฉันฉันใช้ในการติดตั้งซอฟต์แวร์ในท้องถิ่น/opt/NAMEและ symlink /usr/local/binไบนารีไป


0

อีกทางเลือกหนึ่งสำหรับวิธีที่แนะนำทั้งสองคือการสร้างเชลล์สคริปต์ใน/usr/local/binนั้นเมื่อเรียกใช้งานจะดำเนินการตามไบนารี่ที่คุณระบุในสคริปต์ ตัวอย่างเช่นการใช้ maven เป็นตัวอย่างฉันจะสร้างเชลล์สคริปต์ใน/usr/local/binชื่อmavenที่มีสคริปต์ขนาดเล็กภายในเพื่อรันไบนารี maven ที่มันตั้งอยู่และผ่านการขัดแย้งใด ๆ กับมัน:

#!/bin/sh
exec /usr/local/maven/bin/maven "$@"

สิ่งนี้มีข้อเสียของการทำเช่นนี้สำหรับทุกไบนารี่ที่คุณต้องการ "ลิงค์" แต่มันช่วยให้คุณสามารถเรียกไบนารีเหล่านั้นจากบรรทัดคำสั่งโดยไม่จำเป็นต้อง$PATHเปลี่ยนแปลงตัวแปรสภาพแวดล้อมของคุณ

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.