Red Hat Enterprise Linux AS 4 પ્રકાશન નોંધો

Red Hat Enterprise Linux 4 સાથે પૂરી પાડવામાં આવેલ glibc ની આવૃત્તિ માહિતીની સાચવણી માટે અને માહિતીના નાશથી બચાવવા માટે આંતરિક ચકાસણીઓ જેટલું શક્ય હોય તેટલું જલદી કરે છે. મૂળભુત રીતે, શું નાશ શોધી શકાશે, આના જેવો સંદેશો પ્રમાણભૂત ભૂલ સંદેશાની જેમ પ્રદર્શિત થશે (અથવા syslog મારફતે જો stderr ખુલ્લું ના હોય):

*** glibc મળી આવ્યું *** double free or corruption: 0x0937d008 ***

મૂળભુત રીતે, કાર્યક્રમ કે જેણે આ ભૂલ પેદા કરી તે પણ મારી નંખાશે; તેમ છતાં પણ, આ (અને ભૂલ સંદેશો પેદા થાય કે ના થાય તોપણ) MALLOC_CHECK_ પર્યાવરણીય ચલ દ્વારા નિયંત્રિત થાય છે. નીચેનાં સુયોજનો આધારભૂત છે:

શું તમારી ત્રીજી વ્યક્તિ ISV કાર્યક્રમ છે કે જે આ ભંગાણ ચકાસણીઓ બદલે અને સંદેશો પ્રદર્શિત કરે, તમારે કાર્યક્રમના વિક્રેતાને ઉણપ અહેવાલ ફાઈલ કરવો જોઈએ, કારણ કે આ જોખમી ભૂલ સૂચવે છે.

Red Hat Enterprise Linux 4 એ hugemem કર્નલ તરીકે ઓળખાતી કર્નલનો સમાવેશ કરે છે. આ કર્નલ પ્રક્રિયા પ્રતિ 4GB વપરાશકર્તા જગ્યા (અન્ય કર્નલો માટે 3GB ), અને 4GB સીધી કર્નલ જગ્યા વાપરે છે. આ કર્નલને વાપરવાનું Red Hat Enterprise Linux ને 64GB ની મુખ્ય મેમરીની સિસ્ટમો પર ચલાવવા માટે પરવાનગી આપે છે. 16GB ની મેમરીનો સમાવેશ કરતાં સિસ્ટમ રૂપરેખાંકનની બધી મેમરી વાપરવા માટે hugemem કર્નલ જરૂરી છે. hugemem ઓછી મેમરી સાથે ચાલતા રૂપરેખાંકનો સાથે પણ ચલાવવાનો લાભ આપે છે (જો કાર્યક્રમ ચાલી રહ્યો હોય કે જે મોટી પ્રક્રિયા પ્રતિ વપરાશકર્તા જગ્યા વાપરી રહી હોય, ઉદાહરણ તરીકે.)

hugemem કર્નલ સ્થાપિત કરવા માટે, રૂટ તરીકે પ્રવેશ કર્યા પછી નીચેનો આદેશ ચલાવો:

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 માટે આધાર સમાવે તેમછતાં પણ, તે હવે નીચી આવૃત્તિ કરાયેલ ઈન્ટરફેસ છે. જો તમારો કાર્યક્રમ આ ઈન્ટરફેસની મદદથી ઉપકરણ ચલાવવાનું પસંદ કરે, તો Red Hat તમને બ્લોક ઉપકરણને O_DIRECT નિશાની સાથે ખોલવા માટે તમારો કાર્યક્રમ સુધારવા માટે પ્રેરે છે. Red Hat Enterprise Linux 4 ના જીવન માટે rawio અસ્તિત્વમાં હશે, પરંતુ તે ભવિષ્યના પ્રકાશનો માટે દૂર કરવાનો ઉમેદવાર છે.

ફાઈલ સિસ્ટમ પર Asynchronous I/O (AIO) વર્તમાનમાં માત્ર O_DIRECT માં, અથવા non-buffered સ્થિતિમાં આધારભૂત છે. અને એ પણ ધ્યાનમાં રાખો કે asynchronous poll ઈન્ટરફેસ લાંબા સમય સુધી અસ્તિત્વમાં નથી, અને તે pipes પરનું AI લાંબા સમય સુધી આધારભૂત નથી.

ધ્વનિ ઉપસિસ્ટમ હવે 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 સંગ્રહ ઉપકરણો, જેમ કે flash મીડિયા, CD-ROM અને DVD-ROM ઉપકરણો વર્તમાનમાં આધારભૂત છે.

Red Hat Enterprise Linux 4 સાથે સમાવિષ્ટ કર્નલ LSI લોજીકમાંથી નવો megaraid_mbox ડ્રાઈવર સમાવે છે, કે જે megaraid ડ્રાઈવરની બદલી કરે છે. megaraid_mbox ડ્રાઈવર પાસે સુધારેલ ડિઝાઈન છે, જે 2.6 કર્નલ સાથે સુસંગત છે, અને તાજેતરના હાર્ડવેર માટે આધારનો સમાવેશ કરે છે. તેમછતાં પણ, megaraid_mbox અમુક જૂના હાર્ડવેરો કે જે megaraid ડ્રાઈવર દ્વારા આધારભૂત હતા તેને આધાર આપતું નથી.

નીચેના PCI વિક્રેતા ID અને ઉપકરણ ID જોડીઓ સાથેના એડેપ્ટરો megaraid_mbox ડ્રાઈવર દ્વારા આધારભૂત નથી:

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 ફાયબર ચેનલ ડ્રાઈવર (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 બાઈન્ડીંગો ક્યાં તો તૈયાર નથી અથવા મુખ્ય પેકેજનો ભાગ નથી.

Perl સ્ક્રિપ્ટના વપરાશકર્તાઓ GIMP માં Gimp Perl મોડ્યુલ 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 mail transport agent (MTA) સ્થાનિક કમ્પ્યુટર સિવાય કોઈપણ યજમાનમાંથી નેટવર્ક જોડાણો સ્વીકારતું નથી. જો તમે Sendmail ને સર્વર તરીકે બીજા ક્લાઈન્ટો માટે રૂપરેખાંકિત કરવા માંગતા હોય, તો તમારે /etc/mail/sendmail.mc માં ફેરફારો કરવા જ જોઈએ અને DAEMON_OPTIONS લીટીમાં ફેરફાર કરવા જોઈએ નેટવર્ક ઉપકરણો પર સાંભળવા માટે (અથવા આ વિકલ્પને ટિપ્પળી કરી દેવી જોઈએ dnl ટિપ્પળી કરનારની મદદથી). પછી તમારે નીચેનો આદેશ (રુટ તરીકે) ચલાવીને /etc/mail/sendmail.cf ફરીથી બનાવવી જ જોઈએ:

make -C /etc/mail

નોંધ કરો કે તમારી પાસે આ કામ કરવા માટે sendmail-cf પેકેજ સ્થાપિત હોવું જ જોઈએ.

મૂળભુત SELinux સુરક્ષા રૂપરેખાંકન હેઠળ, httpd એ targeted નીતિ હેઠળ આવરી લેવાય છે. આ સિસ્ટમ ઓબ્જેક્ટોને httpd વપરાશ આપીને અથવા મનાઈ કરીને સુરક્ષા અને વેબ સર્વર ક્ષમતા વધારે છે. તેમછતાં પણ, તેની પાસે પહેલાના કામ આપતાં રૂપરેખાંકનોમાં પોટેન્શિયલના કારણો હોવાના લીધે (જેમ કે જેઓ PHP વાપરે છે) તેઓ લાંબા સમય સુધી કામ કરે નહિં, તે તમારે તમારુ રૂપરેખાંકન બંને સુરક્ષા અને વિધેયાત્મક છે તેની ખાતરી કરવા માટે કેવી રીતે SELinux કામ કરે તે સમજવું જ જોઈએ.

ઉદાહરણ તરીકે, ~/public_html/ માંના ઓબ્જેક્ટો જ્યાં સુધી સુરક્ષા સંદર્ભ httpd_sys_content_t થી લેબલ થયેલા હોય ત્યાં સુધી તેમને વાંચવા માટે httpd ને સ્પષ્ટ પરવાનગી આપવા માટે બુલિયન સુયોજિત કરી શકાવું જોઈએ. અપાચે ડિમન ઓબ્જેક્ટો (ફાઈલો, કાર્યક્રમો, ઉપકરણો, અને અન્ય પ્રક્રિયાઓ) વાપરી શકતું નથી કે જેઓ પાસે સુરક્ષા સંદર્ભ હોય કે જે ખાસ કરીને SELinux દ્વારા httpd માં પરવાનગી મળી નહિં હોય.

અપાચેનો વપરાશ માત્ર તેને જરૂરી હોય તેટલા વિધેયો માટે જ માન્ય કરીને, સિસ્ટમની સમજૂતી થયેલ અથવા અયોગ્ય રીતે રૂપરેખાંકિત થયેલ httpd ડિમનોથી સુરક્ષા કરી શકાય.

બંને પ્રમાણભૂત Linux ડિરેક્ટરીઓ અને ફાઈલની પરવાનગીઓ અને એ જ રીતે SELinux ની જરૂરિયાતને કારણે ફાઈલ સંદર્ભ લેબલો, સંચાલકો અને વપરાશકર્તાઓને ફાઈલોને પુનઃલેબલ કરવા વિશે જાણકારી હોવી જોઈએ. પુનઃલેબલ કરવાના ઉદાહરણો નીચેના આદેશોનો સમાવેશ કરે છે (એક પુનરાવર્તિત રીતે ડિરેક્ટરીના સમાવિષ્ટોને પુનઃલેબલ કરવા માટે, અને એક માત્ર એક જ ફાઈલને પુનઃલેબલ કરવા માટે):

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

            

અપાચેના માન્ય પ્રકારોની યાદી પરના સંદર્ભ સાથે લેબલ થયેલ નહિં હોય તેવી ફાઈલ અથવા ડિરેક્ટરી 403 Forbidden ભૂલ પેદા કરશે.

તમે બુલિયન કિંમતો રૂપરેખાંકિત કરી શકો છો અથવા પસંદ કરીને system-config-securitylevel ની મદદથી targeted નીતિને નિષ્ક્રિય કરી શકો છો જે ખાલી અપાચે (અથવા આવરિત ડિમનોમાંનુ કોઈપણ) માટે આવરણ છે. SELinux ટેબ હેઠળ, SELinux નીતિ સુધારો વિસ્તારમાં, તમે અપાચે માટે બુલિયન કિંમતો સુધારી શકો છો. જો તમે ઈચ્છો, તો તમે httpd ડિમન માટે SELinux બચાવ પસંદ કરી શકો છો, જે unconfined_t (મૂળભુત પ્રકાર કે જે SELinux વિના પ્રમાણભૂત Linux સુરક્ષા તરીકે પારદર્શક રીતે વર્તે છે) માંથી ચોક્કસ પ્રકારના ડિમનમાં, એટલે કે, httpd_t માં પરિવહન નિષ્ક્રિય કરી શકો છો. આ પરિવહનને નિષ્ક્રિય કરવાનું અસરકારક રીતે SELinux આવરણને તે ડિમન માટે બંધ કરે છે, તેને પ્રમાણભૂત Linux સુરક્ષા માટે માત્ર મેળવી રહ્યા છીએ.

અપાચે અને SELinux નીતિ વિશે વધુ જાણકારી માટે, Red Hat SELinux નીતિ માર્ગદર્શન અંહિ http://www.redhat.com/docs સંદર્ભ લો.

મૂળભુત રીતે, httpd ડિમન હવે C લોકેલ દ્વારા શરૂ થઈ ગયું, રૂપરેખાંકિત સિસ્ટમ લોકેલ સુયોજનો વાપરવાની જગ્યાએ. આ વર્તણૂક HTTPD_LANG ચલને /etc/sysconfig/httpd ફાઈલમાં સુયોજિત કરીને બદલી શકાય છે.

મૂળભુત /etc/php.ini રૂપરેખાંકન ફાઈલ "ઉત્પાદન" મૂળભુતો વાપરવા માટે બદલાઈ ગઈ છે "વિકાસ" મૂળભુતો વાપરવાની જગ્યાએ; નોંધપાત્ર તફાવતો છે:

અપાચે httpd 2.0 સાથે સંકલન માટે પેકેજ હવે "apache2filter" SAPI ની જગ્યાએ "apache2handler" SAPI ને વાપરે છે. જો પહેલાના પ્રકાશનોમાંથી સુધારો કરી રહ્યા હોય, તો SetOutputFilter directives /etc/httpd/conf.d/php.conf ફાઈલમાંથી દૂર થવા જોઈએ.

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 વિન્ડો સિસ્ટમ હેઠળ ફોન્ટ-સંબંધિત મુદ્દાઓને અનુલક્ષીને ત્યાં અમુક વિવાદ હતો. વર્તમાન સમયે, ત્યાં બે ફોન્ટ ઉપસિસ્ટમો છે, દરેક અલગ લક્ષણો સાથે:

- મૂળ (15+ વર્ષ જૂની) ઉપસિસ્ટમ એ "મૂળ X ફોન્ટ ઉપસિસ્ટમ" તરીકે ઓળખાય છે. આ ઉપસિસ્ટમ દ્વારા રેન્ડર થતા ફોન્ટ એન્ટીએલિઆઝ થયા નથી, તેઓ 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 એ માત્ર fontconfig/Xft ને XFS ફોન્ટ સર્વરની જગ્યાએ મૂળભુત સ્થાનિક ફોન્ટ વપરાશ પદ્ધતિ તરીકે આધાર આપશે.

નોંધ: ઉપર દર્શાવ્યા અનુસાર ફોન્ટ ઉપસિસ્ટમના વપરાશનો અપવાદ 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 font server (xfs) પથમાં દાખલ કરવું જ જોઈએ:

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

નવા ફોન્ટને fontconfig ફોન્ટ ઉપસિસ્ટમમાં ઉમેરવાનું એ ખૂબ સીધું જ છે; નવી ફોન્ટ ફાઈલ માત્ર /usr/share/fonts/ ડિરેક્ટરીમાં નકલ કરવાની જ જરૂર છે (અંગત વપરાશકર્તાઓ તેમના પોતાના ફોન્ટ રૂપરેખાંકનો ફોન્ટને ~/.fonts/ ડિરેક્ટરીમાં નકલ કરીને સુધારી શકે છે).

નવા ફોન્ટની નકલ થઈ ગયા પછી, ફોન્ટની જાણકારી કેશમાં બદલવા માટે fc-cache વાપરો:

fc-cache <directory>

(જ્યાં <directory> ક્યાં તો /usr/share/fonts/ અથવા ~/.fonts/ ડિરેક્ટરીઓ હોઈ શકે.)

અંગત વપરાશકર્તાઓ પણ ફોન્ટને ગ્રાફિક રીતે સ્થાપિત કરી શકે છે, તેમને fonts:/// ને નોટિલસમાં શોધીને, અને નવી ફોન્ટ ફાઈલને અંહિ ખેંચીને.

નોંધ: જો ફોન્ટ ફાઈલ નામ ".gz" થી અંત થાય, તો તે gzip સાથે સંકોચાયેલ છે, અને તેનું (gunzip આદેશ સાથે) સંકોચન દૂર થવું જોઈએ fontconfig ફોન્ટ ઉપસિસ્ટમ તે ફોન્ટ વાપરી શકે તે પહેલાં.

fontconfig/Xft પર આધારિત નવી ફોન્ટ સિસ્ટમોના પરિવહનને કારણે, 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 આદેશોને જો યોગ્ય હોય તો વાપરી રહ્યા હોય તો. LVM1 આદેશો ".lvm1" સાથે અંત લાવીને નામ બદલાય છે (ઉદાહરણ તરીકે, /sbin/vgchange.lvm1 -ay).

nscd નામ સેવા કેશ ડિમન હવે જરૂરી કેશને રીસ્ટાર્ટ અથવા સિસ્ટમ રીબુટ વિરુદ્ધ જાળવણી કરશે. દરેક ડેટાબેઝ (વપરાશકર્તા, જૂથ, અને યજમાન, સંબંધિત રીતે) યોગ્ય બનવા માટે પસંદ કરી શકાશે /etc/nscd.conf માં "yes" સુયોજિત કરીને. પ્રવેશો કેશમાંથી દૂર કરાતા નથી જ્યાં સુધી તેઓ લાંબા સમય સુધી રસની બાબત સાબિત થશે નહિં. બધા પ્રવેશો કે જેઓની છોડવાના સમયની મર્યાદા પૂરી થઈ પરંતુ તેઓ આપોઆપ રસપ્રદ બને નહિં ત્યાં સુધી, કે જે અમુક પરિસ્થિતિમાં મદદ કરે કે જ્યાં ડિરેક્ટરી અને નામ સેવાઓ કામચલાઈ રીતે ઉપ્લબ્ધ નહિં બને.

મૂળભુત SELinux સુરક્ષા રૂપરેખાંકન હેઠળ, આ ડિમન એ લક્ષ્યાંક નીતિ દ્વારા આવરી લેવાય છે. આ ખાસ કરીને સિસ્ટમ ઓબ્જેક્ટોને પરવાનગી આપીને અથવા રદ કરીને સુરક્ષા વધારી શકે છે કે જે સામાન્ય રીતે ડિમન વાપરે છે. તેમછતાં પણ, તેની પાસે પહેલા કામ આપતાં રૂપરેખાંકનોને લાંબા સમય સુધી તેનું વિધેય નહિં કરવા દેવા માટેનું કારણ છે, તેથી તમારુ રૂપરેખાંકન બંને સુરક્ષિત અને વિધેયાત્મક છે તેની ખાતરી કરવા માટે કેવી રીતે SELinux કામ કરે તે શીખવું જ જોઈએ.

SELinux નીતિ વિશે વધુ જાણકારી માટે, Red Hat SELinux નીતિ માર્ગદર્શન અંહિ http://www.redhat.com/docs સંદર્ભ લો.