Red Hat Enterprise Linux AS 4 रिलीज नोट्स

Red Hat Enterprise Linux 4 के साथ दिया गया glibc का संस्करण यथाशीघ्र आंकड़ा करप्शन को रोकने के लिये अतिरिक्त आंतरिक सेनिटी चेक का निष्पादन करता है. मूलभूत रूप से करप्शन खोजा जाना चाहिये, मानक त्रुटि पर निम्नलिखित के समान एक संदेश प्रदर्शित होगी (और syslog के मार्फत लॉग होगी अगर stderr खुला नहीं है):

*** glibc खोजा गया *** डबल फ्री या करप्शन: 0x0937d008 ***

मूलभूत रूप से इस त्रुटि को उत्पन्न करने वाला प्रोग्राम भी खत्म हो जायेगा; हालांकि यह (और यदि त्रुटि संदेश उत्पन्न होता है या नहीं) MALLOC_CHECK_ वातावरण चर के मार्फत नियंत्रित की जा सकेगी. निम्न जमावट समर्थित है:

अगर आपके पास तीसरी पार्टी ISV से एक प्रोग्राम है जो इन करप्शन बंधन को जन्म दिया है और एक संदेश देती है, तो आपको एक अनुप्रयोग विक्रेता के साथ एक जांच रिपोर्ट फाइल करनी चाहिये क्योंकि यह एक गंभीर बग को इंगित करता है.

Red Hat Enterprise Linux 4 में hugemem कर्नेल के रूप में एक कर्नेल शामिल है. यह कर्नेल 4GB प्रति प्रक्रिया उपयोक्ता स्थान (बनाम अन्य कर्नेल के लिये 3GB) और 4GB प्रत्यक्ष कर्नेल स्थान का समर्थन करती है. इस कर्नेल का प्रयोग 64GB मुख्य स्मृति के साथ Red Hat Enterprise Linux को सिस्टम पर चलाने की अनुमति देता है. hugemem कर्नेल की जरूरत 16GB स्मृति से ज्यादा सिस्टम विन्यास की पूरी स्मृति का उपयोग करने के लिये होता है. hugemem कर्नेल कम स्मृति के साथ चलने वाले विन्यास को फायदा पहुंचा सकता है (उदाहरण के लिए, अगर ऐसा अनुप्रयोग चला रहा है जो प्रति प्रक्रिया उपयोक्ता स्थान से फायदा ले सकता है.)

ह्यूजमैम कर्नेल को अधिष्ठापित करने के लिये निम्नलिखित समादेश में दाखिल हों जब आप रूट रहें:

rpm -ivh <kernel-rpm>

            

(जहां <kernel-rpm> ह्यूजमैन कर्नेल RPM फाइल का नाम है — kernel-hugemem-2.6.9-1.648_EL.i686.rpm, उदाहरण के लिए.)

नव अधिष्ठापित ह्यूजमैम कर्नेल के चयन को सुनिश्चित करते हुये अधिष्ठापन के समाप्त होने पर अपने सिस्टम को रिबूट करें. विधिवत कामकाज के लिये अपने सिस्टम को जांचने के बाद आपको /boot/grub/grub.conf फाइल को रूपांतरित करना चाहिये ताकि ह्यूजमैम कर्नेल मूलभूत रूप से बूट हो सके.

हालांकि Red Hat Enterprise Linux 4 में rawio के लिये समर्थन शामिल है, यह अब एक पदावनत अंतरफलक है. अगर आपका अनुप्रयोग इस अंतरफलक की मदद से युक्ति अभिगम का निष्पादन करती है, Red Hat आपको अपने अनुप्रयोग को रूपांतरित करने के लिये O_DIRECT फ्लैग से ब्लॉक युक्ति खोलने हेतु प्रोत्साहित करती है. rawio अंतरफलक Red Hat Enterprise Linux 4 के लिये उपस्थित रहेगी, लेकिन भविष्य के रिलीज में हटाये जाने का अभ्यर्थी है.

फाइल सिस्टम पर अतुल्यकालिक I/O (AIO) अभी O_DIRECT या गैर बफर मोड में समर्थित है. इसे भी नोट करें कि अतुल्यकालिक पोल अंतरफलक अब मौजूद नहीं रहेगा और पाइप पर वह AIO अब समर्थित नहीं रहेगा.

ध्वनि उपसिस्टम अब ALSA पर आधारित है; OSS मौड्यूल अब उपलब्ध नहीं है.

कर्नेल के "hugepage" प्रकार्यात्मकता को प्रयोग करने वाले सिस्टम वातावरण को जानना चाहिये कि इस फीचर को नियंत्रित करने वाली /proc/ प्रविष्टि Red Hat Enterprise Linux 3 और Red Hat Enterprise Linux 4 के दौरान बदल गई है:

Red Hat Enterprise Linux 4 के साथ लाया गया कर्नेल अब Enhanced Disk Device (EDD) पोलिंग को शामिल किये है, जो बूट करने योग्य डिस्क युक्ति सूचना के लिये डिस्क नियंत्रक BIOS से प्रश्न पूछता है और इसे एक प्रविष्टि के रूप में /sys फाइल सिस्टम में संग्रहित करता है.

EDD से संबंधित दो महत्वपूर्ण कर्नेल समादेश रेखा विकल्प को भी जोड़ा जा रहा है:

Red Hat Enterprise Linux 4का आरंभिक रिलीज USB हार्ड डिस्क चालन का समर्थन नहीं करता है. हालांकि, अन्य USB भंडारण युक्तियां, जैसे कि फ्लैश मीडिया, CD-ROM और DVD-ROM युक्तियां अभी समर्थित है.

Red Hat Enterprise Linux 4 के साथ लाया गया कर्नेल नये megaraid_mbox चालक को LSI लॉजिक से शामिल किये हुये है जो megaraid चालक को विस्थापित करता है. megaraid_mbox चालक एक उन्नत डिजायन रखता है, 2.6 कर्नेल के साथ सुसंगत है, और नवीनतम हार्डवेयर के लिये समर्थन को शामिल किये हुये है. हालांकि, megaraid_mbox कुछ पुराने फोल्डर का समर्थन नहीं करता है जो megaraid चालक के द्वारा समर्थित है.

निम्नलिखित PCI विक्रेता ID और युक्ति ID जोड़ा megaraid_mbox driver के द्वारा समर्थित नहीं है:

vendor, device

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

lspci -n समादेश को अधिष्ठापित एडाप्टर के लिये खास मशीन में ID को प्रदर्शित करने में प्रयोग किया जा सकता है. इन ID के साथ उत्पादों को निम्नलिखित मॉडल नाम से (लेकिन सीमित नहीं है) जाना जाता है:

Dell और LSI Logic दोनों ने इशारा दिया है कि वे अब इन मॉडलों को 2.6 कर्नेल के लिये समर्थन नहीं देंगे. परिणामतः, ये एडाप्टर Red Hat Enterprise Linux 4.में समर्थित नहीं है.

Red Hat Enterprise Linux 4 का आरंभिक रिलीज iSCSI सॉफ्टवेयर initiator या target समर्थन को शामिल नहीं करता है. iSCSI के लिये समर्थन को Red Hat Enterprise Linux 4 के आगामी नवीनीकरण में जोड़े जाने के लिये मूल्यांकन किया जा रहा है.

Emulex LightPulse Fibre Channel चालक (lpfc) इस समय Linux 2.6 कर्नेल में संभावित समावेशन के लिये जन समीक्षा के दौर से गुजर रही है. यह 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 में आलेखीय ईडाक क्लाइंट का अद्यतन संस्करण शामिल है. इन सबके साथ इस संस्करण में कई नए फीचर शामिल हैं:

gimp-perl संकुल Red Hat Enterprise Linux 4 से हटा दी गई है क्योंकि GIMP को 2.0 में अद्यतन कर दिया गया है और Perl बंधन न तो तैयार था और न ही मुख्य संकुल का हिस्सा था.

GIMP में Perl स्क्रिप्ट उपयोक्ताओं को Gimp Perll मौड्यूल http://www.gimp.org/downloads/ से अधिष्ठापन करना चाहिये.

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 मेल ट्रांसपोर्ट एजेंट (MTA) स्थानीय कंप्यूटर के अलावा किसी अन्य मेजबान से संजाल संबंधन स्वीकार नहीं करता है. अगर आप Sendmail को एक सर्वर के रूप में अन्य क्लाइंट के लिये विन्यस्त करना चाहते हैं तो आपको जरूर /etc/mail/sendmail.mc को संपादित करना चाहिये और DAEMON_OPTIONS पंक्ति को बदलना चाहिये संजाल युक्तियों पर सुनने के लिये (dnl कमेंट डिलिमिटर के प्रयोग से इस विकल्प को कमेंट आउट करें.). निम्नलिखित समादेश (बतौर रूट) चलाकर आप तब /etc/mail/sendmail.cf को पुनः उत्पन्न करें.

make -C /etc/mail

नोट करें कि आप इसे काम करने के लिए sendmail-cf संकुल जरूर अधिष्ठापित रखें.

मूलभूत SELinux सुरक्षा विन्यास के अंतर्गत httpd को लक्षित नीति के द्वारा कवर किया जाता है. यह सुरक्षा और वेब सर्वर स्थायित्व को सिस्टम में विशिष्ट रूप से अभिगम देकर या न देकर बढाता है. हालांकि इसमें क्षमता है कि यह पहले से काम कर रहे विन्यास को काम करने से रोक सकता है (जैसे कि उनके लिये जो PHP का प्रयोग करते हैं), आप समझ सकते हैं कि कैसे SELinux यह सुनिश्चित करने के लिये काम करता है कि आपका विन्यास सुरक्षित और कार्यशील दोनों है.

उदाहरण के लिए, बूलियन ~/public_html/ में मौजूद सामग्री को पढ़ने के लिये httpd में विशेष अनुमति देता है जबतक कि वे httpd_sys_content_t सुरक्षा संदर्भ के साथ लेबल रहते हैं. Apache डीमन उन वस्तुओं का अभिगम नहीं कर सकता है जिसके पास SELinux के द्वारा सुरक्षा संदर्भ httpd में विशिष्ट रूप से दिया गया नहीं है.

Apache अभिगम की अनुमति आवश्यक कार्यों के लिये देकर सिस्टम को गलत और कुविन्यस्त httpd डीमन से सुरक्षित रखा जाता है.

SELinux फाइल संदर्भ लेबल, प्रशासक और उपयोक्ता के साथ ही साथ मानक Linux निर्देशिका और फाइल अनुमति - दोनों की आवश्यकता के कारण फाइल को पुनः लेबल देने के बारे में जानने की जरूरत होगी. पुनः लेबल करने के उदाहरण में निम्न समादेश शामिल हैं (एक निर्देशिका की सामग्री के रिलेबलिंग के लिये और दूसरा एकल फाइल के रिलेबलिंग के लिये):

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 टैब के अंतर्गत, Modify SELinux Policy क्षेत्र के अंतर्गत, आप बूलियन मान को Apache के लिये रूपांतरित कर सकते हैं. अगर आप चाहें तो आप Disable SELinux protection for httpd daemon के लिये चयन कर सकते हैं, जो unconfined_t से (मूलभूत रूप में जो SELinux के बिना मानक Linux सुरक्षा जैसी पारदर्शिता के साथ काम करती है) httpd_t जैसे विशिष्ट डीमन प्रकार में संक्रमण को निष्क्रिय करता है. इस संक्रमण को निष्क्रिय किया जाना इसे मानक Linux सुरक्षा में लौटाते हुये SELinux को प्रभावी रूप से बंद कर देता है.

Apache और SELinux नीति के बारे में अधिक जानकारी के लिए, Red Hat SELinux Policy Guide को http://www.redhat.com/docs पर देखें.

मूलभूत रूप से httpd डीमन अब C लोकेल के प्रयोग से शुरू की गई है बजाय विन्यस्त सिस्टम लोकेल जमावट के. HTTPD_LANG चर को /etc/sysconfig/httpd फाइल में व्यवस्थित करके इस व्यवहार को बदला जा सकता है.

मूलभूत /etc/php.ini विन्यास फाइल को बजाय "विकास" मूलभूत के "उत्पादन" मूलभूत के रूप में प्रयोग के लिये बदल दिया गया है; मुख्य अंतर हैं:

यह संकुल अब समाकलन के लिये Apache httpd 2.0 के साथ "apache2handler" SAPI का प्रयोग करता है बजाय "apache2filter" SAPI के. अगर पहले रिलीज से उन्नयन हो रहा है तो SetOutputFilter डायरेक्टिव को /etc/httpd/conf.d/php.conf फाइल से हटा लिया जाना चाहिये.

PHP विस्तारण मौड्यूल के संकुलन में निम्न बदलाव किया गया है:

Red Hat Enterprise Linux 4 में xorg-x11-deprecated-libs संकुल समाहित है. यह संकुल X11-संबंधित लाइब्रेरी को समाहित किये है जो पदावनत है और भविष्य के संस्करण से हटाया जा सकता है. इस रूप में पदावनत लाइब्रेरी के संकुलन से मौजूदा अनुप्रयोग के साथ द्विपदीय सुसंगतता का अनुरक्षण किया जाता है जबकि तीसरी पार्टी सॉफ्टवेयर उपलब्धकर्ता को अनुप्रयोग को इन लाइब्रेरी से अलग संक्रमण के लिये समय उपलब्ध कराता है.

अभी यह संकुल Xprint लाइब्रेरी (libXp) को समाहित किये है. यह लाइब्रेरी नये अनुप्रयोग विकास के लिये प्रयोग नहीं किया जाना चाहिये. अनुप्रयोग जो इस लाइब्रेरी को मौजूदा रूप से प्रयोग करता है को समर्थित libgnomeprint/libgnomeprintui प्रिंटिंग APIs में भेजना शुरू करना चाहिये.

X विंडो सिस्टम के अंतर्गत Red Hat Enterprise Linux ( इसके पहले औऱ Red Hat Linux के संस्करण) के हाल के संस्करण में फांट संबंधित मुद्दों के संदर्भ में कुछ भ्रम रहा है. इस समय दो फांट सबसिस्टम है अपनी अलग विशेषताओं के साथ:

- मौलिक (15+ साल पुराना) उपसिस्टम को "core X font subsystem" के रूप में हवाला दिया जाता है. इस उपसिस्टम के द्वारा रेंडर किया हुआ फांट एंटी एलियास नहीं हैं, X सर्वर द्वारा नियंत्रित किया जाता है और इस तरह का नाम रखता है:

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

नया फांट सबसिस्टम "fontconfig" के रूप में जाना जाता है और फांट फाइल में अनुप्रयोगों को सीधी अनुमति देता है. Fontconfig का प्रयोग सीधा "Xft" लाइब्रेरी के साथ होता है जो fontconfig फांट को रेंडर के लिये एंटीएलियासिंग के साथ स्क्रीन में अनुप्रयोग को अनुमति देता है. Fontconfig ज्यादा मित्रता पूर्ण नाम का प्रयोग करता है जैसे:

Luxi Sans-10

कालांतर में fontconfig/Xft कोर X फांट सबसिस्टम को प्रतिस्थापित करेगा. इस समय में Qt 3 या GTK 2 टूलकिट (जो KDE और GNOME अनुप्रयोग) को प्रयोग करने वाले अनुप्रयोग fontconfig और Xft फांट सबसिस्टम का प्रयोग करता है ज्यादातर अन्य कोर X फांट का प्रयोग करते हैं.

भविष्य में Red Hat Enterprise Linux मात्र XFS फाँट सर्वर के बजाय सिर्फ fontconfig/Xft को मूलभूत फांट अभिगम विधि के रूप में समर्थन करेगा.

नोट: फाँट उपसिस्टम प्रयोग के लिये एक अपवाद OpenOffice.org है (जो इसके अपने फांट रेंडरिंग प्रौद्यागिकी का प्रयोग करता है).

अगर आप अपने Red Hat Enterprise Linux 4 सिस्टम पर नया फाँट जोड़ना चाहते हैं तो आप जाने कि आवश्यक चरण निर्भर करती है कि किस फांट सबसिस्ट पर नये फांट काम प्रयोग किया जाना है. कोर X फांट सबसिस्टम के लिये आप अवश्य:

1. /usr/share/fonts/local/ निर्देशिका बनायें(अगर यह पहले से मौजूद नहीं है):

mkdir /usr/share/fonts/local/

2. नए फाँट फाइल को /usr/share/fonts/local/ में कॉपी करें.

3. फाँट सूचना को निम्न समादेश निर्गत कर अद्यतन करें (नोट करें कि संरूपण सीमा के कारण निम्न समादेश एक से ज्यादा पंक्ति में दिख सकती है, लेकिन व्यवहार में प्रत्येक समादेश एक पंक्ति में दाखिल होनी चाहिये):

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

mkfontdir /usr/share/fonts/local/

4. अगर आपको /usr/share/fonts/local/ बनाना पड़ता था, तो आप अवश्य इसे X font server (xfs) path में जोड़ें:

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

fontconfig फांट सबसिस्टम में नया फांट जोड़ना काफी सरल है; नयी फांट फाइल को सिर्फ /usr/share/fonts/ निर्देशिका में कॉपी कर देना जरूरी रह गया है (~/.fonts/ निर्देशिका में फाँट फाइल को कॉपी करके एक व्यक्ति अपने व्यक्तिगत फाँट विन्यास को रूपांतरित कर सकता है).

नए फाँट के कॉपी किये जाने के बाद, fc-cache का उपयोग फाँट सूचना कैश के अद्यतन के लिए करें:

fc-cache <directory>

(जहां <directory> या तो यह /usr/share/fonts/ या ~/.fonts/ निर्देशिका होगी.)

व्यक्ति अब आलेखीय रूप से फांट अधिष्ठापन कर सकेंगे, fonts:/// को Nautilus में ब्राउज कर, और नए फांट फाइल को वहां खींचकर.

नोट: अगर फांट फाइल नाम का ".gz" से अंत होता है, तो इसे gzip से संकुचित किया गया है और अवश्य विसंकुचित (gunzip समादेश से) किया जाना चाहिये इसके पहले कि fontconfig फांट सबसिस्टम फांट का प्रयोग कर सके.

fontconfig/Xft पर आधारित नये फांट सिस्टम में संक्रमण के कारण Font Preferences संवाद के मार्फत किये गये किसी परिवर्तन से GTK+ 1.2 अनुप्रयोग प्रभावित नहीं होगा. इन अनुप्रयोगों के लिये ~/.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) जांचता है अगर आप एक 2.4 कर्नेल चला रहे हैं. औऱ साफ रूप से पुराने LVM1 समादेश को सक्रिय कर सकते हैं अगर उचित है तो. LVM2 समादेश को ".lvm1" से अंत होने के लिये पुनर्नामकरण किया जा रहा है (उदाहरण के लिए /sbin/vgchange.lvm1 -ay).

nscd नाम सेवा कैश डीमन पुनर्प्रारंभ से सिस्टम रिबूट तक एक सतत् कैश का अनुरक्षण करती है. /etc/nscd.conf में उचित पंक्ति में "yes" को व्यवस्थित करके प्रत्येक डाटाबेस ( क्रमशः उपयोक्ता, समूह, और मोजबान) को सतत रहने के लिये चयनित किया जा सकता है. प्रविष्टि को तबतक नहीं हटाया जाता है जबतक कि वे किसी फायदे के नहीं रह जाते हैं. वे सभी प्रविष्टि जिसका जीवनकाल समाप्त हो गया है लेकिन अन्यथा रूचिकर है, स्वतः पुनर्भारित किया जाता है जो उस स्थिति में सहायता करता है जहां निर्देशिका और नाम सेवायें अस्थायी रूप से अनुपलब्ध हो जाती हैं.

मूलभूत SELinux सुरक्षा विन्यास के अंतर्गत, यह डीमन लक्षित नीति के द्वारा कवर की गई है. यह सिस्टम की वस्तु में विशेष रूप से अभिगम देकर या नहीं देकर सिस्टम की सुरक्षा को बढाता है जैसा डीमन सामान्यतः प्रयोग करता है. हालांकि इसकी संभावना है कि पहले काम करने वाले विन्यास अब काम नहीं करेंगे, आपको जरूर समझना चाहिये कि कैसे SELinux आपके विन्यास की सुरक्षा और प्रकार्यात्मकता को सुनिश्चित करने के लिये काम करता है.

SELinux नीति के बारे में अधिक जानकारी के लिए Red Hat SELinux Policy Guide को http://www.redhat.com/docs पर जाकर देखें.