RedHatEnterpriseLinux4 ApplicationCompatibility

ByDonaldFischer

Abstract
TheRedHatEnterpriseLinuxproductfamilyprovidesa powerful,stableplatformforthirdpartysoftwareapplication developers.Thisdocumentdescribesthedifferenttypesof compatibilityguaranteesthatareavailabletoapplication developersbuildingsoftwareforRedHatEnterpriseLinux ononeormorehardwarearchitectures.Italsoprovides guidancetodevelopersonbestpracticesthatshouldbe followedinordertoensureapplicationcompatibilitywith futurereleasesofRedHatEnterpriseLinux.Finally,it summarizesthecompatibilitypoliciesfollowedbyRedHat withinandbetweenmajorreleasesoftheRedHat EnterpriseLinuxplatform.

February2005

Copyright2005RedHat,Inc.Allrightsreserved.RedHatandtheShadowmanlogoareregisteredtrademarksofRedHat,Inc.intheUSandothercountries.Linuxisa registeredtrademarkofLinusTorvalds.Allothertrademarksreferencedhereinarethetrademarksoftheirrespectiveowners.WHP73870US02/05

TableofContents

TypesofCompatibility...3 ApplicationCompatibility...3 SourceApplicationCompatibility...3 BinaryApplicationCompatibility...5 HardwareArchitectureCompatibility...6 SingleArchitecturePlatforms...6 MultipleArchitecturePlatforms...6 ConfigurationandDataFileCompatibility..8 ConfigurationFiles...8 DataFiles....8 DesigningSoftwareforCompatibility...10 UseofSystemLibraries...10 CoreLibraries....10 NonCoreLibraries....10 Packaging....11 TheFileHierarchyStandard..11 SecurityEnhancedLinux....11 RedHatEnterpriseLinuxCompatibilityPolicies..11 CompatibilityWithinAMajorRelease...11 CompatibilityBetweenMajorReleases..12
RedHatEnterpriseLinux4ApplicationCompatibility

TypesofCompatibility

TherearemultipleaspectsofcompatibilityforRedHatEnterpriseLinux:
ApplicationCompatibility:indicateswhetherapplicationswillcompileand runacrossdifferentinstancesoftheoperatingenvironment,including updatedversionsandnewreleases,onaparticularhardwarearchitecture. ConfigurationandDataFileCompatibility:whichindicateswhether configurationfilesanddatafilescanbeusedamongdifferentreleasesof theoperatingenvironment.

ApplicationCompatibility

Applicationcompatibilityspecifiestheportabilityofapplicationsourcecode andcompiledapplicationbinariesacrossdifferentinstancesofacomputer operatingenvironment. Applicationcompatibilitycanbebrokendownintotwobroadcategories:
SourceApplicationCompatibility,whichspecifieswhetherapplication sourcecodewillcompileandexecutecorrectlyacrossdifferentinstancesof theoperatingenvironment.Sourcecompatibilityisdefinedbyconformance withspecifiedApplicationProgrammingInterfaces(APIs). BinaryApplicationCompatibility,whichspecifieswhethercompiled applicationbinaryexecutablesandDynamicSharedObjects(DSOs)will runcorrectlyacrossdifferentinstancesoftheoperatingenvironment. BinarycompatibilityisdefinedbyconformancewithspecifiedApplication BinaryInterfaces(ABIs).
RedHat's definitionofsourcecompatibilityAPIsandbinarycompatibilityABIs issuchthatthereisacontractbetweentheapplicationandRedHat EnterpriseLinuxoperatingenvironment.Thedifferencebetweensource compatibilityAPIsandbinarycompatibilityABIsiswherethecontractis enforcedatcompiletimeorruntime. SourceApplicationCompatibility Sourcecompatibilityenablesabodyofapplicationsourcecodetobe compiledandoperatecorrectlyonmultipleinstancesofanoperating environment,acrossoneormorehardwarearchitectures,aslongasthe sourcecodeiscompiledindividuallyforeachspecifichardwarearchitecture. (Notethatsomeplatformssupportmorethanonehardwarearchitecture,as discussedlaterinsectionMultipleArchitecturePlatforms). SourcecompatibilityisdefinedbyanApplicationProgrammingInterface(API), whichisasetofprogramminginterfacesanddatastructureswhichare providedtoapplicationdevelopers.ForClikelanguages,theprogramming syntaxofAPIsaredefinedinheaderfilesthatspecifydatatypesand programmaticfunctionsimplementedbytheoperatingsystemorlibrariesand madeavailabletoprogrammersforuseintheirapplications.Thesyntaxof APIsareenforcedatcompiletime,orwhentheapplicationsourcecodeis compiledtoproduceexecutablebinaryobjectcode. SourcecompatibilityAPIsareclassifiedas:

Defactostandardsnotformallyspecifiedbutimpliedbyaparticular implementation Dejurestandardsformallyspecifiedinstandardsdocumentation
RedHatEnterpriseLinuxprovidesbackwardscompatibilitywithdefacto standardsforcoresystemcomponentswhereverpossible.Thismeansthat anapplicationbuiltononemajorreleaseofRedHatEnterpriseLinuxwill continuetoworkthroughouttheproductlifecycleonsubsequentupdatesof thatmajorreleaseandonthenextmajorreleaseofRedHatEnterpriseLinux aswell.Forexample,applicationsthatarearecompiledwithheaderfilesand linkedtoaparticularversionofglibc,theGNUCLibrary,areintendedto continuetoworkwithlaterversionsofglibc.Forthecaseofglibc,thisis accomplishedbyprovidingversionedsymbols,whosesyntaxandsemantics arepreservedinsubsequentreleasesofthelibraryevenifanew,otherwise incompatibleimplementationisadded.Forothercoresystemcomponents, suchasall2.xreleasesoftheGTK+toolkit,backwardscompatibilityis ensuredsimplybylimitingchanges,whichpreservethesyntaxandsemantics ofthedefinedAPIs.Inmanycases,multipleversionsofaparticularlibrary maybeinstalledonasinglesystematthesametimetosupportdifferent versionsofanAPI.AnexampleistheinclusionofbothBerkeleyDatabase (db)version4.2.52andversion4.1.25inRedHatEnterpriseLinux4,each withitsownsetofheadersandlibraries. Inallcases,applicationdevelopersshouldseektoensurethatanybehavior theydependonisdescribedinformalAPIdocumentation,soastoavoid introducingdependenciesonunspecifiedimplementationspecificsemanticsor evenintroducingdependenciesonbugsinaparticularimplementationofan API.Forexample,newreleasesoftheGNUClibraryarenotguaranteedto becompatiblewitholderreleasesiftheoldbehaviorviolatedaspecification. RedHatEnterpriseLinuxbyandlargeseekstoimplementsource compatibilitywithavarietyofdejureindustrystandardsdevelopedforUnix operatingenvironments.WhileRedHatEnterpriseLinuxdoesnotfully conformtoallaspectsofthesestandards,thestandardsdocumentsdo provideadefinedsetofinterfaces,andmanycomponentsofRedHat EnterpriseLinuxtrackcompliancewiththem(particularlyglibc,theGNUC Library,andgcc,theGNUC/C++/Java/FortranCompiler).Thereareandwill becertainaspectsofthestandardswhicharenotimplementedasrequiredon Linux. AkeysetofstandardsthatRedHatseekstoconformwitharethosedefined bytheAustinCommonStandardsRevisionGroup(TheAustinGroup). TheAustinGroupisaworkinggroupformedin1998withtheaimofunifying earlierUnixstandardizationeffortsincludingISO/IEC99451and99452, IEEEStandards1003.1and1003.2(POSIX),andTheOpenGroup's Single UnixSpecification.ThegoalofTheAustinGroupistounifythePOSIX,ISO, andSUSstandardsintoasinglesetofconsistentstandards.TheAustin GroupincludesmembersfromTheOpenGroup,ISO,IEEE,majorUnix vendors,andtheopensourcecommunity. ThecombinedstandardsissuedbyTheAustinGroupcarryboththeIEEE POSIXdesignationandTheOpenGroup's TechnicalStandarddesignation, andinthefuturetheISO/IECdesignation.

RedHatEnterpriseLinux4ApplicationCompatibility 4
MoreinformationonTheAustinGroupisavailableat http://www.opengroup.com/austin. BinaryApplicationCompatibility Binarycompatibilityenablesasinglecompiledapplicationbinarytooperate correctlyonmultipleinstancesofanoperatingenvironmentthatsharea commonhardwarearchitecture(whetherthatarchitecturesupportis implementedinnativehardwareoravirtualizationlayer). BinarycompatibilityisdefinedbyanApplicationBinaryInterface(ABI).The ABIisasetofruntimeconventionsadheredtobyalltoolswhichdealwitha compiledbinaryrepresentationofaprogram.Examplesofsuchtoolsinclude compilers,linkers,runtimelibraries,andtheoperatingsystemitself.TheABI includesnotonlythebinaryfileformats,butalsothesemanticsoflibrary functionswhichareusedbyapplications. Similartothecaseofsourcecompatibility,binarycompatibilityABIscanbe classifiedintothefollowing:
Defactostandards,whicharenotformallyspecifiedbutimpliedbya particularimplementation. Dejurestandards,whichareformallyspecifiedinstandards documentation.
ApplicationBinaryInterfacesspecifiedbytheGNUC,C++,FortanandJava Compilerincludethefollowing:
Callingconventions,whichspecifyhowargumentsarepassedtofunctions andhowresultsarereturnedfromfunctions. Registerusageconventions,whichspecifyhowprocessorregistersare allocatedandused. Objectfileformats,whichspecifytherepresentationofbinaryobjectcode. Size,layout,andalignmentofdatatypes,whichspecifieshowdataislaid outinmemory. Interfacesprovidedbytheruntimeenvironment,whichmustbeavailable usingthesamenameatalltimesandwherethedocumentedsemanticsdo notchangefromoneversiontoanother
Inaddition,theApplicationBinaryInterfacefortheGNUC++Compiler specifiesthebinaryinterfacesforthefollowingC++languagefeatures:
Namemangling Exceptionhandling Invokingconstructorsanddestructors Layout,alignment,andpaddingofclasses Layoutandalignmentofvirtualtables
ThedefaultsystemCcompilerincludedwithRedHatEnterpriseLinux4is derivedfromGCC3.4andislargelycompatiblewiththeC99ABIstandard. DeviationsfromtheC99standardinGCC3.4aretrackedonlineat: http://gcc.gnu.org/gcc3.4/c99status.html
RedHatEnterpriseLinux4ApplicationCompatibility 5
ThedefaultsystemC++compilerincludedwithRedHatEnterpriseLinux4is derivedfromG++3.4andconformstoaC++ABIdefinitionwhichisavailable onlineat:http://www.codesourcery.com/cxxabi/ MoreinformationontheABIsimplementedbythestandardRedHat EnterpriseLinuxCandC++compilersisavailableinthemanualRedHat EnterpriseLinux:UsingtheGNUCompilerCollection(GCC),whichis availableonlineat: http://www.redhat.com/docs/manuals/enterprise/RHEL3 Manual/gcc/compatibility.html
HardwareArchitectureCompatibility
SingleArchitecturePlatforms Forapplicationsthatconformtospecifiedinterfaces,binary(ABI)compatibility isprovidedforallapplicationswithinasinglehardwarearchitecture.This meansthatapplicationdevelopersdonotneedtomodifysoftwaretorunon systemsfromdifferentvendors,orwithdifferenthardwareconfigurations,as longastheyshareacommonhardwarearchitectureandthesoftwaredoesnot unconditionallyusefunctionalityofthearchitecturewhichisnotuniversally available(suchasspecialinstructionswhichareavailableononlysome processormodels). Forexample,applicationscompiledforRedHatEnterpriseLinuxfortheIBM iSeriesandpSeriesbrandedsystemsaresupportedonIBMPOWERbranded systemswithPOWER5processorsbecausetheysharethesamehardware architecture(ppc/ppc64). Similarly,applicationscompiledforRedHatEnterpriseLinuxfortheAMD64 architecturearesupportedonIntelEM64Tsystemsandviceversabecause theysharethesamehardwarearchitecture(x8664). Conversely,applicationbinariescompiledforonehardwarearchitecture typicallywillnotrunonotherhardwarearchitectures.Forexample,an applicationbinarycompiledfortheIntelItanium2architecturewillnotrunonan IBMPOWERsystem.TheexceptiontothisruleisthatRedHatEnterprise Linuxofferssupportforacompatibilityruntimeenvironmentonsomehardware architecturesasdiscussedinthenextsection. RedHatEnterpriseLinuxsupportsabroadrangeofhardwareplatformsfrom multiplevendorsacrossseveralhardwarearchitectures.Hardwareplatforms thathavebeencertifiedtorunonRedHatEnterpriseLinuxaredescribedon theRedHatHardwareCompatibilityList(HCL),availableat http://hardware.redhat.com/hcl. MultipleArchitecturePlatforms RedHatEnterpriseLinuxoffersnativesupportforabroadrangeofhardware architectures,including32bitand64bitarchitectures.Forsomeofthe supportedplatforms,bothanativehardwarearchitectureandacompatibility hardwarearchitectureruntimeenvironmentaresupported. ForeachnativearchitecturesupportedbyRedHatEnterpriseLinux,Table1 indicates:

RedHatEnterpriseLinux4ApplicationCompatibility 6
Thenativeuserspacearchitecture,orthehardwarearchitectureforwhich thenativesystemapplicationsandlibrariesarecompiled. Thecompatibilityuserspacearchitecture,ifapplicable,whichincludesa subsetofsystemapplicationsandlibrariessuppliedtoofferruntime compatibilitywithotherarchitectures.Notethatnotallsystemlibraries includedinthenativeuserspaceareincludedinthecompatibility userspace. Thekernelarchitecture,whichisthehardwarearchitectureforwhichthe kerneliscompiled.
Table1:NativeArchitectureSupport
Architecture 32bitx86 64bitAMD64 andIntel EM64T 64bitIntel Itanium2 64bitIBM POWER 31bitIBM S/390 Mainframe 64bitIBM zSeries Mainframe
Native Userspace 32bitx86 (.i386.rpm) 64bitx8664 (.x86_64.rpm) 64bitItanium2 (.ia64.rpm) 32bitPOWER (.ppc.rpm) 31bitS/390 (.s390.rpm) 64bitzSeries (.s390x.rpm)
Compatibility Userspace N/A 32bitx86 (.i386.rpm) 32bitx86 (.i386.rpm)

Kernel 32bitx86

64bitx8664

64bitItanium2

64bitPOWER 64bitPOWER (.pp64.rpm) N/A 31bitS/390 (.s390.rpm) 31bitS/390

64bitzSeries

ForthetheAMD64andIntelEM64Thardwarearchitectures,eitherthe32bit nativedistributionorthe64bitnativedistributioncantypicallybeinstalledona system.Whenthe64bitnativedistributionisinstalled,32bitapplication binariesaresupportedthroughthecompatibilityuserspace.Whenthe32bit nativedistributionisinstalled,only32bitbinariesaresupportedandnot64bit binaries. FortheIntelItanium2hardwarearchitecture,32bitx86applicationsupport requirestheuseofasoftwarepackagecalledtheIA32ExecutionLayer (IA32EL).TheIA32ELissuppliedbyRedHatasanRPMpackageonthe RedHatEnterpriseLinux4ExtrasCDandviaRedHatNetworkforthe Itanium2architectureonly. FortheIBMPOWERhardwarearchitecture,thedefaultuserspaceiscompiled forthe32bitPOWERhardwarearchitecture,andacompatibilityuserspaceis providedfor64bitnativeapplications.ThekernelfortheIBMPOWER
RedHatEnterpriseLinux4ApplicationCompatibility 7
architectureis64bitnative. InallofthecasesdepictedTable1,thecompatibilityuserspacecontainsa subsetofthesystemlibrariesandasubsetofLinuxdistributionapplicationsas comparedtothenativeuserspace.Thegoalofthecompatibilityuserspaceis toprovideabinarycompatibleapplicationruntimeenvironmentforthe specifiedarchitecture.Thecompatibilityuserspacedoesnotprovidea completeapplicationdevelopmentenvironment.Forbestresults,RedHat recommendsthatapplicationsbedevelopedandcompiledininanative hardwareenvironmentwheneverpossible,ratherthaninacompatibility environment.
ConfigurationandDataFileCompatibility
TheRedHatEnterpriseLinuxdistributioncontainsoverathousandindividual softwarepackages,whichimplementavarietyofdifferentsystemservicesand capabilities.Themajorityoftheseapplicationsaredevelopedbyactiveopen sourcedevelopercommunities,whosepoliciesandpracticesdiffer substantiallyfromonetothenext.Oneareainwhichcommunityprojectstend todifferistheircommitmenttopreservingconfigurationfileanddatafile formatsbetweenreleases. ConfigurationFiles ManyofthepackagesintheRedHatEnterpriseLinuxdistributionincludethe conceptofaconfigurationfilewhichspecifiesapplicationsettings,typicallyin anapplicationdefinedtextorbinarydataformat. Whereverpossible,RedHatseekstopreservethestabilityofconfigurationfile formatswithinamajorreleaseofRedHatEnterpriseLinux.Thismeansthat forexample,whenupdatingaparticularpackagefromRedHatEnterprise Linux4Update1toRedHatEnterpriseLinux4Update2,configurationfile customizationsmadebyauserorsystemadministratorshouldcontinueto functionasintendedwithoutmanualintervention. Thesameguaranteecannotbemadeforallpackagesforupgradesfromone majorreleasetoanother(forexample,fromRedHatEnterpriseLinux3toRed HatEnterpriseLinux4).Inthecaseofanautomatedupgradebetweenmajor releases,configurationfilesfromthepreviousreleasewilltypicallybe preserved,butmayrequiremanualadministratororuseradjustmenttowork correctlywiththeversionofthepackageinthenewermajorrelease,if configurationfileformatshavechangedforthatpackage. Applicationdevelopersareadvisedingeneralnottodependontheformatof configurationfilesusedbysystempackages,unlesstheconfigurationfilesare definedbyaspecificationandthecorrespondingupstreamcommunityproject hasexpressedacommitmenttosupportingthoseconfigurationfileformatsin allfuturereleases. DataFiles Similartothesituationwithconfigurationfiles,manypackagesintheRedHat EnterpriseLinuxdistributiondependondatafileswithaspecifictextorbinary datarepresentation.

Whereverpossible,RedHatseekstopreservethestabilityofdatafileformats withinamajorreleaseofRedHatEnterpriseLinux.Thismeansthatfor example,whenupdatingaparticularpackagefromRedHatEnterpriseLinux4 Update1toRedHatEnterpriseLinux4Update2,datafilescreatedbyearlier revisionsofpackagesshouldcontinuetofunctionasexpected. Thesameguaranteecannotbemadeforupgradesfromonemajorreleaseto another(forexample,fromRedHatEnterpriseLinux3toRedHatEnterprise Linux4).Thesupportfordatafileformatsbetweenmajorreleasesistypically dependentonthedevelopmentpoliciesoftheupstreamopensource communityproject.Forsomepackages,datafileformatswillalwaysbe maintained.Forotherpackages,acompatibilitymodeisavailableforinter operatingwitholderdatafileformats.Finally,somepackageswill automaticallyupgradedatafilesfromanoldformattoanewformat. SomespecificexamplesforupgradesfromRedHatEnterpriseLinux3toRed HatEnterpriseLinux4areasfollows:
TheEvolutionmailandgroupwareclientandtheMozillaFirefoxweb browserwillautomaticallyupgradeuserconfigurationanddatafilesfrom earlierreleasestothemostrecentformat,thefirsttimetheyarerunfor eachuser. TheOpenOffice.orgofficesuiteincludessupportforreadingandwriting datafilescreatedbyearlierreleasesoftheofficesuite. Theformatofdatafilesusedbythekernelsystemcallauditing infrastructurehaschangedbetweenRedHatEnterpriseLinux3andRed HatEnterpriseLinux4duetothemigrationtoanewauditing implementationinthekernel.Thus,auditdatafilesandanalysistoolsfrom RedHatEnterpriseLinux3arenotautomaticallyinteroperablewiththose fromRedHatEnterpriseLinux4. Theformatoffilescreatedbythekernelinthe/procfilesystemisnot guaranteedacrossreleases,unlessotherwisespecifiedbythekernel documentation.Thelocationandformatofindividualfilesinthe/proc filesystemmayhavechangedbetweenRedHatEnterpriseLinux3and RedHatEnterpriseLinux4. DatabasecontentcreatedwithearlierreleasesofPostgreSQLcanbe migratedtothenewerreleasebydumpingthecontentsofthedatabaseto atextformatandthenimportingthetextfilesintoanewerrelease.
Applicationdevelopersareadvisedingeneralnottodependontheformatof datafilesusedbysystempackages,unlessthedatafilesformatsaredefined byaspecificationandthecorrespondingupstreamcommunityprojecthas expressedacommitmenttosupportingthosedatafileformatsinallfuture releases. Ifanapplicationusesasystemlibrarytoadministerdatafiles(suchas databases),theapplicationshouldbeabletorecognizechangesinthedata formataslongasthesystemlibraryinterfacehasn' tchanged.
DesigningSoftwareforCompatibility
UseofSystemLibraries TheRedHatEnterpriseLinuxdistributioncontainsoverathousandindividual softwarepackages,manyofwhichincludelibrariesthatareavailableto developersforstaticordynamiclinkingintoapplications. RedHatrecommendsthatapplicationdevelopersavoidstaticlinking wheneverpossible.Someofthedisadvantagesofstaticlinkingincludethe following:

Bugfixesandsecurityfixesmustbeappliedmultipleplacesifcodeis duplicated. Securitymeasuressuchasloadaddressrandomizationarenotavailableto staticallylinkedlibraries. Staticallylinkedapplicationsarelessefficientusersofphysicalmemory, sincecommondynamicallylinkedcodecannotbesharedamongmultiple applicationimages. Somelibraryfunctionalityanddevelopertoolsarenotapplicableto staticallylinkedapplications.
CoreLibraries RedHatdefinesasetoflibrarieswhoseAPIsandABIswillbepreservedfor eacharchitectureacrossmajorreleasesofthedistribution.Toensure applicationruntimecompatibilityacrossmajorreleases(forexamplebetween RedHatEnterpriseLinux3andRedHatEnterpriseLinux4),application developersareencouragedtolimittheirapplicationstolinkingagainstthis limitedsetoflibraries. ForRedHatEnterpriseLinux,thecoresetoflibrariesincludes:
libc,libgcc,libstdc++,libdl,libm,libutil,libcrypt,libz,libpthread,libncurses libX11,libXext,libXt,libICE,libSM,libGL libgtk,libgdk,libgdk_pixmap,libpango,libatk,libglib,libgmodule, libgthread,libgnomeprint,libgnomeprintui,libgconf,libglade
Ifanapplicationcannotlimititselftotheinterfacesofthesecorelibraries,then toensurecompatibilityacrossmajorreleases,theapplicationshouldbundle theadditionalrequiredlibrariesaspartoftheapplicationitself.Inthatcase, thebundledlibrariesmustthemselvesuseonlytheinterfacesprovidedbythe corelibraries. NonCoreLibraries RedHatEnterpriseLinuxalsoincludesawiderangeoflibrarieswhoseAPIs andABIsarenotguaranteedtobepreservedbetweenmajorreleases. Compatibilityoftheselibrariesis,however,providedwithinamajorreleaseof thedistribution.Applicationsarefreetousethesenoncorelibraries,butto ensurecompatibilityacrossmajorreleases,applicationvendorsshouldprovide theirowncopiesofthesenoncorelibraries,whichinturnshoulddependonly onthecorelibrarieslistedintheprevioussection.
Packaging ForthebestintegrationwiththeRedHatEnterpriseLinuxdistributionand softwaremanagementtools,applicationdevelopersareencouragedto packagetheirsoftwareusingtheRPMPackageManager(RPM).RPM providesarobustsoftwarepackagingmechanismthatincludesrigorous specificationofapplicationdependencies. Forimprovedcompatibilityacrossreleases,applicationdevelopersshould followtheseguidelineswhencreatingRPMpackages:
AvoidusingRPMtriggerswheneverpossible. Don't dependontheexecutionorderofpreinstallorpreuninstallscripts, whichmaychangebetweenreleases. Explicitlystateallrequiredruntimeandbuilddependenciesusingthe appropriateRPMsyntax. Donotmodify,replace,orrecompilefilesmanagedbyRedHatprovided RPMpackages. Whenconsideringdependencies,don't assumethatallpossiblepackages willbeinstalledoneveryEnterpriseLinuxsystem.Thedefaultinstalled packagesmaychangebetweenreleases.

TheFileHierarchyStandard ApplicationsshouldfollowtheFilesystemHierarchyStandard(FHS)when installingfiles.Specifically,thirdpartysoftwareshouldinstalltoasubdirectory of/opt.MoreinformationontheFileHierarchyStandardisavailableat: http://www.pathname.com/fhs/2.2/ SecurityEnhancedLinux SecurityEnhancedLinux(SELinux)isanewcapabilityinRedHatEnterprise Linux4.SELinuxprovidesaMandatoryAccessControl(MAC)systemfor Linux,whichcanbeusedtocontrolaccesstosystemresourcesatafine grainedlevel. RedHatEnterpriseLinux4includesanSELinuxpolicyknownasthetargeted policythatrunsonlyaspecificsetofsystemservicesunderSELinux protection.Thetargetedpolicyisdesignedsothatitdoesnotimpactthe runtimebehaviorofthirdpartyapplications.Applicationdevelopersmayalso wishtoinvestigatethedevelopmentofSELinuxpoliciesfortheirapplications toensureadditionalenforcementofsecurityatapplicationruntime. MoreinformationontheSELinuximplementationinRedHatEnterpriseLinux 4isavailableat:http://fedora.redhat.com/projects/selinux/
RedHatEnterpriseLinuxCompatibilityPolicies
CompatibilityWithinAMajorRelease OneofthecoregoalsoftheRedHatEnterpriseLinuxfamilyofproductsisto provideastable,consistentruntimeenvironmentforthirdpartyapplications. Tosupportthisgoal,RedHatseekstopreserveapplicationbinary compatibility,configurationfilecompatibility,anddatafilecompatibilityforall
RedHatEnterpriseLinux4ApplicationCompatibility 11
packageupdatesissuedwithinamajorrelease. Forexample,apackageupdatefromRedHatEnterpriseLinux4Update1to RedHatEnterpriseLinuxUpdate2,orapackageupdatethatfixesan identifiedsecurityvulnerability,shouldnotbreakthefunctionalityofdeployed applicationsaslongastheyadheretostandardApplicationBinaryInterfaces (ABIs)aspreviouslydiscussed. CompatibilityBetweenMajorReleases RedHatEnterpriseLinuxalsoprovidesalevelofcompatibilityacrossmajor releases,althoughitislesscomprehensivethanthatprovidedwithinamajor release.Withthequalificationsgivenbelow,RedHatEnterpriseLinux4 providesruntimecompatibilitysupportforapplicationsbuiltforRedHat EnterpriseLinux2.1andRedHatEnterpriseLinux3. Betweenmajorreleases(forexample,betweenRedHatEnterpriseLinux3 andRedHatEnterpriseLinux4),RedHatseekstoprovidebinaryapplication compatibilityforapplicationsthatadheretopublishedstandardABIsandAPIs referencedinearliersectionsofthisdocument.Thisstatementappliesbothto nativearchitecturesupportandcompatibilityarchitecturesupport. RedHatprovidescompatibilitylibrariesforasetofcorelibraries.However, RedHatdoesnotguaranteecompatibilityacrossmajorreleasesofthe distributionfordynamicallylinkedlibrariesoutsideofthecorelibrarysetunless versionsoftheDynamicSharedObjects(DSOs)theapplicationexpectsare provided(eitheraspartoftheapplicationpackageorseparatedownloads). Toensurecompatibilityacrossmajorreleases,applicationdevelopersare encouragedtolimittheirdynamicallylinkedlibrarydependenciestothosein thecorelibraryset,ortoprovideanindependentversionoftherequirednon corelibrariespackagedwiththeirapplication(whichinturndependonlyon corelibraries).Asarule,RedHatrecommendsagainststaticallylinking librariesintoapplications. RedHatalsoreservestherighttoremoveparticularpackagesbetweenmajor releases.RedHatprovidesalistofdeprecatedpackagesthatmaybe removedinfutureversionsoftheproductintheReleaseNotesforeachmajor release.Applicationdevelopersareadvisedtoavoidusinglibrariesonthe deprecatedlist.RedHatreservestherighttoreplacespecificpackage implementationsinfuturemajorreleaseswithalternativepackagesthat implementsimilarfunctionality. RedHatdoesnotguaranteecompatibilityofconfigurationfileformatsordata fileformatsbetweenmajorreleasesofthedistribution,althoughindividual softwarepackagesmayinfactprovidefilemigrationorcompatibilitysupport. Formoreinformation,visitwww.redhat.comorcontactusat1888REDHAT1 (USandCanada)/+19197543700(international).