আমাদের সিস্টেমে অ্যাডমিন সার্ভারে একটি সফ্টওয়্যার অ্যাপ্লিকেশন (মাভেন) ইনস্টল করেছে এবং প্রত্যেককে /usr/local/maven/bin/তাদের পথে ফোল্ডারটি যুক্ত করতে বলেছে ।
আমি মনে করি যে এই ফোল্ডারে কয়েকটি প্রোগ্রামকে /binফোল্ডার (বা অন্য ফোল্ডার যা প্রত্যেকে তাদের পথে রয়েছে) থেকে লিঙ্ক করা আরও সুবিধাজনক হতে পারে :
ln -s /usr/local/maven/bin/* /bin
এটা কি সঠিক? আমার পরামর্শের কোনও গোপন পার্শ্ব প্রতিক্রিয়া আছে কি?
উত্তর:
আপনি সাধারণত এর /usr/local/*সাথে লিঙ্ক করেন না /bin, তবে এটি একটি historicalতিহাসিক অনুশীলন বেশি। সাধারণভাবে, কয়েকটি "প্রযুক্তিগত" কারণ রয়েছে যা আপনি পরামর্শ দিচ্ছেন তা করতে পারেন না।
এক্সিকিউটেবলের সাথে লিঙ্ক তৈরি করা /binসমস্যার কারণ হতে পারে:
সম্ভবত সবচেয়ে বড় সতর্কতাটি হ'ল যদি আপনার সিস্টেমে কোনও ধরণের প্যাকেজ ম্যানেজার যেমন RPM, dpkg, APT, YUM, pacman, pkg_add, ইত্যাদি দ্বারা পরিচালিত প্যাকেজগুলি থাকে তবে আপনি সাধারণত প্যাকেজটিকে অনুমতি দিতে চান ম্যানেজার তার কাজ এবং যেমন ডিরেক্টরি পরিচালনা /sbin, /bin, /libএবং /usr। একটি ব্যতিক্রম /usr/localহ'ল যা আপনার বাক্সে হস্তক্ষেপকারী কোনও প্যাকেজ ম্যানেজার সম্পর্কে চিন্তা না করেই বাক্সের মধ্যে উপযুক্ত দেখা হিসাবে সাধারণত করার একটি নিরাপদ জায়গা।
প্রায়শই নির্বাহযোগ্যদের জন্য নির্মিত /usr/localনির্বাহীদের তাদের এক্সিকিউটেবলের মধ্যে এই প্যাথটিকে হার্ড-কোডেড করে রাখে। /usr/localএই অ্যাপ্লিকেশনগুলির ইনস্টলেশনের অংশ হিসাবে অন্তর্ভুক্ত থাকা কনফিগারেশন ফাইলগুলিও থাকতে পারে । সুতরাং কেবল এক্সিকিউটেবলের সাথে সংযোগ স্থাপনের ফলে এই অ্যাপ্লিকেশনগুলির মধ্যে .cfgফাইলগুলি পরে সন্ধান করা সমস্যার কারণ হতে পারে । এই জাতীয় মামলার উদাহরণ এখানে:
$ strings /usr/local/bin/wit | grep '/usr/local'
/usr/local/share/wit
/usr/local/share/wit/
.cfgফাইলগুলি অনুসন্ধানের ক্ষেত্রে প্রযোজ্য একই সমস্যাটি "সহায়ক" এক্সিকিউটেবলের সাথেও ঘটতে পারে যা প্রাথমিক অ্যাপটি চালানো দরকার। এগুলিও এর সাথে লিঙ্ক করা দরকার /usr/bin, কারণ এটি সমস্যাযুক্ত হতে পারে এবং আপনি যখন লিঙ্কযুক্ত অ্যাপ্লিকেশনটি বাস্তবায়নের চেষ্টা করেছিলেন কেবল তখনই তা প্রদর্শিত হবে।
উল্লেখ্য: সাধারণভাবে এটা অ্যাপ্লিকেশন বন্ধ এক লিঙ্ক প্রলোভন এড়াতে সেরা /usr/bin।
তারপরে সমস্ত ব্যবহারকারীকে এই ব্যবস্থাপনার ব্যবস্থা করতে হবে, প্রশাসক খুব সহজেই ডিরেক্টরিতে $PATHএটি সম্পর্কিত ফাইল যুক্ত করে বাক্সের প্রত্যেকের সাথে এটি যুক্ত করতে পারে /etc/profile.d।
এর মতো একটি ফাইল /etc/profile.d/maven.sh:
PATH=$PATH:/usr/local/maven/bin
আপনি এটির সাহায্যে সমস্ত ব্যবহারকারীর সেটআপটিকে দূষিত না করে প্রশাসক হিসাবে এটি করেন।
বেশিরভাগ ডিস্ট্রোস এখন alternatives(ফেডোরা / সেন্টোস) বা update-alternatives(দেবিয়ান / উবুন্টু) নামে আরেকটি সরঞ্জাম সরবরাহ করে যা আপনি সেই $PATHসরঞ্জামগুলিতে লুপ করতেও ব্যবহার করতে পারেন যা সম্ভবত বাইরের বাইরে থাকতে পারে /bin। এগুলির মতো সরঞ্জাম ব্যবহার করা অধিকতর কার্যকর কারণ এগুলি বেশিরভাগ অ্যাডমিনরা "স্ট্যান্ডার্ড অনুশীলন" হিসাবে বিবেচনা করবে এবং তাই সিস্টেমগুলি এক অ্যাডমিন থেকে অন্য প্রশাসকের কাছে হস্তান্তর করা সহজ করে দেয়।
লিঙ্কগুলি তৈরি করতে এই সরঞ্জামটি একই কাজ করে /bin; তবে এটি এই লিঙ্কগুলি তৈরি এবং ধ্বংস পরিচালনা করে, সুতরাং কোনও সরঞ্জামের মাধ্যমে বনাম বনাম আপনি যখন পরামর্শ দিচ্ছেন ঠিক ততক্ষণে এটি করা সিস্টেমের উদ্দেশ্যযুক্ত সেটআপটি বোঝা সহজ।
এখানে আমি একটি বাক্সে ওরাকল জাভা পরিচালনা করতে সেই সিস্টেমটি ব্যবহার করছি:
$ 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
দুর্ভাগ্যজনক /binহলেও লিঙ্কগুলি তৈরি করা সম্ভবত বেশিরভাগ সিসাদমিন দ্বারা অত্যন্ত নিরুৎসাহিত হবে:
/binডিরেক্টরিটির মালিক নন । এখানে একটি উদাহরণ। রেড হ্যাট ডিগ্রোজে আরপিএম ব্যবহার করে যদি কোনও ফাইল ইতিমধ্যে /binআরপিএম-এ উপস্থিত থাকে তবে উপরে বর্ণিত হিসাবে ইনস্টল না করা হবে, যদি না --replacefilesস্যুইচটি ব্যবহার করে এটি করা হয় । সুতরাং এটি আসলে কোনও প্রযুক্তিগত কারণ নয়। অন্যান্য ডিরেক্টরি একই। আমি ওএস "মালিকানাধীন" সম্পর্কে আপনি যা বলছেন তা বুঝতে পেরেছি তবে আপনি যেটা বলছেন /binঠিক ততটা সোজা নয়।
জিজ্ঞাসা করা প্রশ্নের উত্তর:
এটা কি সঠিক?
না , এটি একটি খারাপ অনুশীলন।
আমার পরামর্শ কিছু লুকানো পার্শ্ব প্রতিক্রিয়া আছে?
হ্যাঁ এর কয়েকটি পার্শ্ব প্রতিক্রিয়া রয়েছে। আপনার পরামর্শটি প্রয়োগের উপর নির্ভর করে কাজ করতে পারে বা না পারে এবং দীর্ঘমেয়াদে তাড়াতাড়ি বা ভেঙে যেতে পারে।
এ জাতীয় প্রতীকী লিঙ্ক তৈরি না করার বুদ্ধিমান কারণ রয়েছে :
প্রশাসকরা "নিজস্ব" /bin(নোট 1 দেখুন) হিসাবে এই ডিরেক্টরিটি অপারেটিং সিস্টেম / বিতরণ বিকাশকারীদের অন্তর্গত। অন্যদিকে /usr/localস্থানীয় প্রশাসক দ্বারা নির্ধারিত সফ্টওয়্যারগুলির জন্য একটি traditionalতিহ্যবাহী অবস্থান, /opt/<packagename>আনবান্ডেলড সফ্টওয়্যারগুলির মধ্যে একটি। যদি আপনি কোনও ফাইল বা লিংক তৈরি করেন তবে /binপ্যাকেজ ইনস্টলেশন দ্বারা এটি ওভাররাইট করার ঝুঁকি রয়েছে, আপনার ক্ষেত্রে mavenওএস দ্বারা সরবরাহ করা একটি হাইপোথিটিক্যাল প্যাকেজ, এটি স্থানীয়ভাবে নির্মিত একটি নতুন থেকে তৈরি করা হলে রিগ্রেশন হতে পারে উত্স কোড যে ওএস সংস্করণ। উদাহরণস্বরূপ, এসভিআর 4 pkgadd, ডিবিয়ান dpkg, লাল-টুপি rpmএবং স্ল্যাকওয়ার ট্র্যাবালগুলি অন্ধভাবে আপনার প্রতীকী লিঙ্কটি ওভাররাইট করবে।
কিছু অ্যাপ্লিকেশন সেই জায়গায় নজর রাখে যেখানে কনফিগারেশন ফাইল, প্লাগইন এবং অনুরূপ সংস্থান পুনরুদ্ধার করার জন্য তাদের ডাকা হয়। আপনি যদি এই অ্যাপ্লিকেশনটিকে একটি প্রতীকী লিঙ্ক দিয়ে কল করেন তবে এর কোডটি এটি অনুসরণ করতে ব্যর্থ হতে পারে এবং তারপরে এই সংস্থান ফাইলগুলি /usr/binযেখানে নেই সেগুলি সন্ধান করতে পারে।
এতে অন্য বাইনারি থাকতে পারে আপনি ইতিমধ্যে সমস্ত সম্ভাব্য কমান্ডের লিঙ্ক যুক্ত করে আপনার কমান্ডের সাথে এটি অ্যাকাউন্টে গ্রহণ করার সাথে সাথে সরানো হয়েছে।/usr/local/maven/binএবং আপনার पथপথটিতে এই ডিরেক্টরিটি যুক্ত না করা এগুলি অনুপলব্ধ করে তুলবে।
Maven2 পৃষ্ঠা আপনার পথে এই ডিরেক্টরির যোগ করার জন্য বলে (অবিকল: আপনার পথে, M2 এনভায়রনমেন্ট ভেরিয়েবল যোগ করুন, যেমন রপ্তানি পাথ = $, M2: $ পাথ ।), একটি ভিন্ন পদ্ধতির ব্যবহার করে আপনার যে পদক্ষেপ ভঙ্গ হয়, তাই দ্বারা একটি অসমর্থিত যাচ্ছি উপায়। অবশ্যই, যদি কোনও সিস্টেমের বেশিরভাগ ব্যবহারকারী সম্ভাব্য mavenব্যবহারকারী হন, তবে এটি PATHপ্রতিটি এবং প্রতিটির পরিবর্তে বিশ্বব্যাপী সেট করা আরও বুদ্ধিমান হবে .profile।
নোট 1:
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.
ডেবিয়ান / ফাইল সিস্টেম হায়ারার্কি স্ট্যান্ডার্ড
/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
/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.
বিকল্পটি ব্যবহার না করা 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
/binবা তার কম্পিউটারে সরাসরি তার সফ্টওয়্যার ইনস্টল করে /usr/bin। লুকানো বা বিকৃত সিস্টেম বাইনারিগুলির সমস্যাগুলি আবিষ্কার করার পরে (সর্বাধিক বিখ্যাত ছিল test) অন্য কোথাও নন সিস্টেম বাইনারি ইনস্টল করার সর্বোত্তম অনুশীলনটি ক্রমান্বয়ে গৃহীত হয়েছিল।
আপনি যদি সিমিলিংক করতে চান তবে এটিতে সিমলিংক করা ভাল /usr/local/bin। আমার সার্ভারে, আমি স্থানীয় সফ্টওয়্যার ইনস্টল করতে /opt/NAMEএবং বাইনারিগুলিতে সিমিলিং করতাম /usr/local/bin।
প্রস্তাবিত দুটি পদ্ধতির বিকল্প হ'ল এতে একটি শেল স্ক্রিপ্ট তৈরি করা হয় /usr/local/bin, যখন কার্যকর হয়, স্ক্রিপ্টে আপনি যে বাইনারি নির্দিষ্ট করে তা কার্যকর করে utes উদাহরণস্বরূপ, ম্যভেনকে উদাহরণ হিসাবে ব্যবহার করে, আমি একটি শেল স্ক্রিপ্ট তৈরি করব /usr/local/binযার নামটি ছিল mavenমাভেন বাইনারি যেখানে রয়েছে সেখানে চালিত করার জন্য এটিতে একটি ছোট স্ক্রিপ্ট রয়েছে এবং এটিতে কোনও যুক্তি পাস করতে হবে:
#!/bin/sh
exec /usr/local/maven/bin/maven "$@"
আপনি "লিঙ্ক" করতে চান এমন প্রতিটি বাইনারিটির জন্য এটি করার ক্ষয়ক্ষতি রয়েছে তবে এটি আপনাকে আপনার $PATHপরিবেশ পরিবর্তনশীলকে আপত্তিহীনভাবে কমান্ড লাইন থেকে সেই বাইনারিগুলি কল করার অনুমতি দেয় ।
/opt।