Red Hat Enterprise Linux AS 4 রিলিজ নোটস

Red Hat Enterprise Linux 4-র সাথে উপলব্ধ glibc-র সংস্করণ অতিরিক্ত অভ্যন্তরীণ পরীক্ষা করতে ব্যবহৃত হয় এবং এর ফলে প্রারম্ভিক অবস্থায় ডাটা-র ক্ষয়ক্ষতি সনাক্ত করে তা রোধ করা সম্ভব। কোনো ক্ষয়ক্ষতি সনাক্ত করা হলে, ডিফল্ট অবস্থায় নিম্নলিখিত বার্তার অনুরূপ একটি বার্তা স্ট্যান্ডার্ড এরার-এ প্রদর্শিত হবে (অথবা stderr ব্যবহারের জন্য প্রস্তুত না থাকলে syslog-র মাধ্যমে লগ করা হবে):

*** glibc detected *** double free or corruption: 0x0937d008 ***

ডিফল্ট অবস্থায় সমস্যা উৎপন্নকারী প্রোগ্রামটিও বন্ধ (kill) করা হবে; কিন্তু, এই আচরণ (এবং সমস্যা বার্তা উৎপন্ন হবে কিনা) MALLOC_CHECK_ এনভায়রনমেন্টের মাধ্যমে নিয়ন্ত্রণ করা সম্ভব। নিম্নলিখিত মান সমর্থিত হয়:

যদি স্বতন্ত্র ISV থেকে প্রাপ্ত কোনো প্রোগ্রাম ব্যবহারের ফলে এই পরীক্ষণ আরম্ভ হয়ে থাকে এবং সমস্যার বার্তা প্রদর্শিত হয়, তাহলে অ্যাপ্লিকেশন বিক্রেতাকে এই সম্বন্ধে সূচিত করুন, কারণ এটি একটি গুরুতর সমস্যা।

Red Hat Enterprise Linux 4-এ hugemem নামক একটি কার্নেল উপস্থিত রয়েছে। এই কার্নেলে প্রতিটি প্রসেসর জন্য ৪ গিগাবাইট ইউজার স্থান (অন্যান্য কার্নেলে এর পরিমাণ ৩ গিগাবাইট), এবং ৪ গিগাবাইট ডাইরেক্ট কার্নেল স্থান উপলব্ধ করা হয়। এই কার্নেল ব্যবহারের ফলে ৬৪ গিগাবইট মাপের প্রধান মেমরিসহ সিস্টেমেও Red Hat Enterprise Linux চলতে সক্ষম। ১৬ গিগাবইটের অধিক মেমরিসহ সিস্টেমের সম্পূর্ণ মেমরি ব্যবহার করতে হলে hugemem কার্নেল উপস্থিত থাকা প্রয়োজন। কম মেমরি সহ সিস্টেমেও hugemem কার্নেলের প্রয়োগ লাভজনক হতে পারে (উদাহরণস্বরূপ, প্রতি প্রসেসের জন্য অধিক ইউজার স্থান প্রয়োগকারী কোনো অ্যাপ্লিকেশন চালানোর সময়।)

Hugemem কার্নেল ইনস্টল করার জন্য root পরিচয়ে লগ-ইন করে নিম্মলিখিত কমান্ড লিখুন:

rpm -ivh <kernel-rpm>

            

(<kernel-rpm>-র পরিবর্তে hugemem কার্নেলের RPM ফাইলের নাম লিখুন — যেমনkernel-hugemem-2.6.9-1.648_EL.i686.rpm।)

ইনস্টলেশন সম্পন্ন করে সিস্টেম পুনরায় বুট করে hugemem কার্নেল নির্বাচন করুন। Hugemem কার্নেল ব্যবহার করে আপনি সিস্টেম সঠিকভাবে চলছে কিনা তা পরীক্ষা করে /boot/grub/grub.conf ফাইলটি পরিবর্তন করুন যার ফলে hugemem কার্নেল ডিফল্ট অবস্থায় বুট করা হবে।

যদিও Red Hat Enterprise Linux 4, rawio সমর্থন করে কিন্তু এই ইন্টারফেসের অবচয় ঘটানো হয়েছে। যদি কোনো অ্যাপ্লিকেশন এই ইন্টারফেসের মাধ্যমে কোনো ডিভাইস ব্যবহার করে তাহলে O_DIRECT ফ্ল্যাগের মাধ্যমে ব্লক ডিভাইস খুলতে সক্ষম করার জন্য Red Hat আপনার অ্যাপ্লিকেশনটি পরিবর্তন করার অনুরোধ জানাচ্ছে। rawio, Red Hat Enterprise Linux 4-এ, উপস্থিত থাকলেও ভবিষ্যতে এটি সরিয়ে ফেলা হবে।

ফাইল-সিস্টেমের উপর অ্যাসিঙ্কক্রোনাস I/O (AIO) এখন শুধুমাত্র O_DIRECT অথবা নন-বাফারড মোডে উপলব্ধ রয়েছে। উল্লেখ্য অ্যাসিঙ্কক্রোনাস পোল ইন্টারফেস এখন উপস্থিত নেই এবং পাইপের উপর AIO পদ্ধতি সমর্থিত হয় না।

OSS মডিউলগুলি সরিয়ে ফেলে, শব্দ সংক্রান্ত সাব-সিস্টেমের জন্য ALSA প্রয়োগ করা হয়েছে।

সিস্টেম কার্নেলের "hugepage" বৈশিষ্ট্য ব্যবহার করা হলে অনুগ্রহ করে সচেতন থাকবেন যে এই বৈশিষ্ট্য নিয়ন্ত্রণকারী /proc/ এন্ট্রিটি Red Hat Enterprise Linux 3 এবং Red Hat Enterprise Linux 4-র মধ্যে পৃথকভাবে লেখা হয়েছে:

Red Hat Enterprise Linux 4-এ ব্যবহৃত কার্নেলে এনহান্সড ডিস্ক ডিভাইস (EDD) পোলিং উপলব্ধ রয়েছে। এটি সরাসরি ডিস্ক নিয়ন্ত্রক BIOS-র থেকে বুট করার যোগ্য ডিস্ক ডিভাইস সম্পর্কে তথ্য অনুসন্ধান করে /sys ফাইল-সিস্টেমে যোগ করে দেয়।

EDD সংক্রান্ত দুটি গুরুত্বপূর্ণ কার্নেল কামন্ড-লাইন অপশনও যোগ করা হয়েছে:

Red Hat Enterprise Linux 4-র প্রাথমিক রিলিজে USB হার্ড-ডিস্ক ড্রাইভ সমর্থিত হয় না। তথাপি, অন্যান্য USB সংরক্ষণ ডিভাইস যেমন ফ্ল্যাশ মিডিয়া CD-ROM এবং DVD-ROM ডিভাইস বর্তমানে সমর্থিত হয়ে থাকে।

Red Hat Enterprise Linux 4-এ ব্যবহৃত কার্নেলে LSI Logic-র নতুন megaraid_mbox ড্রাইভার উপস্থিত রয়েছে। এটি megaraid ড্রাইভারের পরিবর্তে ব্যবহৃত হবে। megaraid_mbox ড্রাইভার উন্নত রূপে নির্মিত হয়েছে, এটি ২.৬ কার্নেলের সাথে সুষ্ঠুরূপে চলতে সক্ষম এবং সর্বাধুনিক হার্ডওয়্যারের ব্যবহার সমর্থন করে। কিন্তু, megaraid ড্রাইভারের দ্বারা সমর্থিত কয়েকটি পুরোনো হার্ডওয়্যারের ব্যবহার megaraid_mbox ড্রাইভার সমর্থন করে না।

নিম্নলিখিত PCI বিক্রেতার ID এবং ডিভাইস ID-র জুটি megaraid_mbox ড্রাইভারের দ্বারা সমর্থিত হয় না:

বিক্রেতা, ডিভাইস

0x101E, 0x9010
0x101E, 0x9060
0x8086, 0x1960

কোনো মেশিনে ইনস্টল করা বিভিন্ন অ্যাডাপ্টারের ID, lspci -n কমান্ড ব্যবহার করে প্রদর্শন করা যাবে। এই ID-গুলির দ্বারা নিম্নলিখিত মডেলের (কিন্তু এই তালিকা সীমাবদ্ধ নয়) নাম উল্লেখ করা হয়:

Dell এবং LSI Logic-র পক্ষ থেকে জানানো হয়েছে যে তাদের দ্বারা এই মডেলগুলি ২.৬ কার্নেলে সমর্থন করা হবে না। যার ফলে Red Hat Enterprise Linux 4-এ এই অ্যাডাপ্টারগুলি সমর্থিত হয় না।

Red Hat Enterprise Linux 4-র প্রাথমিক রিলিজে iSCSI সফ্টওয়্যারের দ্বারা intitator ও target চিহ্নিত করার প্রক্রিয়া সমর্থন করে না। Red Hat Enterprise Linux 4-র পরবর্তী সংস্করণে iSCSI-র সমর্থন সংযোজন করা হবে কিনা তা সমীক্ষা করা হচ্ছে।

Linux 2.6 কার্নেলে Emulex LightPulse Fibre Channel ড্রাইভার (lpfc) অন্তর্ভুক্ত করা হবে কিনা তা জানার জন্য এটি বর্তমানে সার্বজনিকভাবে সমীক্ষা করা হচ্ছে। Red Hat Enterprise Linux 4-এ এটি পরীক্ষামূলকভাবে উপলব্ধ করা হয়েছে। এই ড্রাইভারে নিশ্চিতরূপে কিছু পরিবর্তন করা হবে। যদি এর মধ্যে কিছু সমস্যা দেখা দেয় অথবা এটি Linux 2.6 কার্নেলে অন্তর্ভুক্ত না করা হয়, তাহলে Red Hat Enterprise Linux-র চুড়ান্ত রিলিজ থেকে এটি অপসারিত হবে।

lpfc ড্রাইভারে, নিম্মলিখিত সমস্যাগুলি বর্তমানে রয়েছে:

পূর্বে, কার্নেল আপগ্রেড করা হলে সিস্টেমের বুট-লোডার কনফিগারেশনে ডিফল্ট কার্নেল পরিবর্তিত হত না।

কিন্তু Red Hat Enterprise Linux 4-এ এই বৈশিষ্ট্যের পরিবর্তন করা হয়েছে এবং নতুন ইনস্টল করা কার্নেলটিকে ডিফল্টরূপে স্থাপন করা হয়। এটি (rpm -i সহ) সর্বপ্রকার ইনস্টলেশন পদ্ধতির ক্ষেত্রে প্রযোজ্য।

এই আচরণ /etc/sysconfig/kernel ফাইলের দুটি পংক্তি দ্বারা নিয়ন্ত্রণ করা হয়:

কার্নেলের .src.rpm ফাইলে কার্নেল সোর্স-কোড উপস্থিত থাকার কারণে Red Hat Enterprise Linux 4, kernel-source প্যাকেজটি পৃথকভাবে উপলব্ধ করে না। কার্নেল সোর্স ব্যবহার করতে ইচ্ছুক ব্যবহারকারীরা সেগুলি kernel .src.rpm ফাইলে পাবেন। এই ফাইল থেকে একটি প্রসারিত সোর্স-কোড ট্রি নির্মাণ করার জন্য নিম্নলিখিত নির্দেশ অনুসরণ করুন (উল্লেখ্য, সিস্টেমে বর্তমানে ব্যবহৃত কার্নেলের সংস্করণ <version>-র দ্বারা চিহ্নিত হয়):

এর পরে স্বাভাবিক পদ্ধতি ধরে এগিয়ে চলুন।

obj-m    := foo.o

KDIR    := /lib/modules/$(shell uname -r)/build
PWD    := $(shell pwd)

default:
    $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules

              

Red Hat Enterprise Linux 4-এ Evolution গ্রাফিকাল ই-মেইল ক্লায়েন্টের একটি উন্নত সংস্করণ অন্তর্ভুক্ত করা হয়েছে। এই সংস্করণে একাধিক নতুন বৈশিষ্ট্য উপস্থিত রয়েছে, যেমন:

gimp-perl প্যাকেজটি Red Hat Enterprise Linux 4 থেকে সরিয়ে ফেলা হয়েছে, কারণ GIMP উন্নত করে 2.0 সংস্করণে পরিবর্তন করা হয়েছে। এর সাথে Perl বাইন্ডিংগুলি মূল প্যাকেজের অংশ হিসাবে আর গণ্য করা হয় না এবং সেগুলি প্রস্তুতও ছিল না।

GIMP-এ Perl স্ক্রিপ্ট ব্যবহার করতে হলে http://www.gimp.org/downloads/ থেকে Gimp Perl মডিউলটি ইনস্টল করুন।

ja_JP.eucJP-র পরিবর্তে ja_JP.UTF-8

ko_KR.eucKR-র পরিবর্তে ko_KR.UTF-8

zh_CN.GB18030-র পরিবর্তে zh_CN.UTF-8

zh_TW.Big5-র পরিবর্তে zh_TW.UTF-8

ভারতীয় ভাষা — iiimf-le-unit

জাপানি — iiimf-le-canna

কোরিয়ান — iiimf-le-hangul

সরলীকৃত চীনা — iiimf-le-chinput

পাম্পরিক চীনা — iiimf-le-xcin

ami-র দ্বারা iiimf-le-hangul ইনস্টল করা হয়

kinput2-র দ্বারা iiimf-le-canna ইনস্টল করা হয়

miniChinput-র দ্বারা iiimf-le-chinput ইনস্টল করা হয়

xcin-র দ্বারা iiimf-le-xcin ইনস্টল করা হয়

ডিফল্ট অবস্থায় Sendmail মেইল পরিবহনকারী (transport) এজেন্ট (MTA) স্থানীয় কম্পিউটার ব্যতীত অন্য কোনো হোস্টের থেকে উৎপন্ন নেটওয়ার্ক সংযোগ গ্রহণ করে না। অন্যান্য ক্লায়েন্টদের জন্যও যদি আপনি সার্ভার হিসাবে Sendmail কনফিগার করতে ইচ্ছুক থাকেন, তাহলে /etc/mail/sendmail.mc ফাইল পরিবর্তন করা প্রয়োজন। নেটওয়ার্ক ডিভাইসে অপেক্ষা করার জন্য DAEMON_OPTIONS পংক্তিটি পরিবর্তন করুন (অথবা dnl কমেন্ট ডি-লিমিটার ব্যবহার করে এই অপশনটি সম্পূর্ণ নিষ্ক্রিয় করুন) নিম্নলিখিত কমান্ডটি (root পরিচয়ে) নির্বাহ করে /etc/mail/sendmail.cf ফাইলটি পুনরায় গঠন করুন:

make -C /etc/mail

উল্লেখ্য, এটি কার্যকরী করার জন্য sendmail-cf প্যাকেজটি ইনস্টল থাকা আবশ্যক।

ডিফল্ট SELinux সুরক্ষা কনফিগারেশনে নির্ধারিত নীতি অনুযায়ী httpd-র পরিচালনা করা হয়। httpd দ্বারা ব্যবহৃত সিস্টেম-অবজেক্টের জন্য সুস্পষ্টরূপে প্রবেশাধিকার প্রদান করে অথবা প্রত্যাখ্যান করে নিরাপত্তার উন্নতি ও ওয়েব-সার্ভারের স্থায়িত্ব বর্ধিত হয়। কিন্ত এর ফলে পূর্বে চলমান কনফিগারেশন (উদাহরণস্বরূপ, PHP ব্যবহারকারী কনফিগারেশন) বিকল হওয়ার সম্ভাবনা থাকে। এই কারণে SELinux-র কর্ম প্রণালী সম্পর্কে অবগত থাকা প্রয়োজন যার ফলে কনফিগারেশন নিরাপদ ও সক্রিয় রাখা সম্ভব হবে।

উদাহরণস্বরূপ, httpd_sys_content_t সুরক্ষাচিহ্নসহ ~/public_html/-এ উপস্থিত অবজেক্ট ব্যবহার করার জন্য httpd-কে অনুমতি প্রদান করার জন্য একটি বুলিয়ান মান নির্ধারণ করা সম্ভব। SELinux-র দ্বারা httpd-র জন্য কোনো অবজেক্টে (ফাইল, অ্যাপ্লিকেশন, ডিভাইস ও অন্যান্য প্রসেস) সুস্পষ্টভাবে অনুমতি প্রদান না করা হলে Apache ডেমন সেগুলি ব্যবহার করতে সক্ষম হবে না।

Apache-র সঠিক কর্মসঞ্চালনের জন্য প্রয়োজনীয় অনুমতি প্রদান করা হলে, অশুদ্ধভাবে কনফিগার করা অথবা ক্ষতিগ্রস্ত httpd ডেমনের হাত থেকে সিস্টেম নিরাপদ রাখা সম্ভব।

ডিরেক্টরি ও ফাইল সংক্রান্ত Linux-র প্রমিত অনুমতি এবং SELinux-র প্রসঙ্গিক ফাইল লেবেলের প্রয়োজনে, ফাইল পুনরায় লেবেল করার পদ্ধতি সম্পর্কে অ্যাডমিনিসট্রেটর এবং ব্যবহারকারীদের অবগত থাকা আবশ্যক। নিম্নলিখিত কমান্ডগুলির সাহায্যে পুনরায় লেবেল করার পদ্ধতির উদাহরণ উল্লিখিত হয়েছে (প্রথমটি কোনো ডিরেক্টরির মধ্যেকার বস্তু রিকার্সিভ পক্রিয়ায় পুনরায় লেবেল করতে ব্যবহৃত হয় এবং দ্বিতীয় উদাহরণের সাহয্যে একটি ফাইল পুনরায় লেবেল করা যাবে):

chcon -R -h -t httpd_sys_content_t public_html
chcon -t httpd_sys_content_t public_html/index.html

            

Apache-র জন্য অনুমোদিত ধরন-র তালিকার মধ্যে অন্তর্ভুক্ত কোনো চিহ্নবিহীন ফাইল অথবা ডিরেক্টরি 403 Forbidden সমস্যাটি উৎপন্ন করবে।

আপনি বুলিয়ান মান পরিবর্তন করতে পারেন অথবা system-config-securitylevel ব্যবহারকারী Apache (অথবা অন্য কোনো ডেমনের) জন্য নির্ধারিত নিয়মনীতি পরিবর্তন করতে পারেন। SELinux ট্যাবের SELinux-এর পলিসি পরিবর্তন করো-র মধ্যে আপনি Apache-র বুলিয়াল মান পরিবর্তন করতে সক্ষম হবেন। প্রয়োজনে আপনি httpd ডেমনের জন্য SELinux সুরক্ষা নিষ্ক্রিয় করো নির্বাচন করতে পারেন যার ফলে unconfined_t (ডিফল্ট ধরন যা SELinux বিহীন Linux-র সাধারণ সুরক্ষা পদ্ধতির মত আচরণ করে) থেকে নির্দিষ্ট ধরনের ডেমন অর্থাৎ httpd_t-তে পরিবর্তন করা হবে না। এই পরিবর্তন প্রক্রিয়া নিষ্ক্রিয় করা হলে ঐ ডেমনের জন্য SELinux-র সুরক্ষা প্রদান না করে শুধুমাত্র সাধারণ Linux সুরক্ষা উপলব্ধ করা হবে।

Apache এবং SELinux-র নিয়মনীতি সম্পর্কে অধিক বিবরণের জন্য Red Hat SELinux Policy Guide পড়ুন যা অনলাইন http://www.redhat.com/docs-এ উপস্থিত রয়েছে।

ডিফল্টরূপে, এখন httpd ডেমন আরম্ভ করার জন্য সিস্টেম লোকেইলের নির্দিষ্ট মানের পরিবর্তে C লোকেইল ব্যবহার করা হয়। /etc/sysconfig/httpd ফাইলের HTTPD_LANG ভেরিয়েবলটি সম্পাদন করে এই আচরণ পরিবর্তন করা সম্ভব।

ডিফল্ট /etc/php.ini কনফিগারেশন ফাইলটি পরিবর্তন করা হয়েছে। "development"-র ডিফল্ট মানের পরিবর্তে এখন এটি "production"-র ডিফল্ট মান ব্যবহার করে; উল্লেখযোগ্য পার্থক্যগুলি হল:

প্যাকেজটি এখন Apache httpd 2.0-র সাথে সমঞ্জস্যের জন্য "apache2filter" SAPI-র পরিবর্তে "apache2handler" SAPI ব্যবহার করে। পূর্ববর্তী কোনো রিলিজ থেকে আপগ্রেড করার সময় /etc/httpd/conf.d/php.conf ফাইল থেকে SetOutputFilter ডিরেক্টিভ সরিয়ে নেওয়া আবশ্যক।

PHP এক্সটেনশন মডিউল প্যাকেজিং-এ নিম্নলিখিত পরিবর্তনগুলি করা হয়েছে:

Red Hat Enterprise Linux 4-র মধ্যে নতুন xorg-x11-deprecated-libs প্যাকেজটি উপলব্ধ করা হয়েছে। এই প্যাকেজের মধ্যে X11সংক্রান্ত অবচিত ডিরেক্টরিগুলি রয়েছে, যেগুলির Red Hat Enterprise Linux-র ভবিষ্যত সংস্করণ থেকে অপসারিত হয়ে যাওয়ার সম্ভাবনা রয়েছে। অবচিত লাইব্রেরিগুলি প্যাকেজ করে,বর্তমান অ্যাপ্লিকেশনগুলির জন্য বাইনারি স্তরের সামঞ্জস্য বজায় রাখার পাশাপাশি স্বতন্ত্র সফ্টওয়্যার প্রস্তুতকারকরা এর ফলে এই লাইব্রেরিগুলি বর্জন করার জন্য প্রয়েজনীয় সময় পাবেন।

বর্তমানে এই প্যাকেজে Xprint লাইব্রেরি (libXp) অন্তর্ভুক্ত রয়েছে। নতুন অ্যাপ্লিকেশন নির্মাণ করতে এই লাইব্রেরিটি ব্যবহার না করা উচিত। যে অ্যাপ্লিকেশনগুলি এই লাইব্রেরি ব্যবহার করে, সেগুলিকে libgnomeprint/libgnomeprintui প্রিন্ট API ব্যবহার করার জন্য পরিবর্তন করা বাঞ্ছনীয়।

Red Hat Enterprise Linux-র সাম্প্রতিক সংস্করণগুলিতে (এবং তার পূর্ববর্তী Red Hat Linux-এ) X উইন্ডো সিস্টেমে ফন্ট সংক্রান্ত কিছু বিভ্রান্তি দেখা দিয়েছিল। বর্তমানে পৃথক বৈশিষ্ট্যসহ দুটি ফন্ট সাব-সিস্টেম উপস্থিত রয়েছে:

- মূল (১৫ বৎসরের অধিক পূরোনো) সাব-সিস্টেমটি "কোর X ফন্ট সাব-সিস্টেম" নামে পরিচিত। এই সাব-সিস্টেমের দ্বারা রেন্ডার করা ফন্টগুলি অ্যান্টি-অ্যালায়েস্ড হয় না। এগুলি X সার্ভার দ্বারা পরিচালিত হয় এবং এগুলির নাম নিম্নলিখিত নামের মত হয়:

-misc-fixed-medium-r-normal--10-100-75-75-c-60-iso8859-1

নতুন সাব-সিস্টেমটি "fontconfig" নামে পরিচিত এবং অ্যাপ্লিকেশনগুলিকে সরাসরি ফন্ট-ফাইল ব্যবহার করার অনুমতি দেয়। Fontconfig অধিকাংশ সময় "Xft" লাইব্রেরির সাথে ব্যবহৃত হয়। এর ফলে অ্যাপ্লিকেশনগুলি fontconfig-র ফন্টগুলিকে অ্যান্টি-অ্যালায়েসিং-সহ রেন্ডার করতে সাহায্য করে। Fontconfig সহজ সরল নাম ব্যবহার করে, যেমন:

Luxi Sans-10

ভবিষ্যতে, কোর X ফন্ট সাব-সিস্টেমের পরিবর্তে fontconfig/Xft ব্যবহৃত হবে। বর্তমানে Qt 3 অথবা GTK 2 টুলকিট ব্যবহারকারী অ্যাপ্লিকেশন (KDE এবং GNOME অ্যাপ্লিকেশনগুলি এই তালিকায় অন্তর্ভুক্ত) fontconfig এবং Xft font সাব-সিস্টেম ব্যবহার করে; অন্যান্য প্রায় সব অ্যাপ্লিকেশন কোর X ফন্ট ব্যবহার করে।

ভবিষ্যতে, ডিফল্ট স্থানীয় ফন্ট ব্যবহার পদ্ধতি হিসাবে সম্ভবত Red Hat Enterprise Linux, XFS ফন্ট সার্ভারের পরিবর্তে শুধুমাত্র fontconfig/Xft ব্যবহার করবে।

উল্লেখ্য: উপরোক্ত ফন্ট সাব-সিস্টেমের একটি ব্যতীক্রম হল OpenOffice.org (যা নিজেদের অভ্যন্তরীণ ফন্ট রেন্ডারিং প্রযুক্তি ব্যবহার করে)।

Red Hat Enterprise Linux 4 সিস্টেমে নতুন ফন্ট যোগ করতে ইচ্ছুক হলে, আপনাকে প্রথমে জানতে হবে কোন ফন্ট সাব-সিস্টেমে ফন্টগুলি ব্যবহৃত হবে সাব-সিস্টেমের উপর নির্ভর করে পৃথক ইনস্টল পদ্ধতি ব্যবহৃত হবে। কোর X ফন্ট সাব-সিস্টেমের জন্য আপনাকে নিম্নলিখিত পদ্ধতি অনুসরণ করতে হবে:

১. /usr/share/fonts/local/ ডিরেক্টরিটি নির্মাণ করতে হবে (যদি বর্তমানে উপস্থিত না থাকে):

mkdir /usr/share/fonts/local/

২. নতুন ফন্ট ফাইলটি /usr/share/fonts/local/ ডিরেক্টরিতে কপি করুন

৩. নিম্নলিখিত কমান্ডগুলি ব্যবহার করে ফন্ট সংক্রান্ত তথ্য পরিবর্তন করুন (উল্লেখ্য, লেখার সুবিধার জন্য কমান্ডগুলি কিছু ক্ষেত্রে একাধিক পংক্তিতে লেখা হতে পারে কিন্তু বাস্তবে এগুলি একই পংক্তিতে লিখতে হবে):

ttmkfdir -d /usr/share/fonts/local/ -o /usr/share/fonts/local/fonts.scale

mkfontdir /usr/share/fonts/local/

৪. আপনাকে যদি /usr/share/fonts/local/ ডিরেক্টরিটি নির্মাণ করতে হয়ে থাকে, তাহলে সেটি X ফন্ট সার্ভার (xfs)-র পাথ-এ যোগ করা আবশ্যক:

chkfontpath --add /usr/share/fonts/local/

fontconfig ফন্ট সাব-সিস্টেমে নতুন ফন্ট যোগ করার পদ্ধতি তুলনামূলকভাবে সহজ; নতুন ফন্টগুলি /usr/share/fonts/ ডিরেক্টরিতে কপি করতে হবে (তাদের নিজস্ব ফন্ট কনফিগারেশন পরিবর্তন করার জন্য ব্যবহারকারীদেরকে ফন্ট ফাইলটি ~/.fonts/ ডিরেক্টরিতে কপি করতে হবে)।

নতুন ফন্ট কপি করার পরে fc-cache ব্যবহার করে ফন্ট সংক্রান্ত তথ্যের ক্যাশে আপডেট করুন:

fc-cache <directory>

(<directory>-র পরিবর্তে /usr/share/fonts/ অথবা ~/.fonts/ ডিরেক্টরির নাম লিখুন।)

গ্রাফিকাল প্রেক্ষাপটেও ফন্ট ইনস্টল করা সম্ভব। এর জন্য Nautilus-এ fonts:/// ব্রাউজ করে নতুন ফন্ট ফাইলগুলি ঐখানে টেনে নিয়ে আসতে হবে।

উল্লেখ্য: যদি ফন্ট ফাইলটি gzip ব্যবহার করে কম্প্রেস করা হয়ে থাকে, তাহলে এর নামের শেষে ".gz" লেখা থাকবে। এর ফলে fontconfig ফন্ট সাব-সিস্টেমের দ্বারা এই ফন্ট ব্যবহার করার জন্য প্রথমে এই ফাইলটি (gunzip কমান্ডের সাহায্যে) ডি-কম্প্রেস করা আবশ্যক।

fontconfig/Xft, GTK+ ১.২ ভিত্তিক নতুন ফন্ট সিস্টেমে পরিবর্তন করার ফলে ফন্ট সম্পর্কিত পছন্দ ডায়লগ বক্সের মাধ্যমে করা পরিবর্তনের প্রভাব কোনো অ্যাপ্লিকেশনের উপর পড়বে না। এই অ্যাপ্লিকেশনগুলির জন্য ফন্ট কনফিগার করতে হলে ~/.gtkrc.mine ফাইলে নিম্নলিখিত পংক্তিগুলি যোগ করা আবশ্যক:

style "user-font" {

fontset = "<font-specification>"

}

widget_class "*" style "user-font"

(<font-specification>-র পরিবর্তে X অ্যাপ্লিকেশনগুলির দ্বারা ব্যবহৃত ফন্টের বিন্যাস উল্লেখ করুন, যেমন "-adobe-helvetica-medium-r-normal--*-120-*-*-*-*-*-*"।)

LVM2 কমান্ডের একটি সম্পূর্ণ সংকলন /usr/sbin/-এ ইনস্টল করা হয়েছে। যেসব বুট পরিবেশে /usr/ উপলব্ধ হয় না, সেখানে প্রত্যেকটি কমান্ডের পূর্বে /sbin/lvm.static লেখা আবশ্যক (উদাহরণস্বরূপ /sbin/lvm.static vgchange -ay)।

যেসব পরিবেশে /usr/ উপলব্ধ রয়েছে, সেখানে কমান্ডের পূর্বে lvm লেখার প্রয়োজন নেই (উদাহরণস্বরূপ /usr/sbin/lvm vgchange -ay-র পরিবর্তে /usr/sbin/vgchange -ay লিখুন)।

২.৪ কার্নেল চালানো হলে, নতুন LVM2 কমান্ডগুলি (যেমন /usr/sbin/vgchange -ay এবং /sbin/lvm.static vgchange -ay) তা সনাক্ত করতে সক্ষম এবং প্রয়োজনে নীরবে পুরোনো LVM1 কমান্ডগুলি প্রয়োগ করে। LVM1 কমান্ডগুলি পরিবর্তন করা হয়েছে এবং এগুলির শেষে এখন ".lvm1" লেখা হয় (উদাহরণ, /sbin/vgchange.lvm1 -ay)।

সিস্টেম পুনরায় আরম্ভ অথবা বুট করা হলে nscd name service cache daemon-টি এখন স্থায়ী ক্যাশে ব্যবহার করতে পারে। প্রত্যেকটি ডাটাবেস (যথাক্রমে ব্যবহারকারী, দল এবং হোস্ট) স্থায়ী করার জন্য নির্ধারণ করা সম্ভব। এই জন্য /etc/nscd.conf ফাইলের সঠিক স্থানে "yes" মান নির্দিষ্ট করা আবশ্যক। অপ্রয়োজনীয় হিসাবে ধার্য না হওয়া অবধি ক্যাশে থেকে কোনো বস্তু অপসারিত হয় না। যে সব প্রয়োজনীয় বস্তুগুলির নির্ধারিত মেয়াদ উত্তীর্ণ হয়ে যায় সেগুলি স্বয়ংক্রিয়ভাবে পুনরায় লোড করে নেওয়া হয়। এর ফলে ডিরেক্টরি এবং name পরিসেবা অস্থায়ীরূপে উপলব্ধ না থাকলে বিশেষ লাভ হওয়া সম্ভব।

ডিফল্ট SELinux সুরক্ষা কনফিগারেশনের নির্ধারিত নীতি অনুযায়ী এই ডেমনটির পরিচালনার ব্যবস্থা করা হয়। ডেমনটির দ্বারা ব্যবহৃত সিস্টেম-অবজেক্টের জন্য সুস্পষ্টরূপে প্রবেশাধিকার প্রদান করে অথবা প্রত্যাখ্যান করে নিরাপত্তার উন্নতি করা হয়। কিন্ত এর ফলে পূর্বে চলমান কনফিগারেশন বিকল হওয়ার সম্ভাবনা থাকে। এই কারণে SELinux-র কার্য-প্রক্রিয়া সম্পর্কে অবগত থাকা প্রয়োজন যার ফলে কনফিগারেশন নিরাপদ ও সক্রিয় রাখা সম্ভব হবে।

SELinux সম্বন্ধে অধিক বিবরণের জন্য Red Hat SELinux Policy Guide পড়ুন যা http://www.redhat.com/docs-এ উপস্থিত রয়েছে।