Patch Management in Linux and Solaris

Jason Hotra
November 15, 200
1.Abstract.............................................................................................................................3
2.Introduction.......................................................................................................................3
2.1Security.......................................................................................................................3
2.2Functionality...............................................................................................................4
2.3Performance................................................................................................................4
2.4Who Distributes Patches.............................................................................................4
3.Patch Manaement............................................................................................................4
3.1Disco!ery" Findin the #atest Patches........................................................................$
3.1.1Solaris..................................................................................................................$
3.1.2%ed &at................................................................................................................$
2.3Determination" Determinin Which Patches to Install...............................................'
3.1.3Solaris..................................................................................................................'
3.1.4%ed &at (et)or*.................................................................................................+
3.2Installation" Installin the Patches..............................................................................,
3.2.1Solaris..................................................................................................................,
3.2.2%ed &at................................................................................................................,
4.Patch Manaement Strateies...........................................................................................-
4.1.1Solaris Patch Manaement Stratey....................................................................-
4.1.1.1Automated Patch Manaement...................................................................1.
4.1.2%ed &at Patch Manaement Strateies..............................................................1.
4.1.2.1Automated Patch Manaement...................................................................11
$.%eferences.......................................................................................................................11
2
1! "bstract
A necessary /rocedure for system administrators is )hen and ho) to u/date the
/roduction en!ironment in use at a com/any. 0ne of the most routine tas*s that fit into
this cateory is /atch manaement of the o/eratin system. 1his re/ort )as )ritten to
/ro!ide a detailed bac*round of )hat /atch manaement is and some common strateies
to handle this /rocess. It )ill focus on Solaris and %ed &at #inu2 3 t)o of the most
/o/ular 4(I5 o/eratin systems in use today.
1his re/ort )ill bein )ith a brief introduction to /atch manaement6 includin an
e2/lanation of )hat a /atch is. Follo)in this )ill be se!eral /roducts a!ailable from
both Sun Microsystems and %ed &at6 the !endors of the o/eratin systems6 and locations
of )here to find the tools online. With a solid bac*round of *no)lede of /atch
manaement and a!ailable tools6 the document is concluded )ith strateies for actually
manain /atches.
2! #ntroduction
A /atch is a collection of fi2es to a /roblem. 1he /roblem can already be )ell *no)n or
be a /otential roadbloc* do)n the road. In addition to *no)n /roblems6 /atches can also
/ro!ide added functionality to e2istin soft)are. Patches usually fi2 /roblems in one of
the follo)in cateories"
Security
Functionality
Performance
1he boundaries bet)een each cateory are sometimes !aue6 and /atches can be
im/lemented to handle any number of /roblems in one fi2.
2!1 Securit$
Security /atches attem/t to correct bus that /ro!ide access to the system that )ere not
*no)n about durin the latest release. 7!ildoers en8oy findin these bus and e2/loitin
them in a malicious6 sometimes comical6 manner that )ill usually ha!e a neati!e effect
on the system as a )hole. 9iruses6 )orms6 and 1ro8an horses are e2am/les of /rorams
used to ta*e ad!antae of this illeal access. (o system is com/letely safe from un)anted
attac*s.
0ne such bu that )as a ma8or concern a fe) years ao :1--+; )as )ith the rlogin
/roram. It )as /ossible for a user to ain su/er user access to a taret machine /rior to a
/atch bein released that fi2ed this /roblem.
3
2!2 %unctionalit$
Functionality /atches attem/t to correct functional errors6 such as data interity and
reliability. 1hey /ro!ide fi2es to /roblems in a /roram that may result in une2/lained
failure or corru/tion of data.
In addition to data /roblems6 /rorams are sometimes found to ha!e une2/ected
beha!iors. 1his ty/e of /roblem occurs )hen a feature is abused or misunderstood6 or a
standard )as not adhered to )hen a /roram )as created. 0n the other hand6 the
a//lication crontab uses 3r to remo!e the cron file. 1his miht be determined to be a
/roblem in the future6 and a /atch )ould be im/lemented to chane this.
2!& Per'ormance
Performance /atches attem/t to correct issues that cause unnecessary delays to the end
user. 1hese delays can be seen in /rorams runnin unnecessarily lon6 bloc*in system
de!ices :memory6 <P4 time6 etc.;6 or sluish res/onse to user in/ut. 7!en the most )ell
desined /roram can sometimes ta*e u/ an e2cessi!e amount of system resources )hile
runnin.
A common form of /erformance errors occur )hen an a//lication does not clean itself u/
/ro/erly. For e2am/le6 a /rocess that for*s off se!eral children6 but doesn=t *ill them
/ro/erly can cause >ombie /rocesses. Another common /roblem is )hen an a//lication
does not manae its lo files correctly6 /otentially fillin u/ a!ailable s/ace on a hard
dri!e.
2! (ho )istributes Patches
Patches can be associated )ith o/eratin systems or any third /arty a//lication. Sun and
%ed &at mostly concern themsel!es )ith the *ernel6 the core /roram of an o/eratin
system. At times6 it is necessary to u/date other /rorams that reside on a i!en /latform
alon )ith the o/eratin system.
Most /rorams or a//lications /ro!ided )ith the %ed &at or Solaris distribution )ill be
maintained throuh /atches from their res/ecti!e !endor. Sometimes the !endor decides
to sto/ su//ortin an a//lication6 or other a//lications ha!e nothin to do )ith the
o/eratin system. Part of /atch manaement is to deal )ith the !endors of a//lications
that are not bein su//orted by Sun or %ed &at.
Most !endors )ho /roduce soft)are routinely /ro!ide ne)er !ersions of their /rorams.
1here is little in the )ay of standardi>ation )hen it comes to release schedules of these
a//lications6 but it is im/ortant to reali>e that all soft)are /rorams need to be
maintained. 7ach !endor of an a//lication needs to be contacted se/arately.
&! Patch Management
Patch manaement is the /rocess of determinin )hether a system has the most
a//ro/riate soft)are installed. Patch Manaement is a three?ste/ /rocess"
Disco!ery
4
Determination
Installation
7ach of the sub sections describes a ste/ in detail. It includes a short descri/tion of the
a!ailable tools for both Solaris and %ed &at.
&!1 )iscover$* %inding the Latest Patches
1he first ste/ re@uired for /atch manaement is to find out )hat /atches are currently
a!ailable. 1his information can be found from se!eral online sources. Aoth Solaris and
%ed &at ha!e se!eral o/tions to inform interested /arties in rele!ant /atches. Findin
/atch information is usually less difficult than filterin throuh all the /atches for
/ertinent fi2es.
3.1.1 Solaris
Solaris /ro!ides a mailin list to recei!e a )ee*ly notification of ne) and u/dated
/atches6 freely a!ailable at htt/"BB))).sun.comBne)sletters. 1heir )ebsite offers se!eral
/laces to find information reardin their /atches6 as )ell as se!eral to/ic?s/ecific
forums. 1he Solaris Patch Manaer 1ool6 a full?featured /atch manaement tool6 also
/ro!ides details reardin /atches. Another tool6 Sun Patch <hec*6 can be run to obtain a
listin of a!ailable /atches6 but /ro!ides little dianostic ca/abilities.
3.1.2 Red Hat
%ed &at /ro!ides a com/rehensi!e /atch manaement system throuh t)o tools" the %ed
&at (et)or* :C%&(D; and the %PM Pac*ae Manaer :C%PMDE another insatiable F(4
/un;. %&( is a com/any?maintained )eb site located at htt/"BBrhn.redhat.com that
/ro!ides the latest information about /atches. %PM is installed by default on all current
!ersions of %ed &at. If not currently a!ailable on the system6 it can be obtained from the
F1P site maintained by %ed &at6 ft/"BBft/.redhat.com.
1he %ed &at (et)or* re@uires the /urchase of a license to fully utili>e it6 unless the
system bein manaed is for /ersonal use. In the latter case6 a !ery basic utility is
a!ailable for one system only. 1his online resource /ro!ides e2tensi!e information about
e2istin /atches6 and can be confiured to monitor any taret system. %&( /ro!ides both
free and custom ser!ices based on the user le!el.
An additional facility related to %&( is the %&( Alert (otification 1ool6 a Ga!a?based
/roram that resides on the taret system. 1his tool can be confiured to routinely chec*
for u/dates from the %&( and notify you of /atches to install. 1he Alert (otification
1ool resides on the taret system=s des*to/. When a ne) u/date is a!ailable6 it notifies
the administrator throuh a chane in its icon. 4nfortunately6 the tool does not a//ear to
ha!e a mail facility6 )hich )ould not re@uire the administrator to be loed into the
system.
%PM /ro!ides a similar functionality from the taret system. It does not /ro!ide detailed
information about each /atch li*e %&( does6 but it does /ro!ide a list of a!ailable
$
/atches throuh a relati!ely friendly user interface. Aoth %PM and %&( are the buildin
bloc*s for the %ed &at 4/date Aent6 described in detail later.
%PM can be used !ia the command line rpm6 )hich in!o*es a sub?shell on #inu2.
2!& )etermination* )etermining (hich Patches to #nstall
1he ne2t ste/ in the /atch manaement /rocess is to determine )hich /atches are
necessary to install. 1he !endor attem/ts to sim/lify this tas* by rou/in /atches by
their relati!e im/ortance. <ritical /atches should al)ays be installed. %outine6 non?
critical /atches are left to the 8udment of the administrator. 1he administrator should be
able to find enouh information from one of the sources mentioned abo!e to determine its
im/ortance.
Most com/anies ha!e their o)n /olicies concernin the installation of ne) soft)are.
Patch manaement tends to fall under one of these umbrella /olicies6 )hich ma*es
determinin )hat is necessary and )hat isn=t all the more difficult. Any /olicy that does
not ad!ise automatic or routine u/radin usually affects this ste/ drastically. (o matter
)hat the /olicy6 it is )ise to ha!e a test system to !erify chanes )or* /rior to releasin
to a /roduction en!ironment.
Aefore it can be decided )hich /atches to install6 it is necessary to find out )hich /atches
are not installed on the /resent machine6 accordin to the !endor. 1his is done by
com/arin the a!ailable list of /atches from a !endor aainst the e2istin /atches on a
system. Solaris and %ed &at /ro!ide se!eral tools to accom/lish this tas*.
3.1.3 Solaris
Sun /ro!ides a be!y of tools to aid in the automation of /atch manaement6 includin the
Solaris Patch Manaer 1ool6 Sun Patch <hec*6 PatchDia6 Sun Manaement <enter6
Solaris #i!e 4/rade6 and Solaris Flash 1echnoloy. All of these tools ha!e a free
!ersion. Due to the )ide !ariety of tools6 a brief descri/tion of each )ill only be
/ro!ided6 alon )ith a lin* of )here to find additional information.
1he Solaris Patch Manaer 1ool is a!ailable at htt/"BB))).sun.comBsunsol!eB/atches.
1he Patch Manaer 1ool /ro!ides functionality that )ill allo) the administrator to
do)nload and install s/ecific /atches. 1he Patch Manaer comes in a free command line
inter/reter :C<#ID; !ersion6 and a more robust ra/hical user interface :CF4ID; !ersion
called PatchPro. All !ersions of Solaris from !ersion - use PatchPro.
Sun Patch <hec* and PatchDia are also a!ailable at
htt/"BB))).sun.comBsunsol!eB/atches. Aoth can be used to com/are a i!en systems
confiuration )ith )hat is a!ailable from Sun. 1he main difference is that Patch <hec*
cannot s/ecify a desired confiuration to com/are aainst. Instead6 it /ro!ides a full list
of /atches a!ailable for the s/ecified o/eratin system. (either tool can be used to
do)nload or install any /atches found to be necessary.
'
1he Sun Manaement <enter :htt/"BB))).sun.comBsunmanaementcenter;6 Solaris #i!e
4/rade :htt/"BB))).sun.comBsolarisBli!eu/rade;6 and Solaris Flash 1echnoloy
:htt/"BB))).sun.comBsoft)areBsolarisB)ebstartflash; /ro!ide more functionality than 8ust
/atch manaement. All three tools are desined for handlin multi/le ser!ers and include
additional manaement facilities. 1he Sun Manaement <enter and #i!e 4/rade also
ha!e built?in rollbac* ca/abilities. 0ne additional feature of the Sun Manaement <enter
is that it can also be used for #inu2.
1he Solaris Patch Manaer6 PatchDia6 and Sun Manaement <enter tool:s; also /ro!ide
a feature to find a listin of the currently installed /atches on a system. 1his information
is useful for chec*in the end result of any automatic installation6 or for @uic*ly chec*in
if a critical /atch has been installed. All o/eratin system /atches are co/ied into the
/var/sadm/patches directory6 and the showrev p or an ls of this directory )ill
/ro!ide the same information.
3.1.4 Red Hat Network
1he %ed &at 4/date Aent6 up2date6 is the com/lete /ac*ae for /atch manaement. As
mentioned in the /re!ious section6 %ed &at /ro!ides the %&( and %PM to system
administrators for easy access to /atch information. 1he 4/date Aent oes a ste/
beyond and /ro!ides a tool to com/are the taret systems confiuration )ith the latest
/atches a!ailable.
1he 4/date Aent can be used in t)o )ays" from the taret system6 or from %&(. 0n the
taret system6 a <#I and F4I !ersion are a!ailable. %&( /ro!ides access to the same
information throuh the %ed &at (et)or* Daemon. Aoth tools /oll the taret system for
information that is com/ared )ith a base confiuration de/endin on the desired
CchannelD selected.
%ed &at has come u/ )ith the conce/t of a CchannelD to define a taret confiuration for
any machine. All u/date tools re@uire the assinment of a channel to the system bein
administered. 1here are t)o ty/es of channels" base channels and child channels. 0nly
one base channel can be assined to a system6 and multi/le children are allo)ed.
1he base channel defines the !ersion of %ed &at installed and the hard)are /latform it is
installed on. For e2am/le6 C%ed &at #inu2 +.2 i3,'D is a base channel. <hild channels are
associated )ith a base channel and /ro!ide /atches s/ecific to a s/ecial a//lication.
When run aainst a taret system6 both the 4/date Aent and %&( /ro!ide a list of
/atches that are a!ailable but not installed. %&( and the F4I !ersion of the 4/date
Aent /ro!ide a detailed e2/lanation of each /atch to let the administrator determine
their necessity. If it is determined that a /atch should not be installed6 it can be added to
an e2clude list throuh any of the tools :4/date Aent F4I or <#I and %&(;.
1he list of currently installed /atches on a system is a!ailable throuh the %&( )ebsite6
%PM and the 4/date Aent tools. 1he %ed &at (et)or* /ro!ides this information under
the desired system=s CPac*aesD tab. 1he command rpm q all )ill dis/lay all /atches
+
and !ersions. 1he 4/date Aent /ro!ides a System Profile that contains this same
information.
&!2 #nstallation* #nstalling the Patches
1he final ste/ in the /atch manaement /rocess is to install the desired /atches onto the
system. 1his is one of the fe) cases )here the clichH Clast but not leastD does not fit6 as
this is by far the sim/lest ste/ on both Solaris and %ed &at. Far more time )ill be s/ent
findin )hich /atches to install than actually installin them on a system 3 unless the
system has ne!er been u/dated.
1he automated tools sim/lify the installation /rocess reatly. If manual installation is
necessary6 the user is res/onsible for determinin the /atch de/endencies and remo!al of
e2istin /atches on a taret system. Aoth %ed &at and Solaris incor/orate these concerns
into their tools. 1he follo)in ste/s /ro!ide a frame)or* for manual installation"
Determine any de/endencies re@uired by the /atch
Do)nload the /atch and its de/endencies from the online resources
%emo!e all /atches affected by this /atch and its de/endencies
Install the de/endent /atches
Install the /atch
1he de/endency rule abo!e can ma*e )hat is a rather sim/le /rocess become !ery
com/le2. 7ach /atch that is to be installed6 includin /atch de/endencies re@uirin
installation of additional /atches6 has to ha!e this ste/ chec*ed. Due to this6 it is
recommended that one of the !endor?su//lied tools be used to manae /atches.
3.2.1 Solaris
Se!eral of the Solaris tools can also be used to install /atches once it is determined )hich
need to be installed. 1he Solaris Patch Manaer6 Sun Manaement <enter6 Solaris #i!e
4/rade6 and Solaris Flash technoloy all /ro!ide this feature. %efer to indi!idual tool
documentation for an e2/lanation of ho).
3.2.2 Red Hat
1he %PM becomes !ery im/ortant in this ste/ of /atch manaement for %ed &at. It is the
bac*bone to the %ed &at 4/date Aent and %&( Alert (otification tools. When a /atch
is determined necessary6 %PM or the 4/date Aent can be used to do)nload it. Aoth
tools ha!e a command line !ersion6 and there a//ears to be little to no difference in the
end result of either. 1he main reason for usin the 4/date Aent is that it can be run from
a F4I6 and confiured much easier.
1he 4/date Aent allo)s for the do)nload and installation in an all?in?one /rocess. It
also allo)s the e2clusion of /atches that are *no)n to be unnecessary. Due to this6 it is
/robably the /referred method to the system administrator )ho )ishes to ma*e their life
easier. 1he 4/date Aent has a )i>ard?li*e interface to uide the user throuh tine
installation /rocess.
,
1he %&( Alert (otification 1ool also /ro!ides a similar interface to the 4/date Aent
for installin /atches. It also runs throuh %PM to do)nload and install /atches.
0ne final o/tion for installin /atches is to use the %ed &at (et)or*. Any reistered
system can be manaed throuh the )ebsite. If a system is not reistered6 /atches can
still be obtained and installed manually.
When a /atch is found to install on a reistered system throuh %&(6 it can be scheduled
for installation. 0nce a /atch is scheduled6 it )ill e!entually be recei!ed from the %ed
&at (et)or* Daemon that is runnin on the taret system automatically. Success or
failure )ill be recorded on the )ebsite.
! Patch Management Strategies
1here are se!eral strateies for handlin /atch manaement6 some of )hich ha!e been
alluded to in /re!ious sections. 1his section )ill focus on the recommended strateies
/ro/osed by Sun Microsystems and %ed &at.
4.1.1 Solaris Patch Management Strategy
Sun recommends that the administrator *ee/ their system runnin the latest !ersion of the
o/eratin system at all times. Aut6 they reali>e this is not al)ays feasible. 1herefore6 they
ha!e a second recommendation that a system administrator maintain the latest !ersion of
installed soft)are in a three?tiered /atch manaement stratey"
Install Solaris 4/dates or Maintenance 4/dates as soon as /ossible.
Install Sun Alert Patches as soon they are released.
Install /atches as necessary to address /roblems encountered bet)een
Solaris 4/dates or Maintenance 4/dates.
Solaris 4/dates and Maintenance 4/dates are released /eriodically for the latest !ersion
of Solaris a!ailable. 0nce a ne) !ersion of the o/eratin system is released6 no ne)
u/dates of this form )ill be created for older !ersions. Aoth u/dates include all of the
latest /atches needed to brin the runnin !ersion of Solaris u/ to date. 1here a//ears to
be little difference bet)een Solaris and Maintenance 4/dates6 )ith the e2ce/tion of
/ro!isionin.
Whene!er a ma8or issue arises from hard)are or soft)are?related /roblems6 Sun releases
an Alert Patch to fi2 it. 1hese are considered to be hih /riority6 and made a!ailable as
@uic*ly as /ossible after the /roblem is found. Due to their s/oradic nature6 Sun ad!ises
you reularly chec* for these /atches throuh one of the means mentioned in this re/ort.
A detailed e2/lanation of the /roblem comes alon )ith the Alert Patch. 1his information
should be used to determine if a /atch is necessary for the taret system6 based on the
situation that causes the /roblem to ha//en. (ot all Alert Patches are necessary to be
installed6 but Sun has another cateory of /atches that describe issues that they do not
consider to be alert. 1he safest stratey is to al)ays install Alert Patches once they are
released.
-
0utside of the reular maintenance u/dates and s/ecific alerts6 additional /atches )ill be
/ro!ided )hen Solaris issues are addressed by Sun. 1hese /atches are of a lo) /riority
nature6 tendin to correct /roblems )ith usability or desired enhancements to some
as/ect of the o/eratin system. Gust li*e Alert Patches6 these /atches come )ith a detailed
e2/lanation of )hat they intend to fi26 and it is left to the discretion of the administrator
for a i!en system to determine their im/ortance.
Sun oes one ste/ beyond /atch definition and describes a !ery con!enient methodoloy
of /atch release that is also )orth mentionin. 1hey ad!ise a t)o or three ste/
en!ironment release /rocess. 0nce all /atches for a i!en installation are *no)n6 it is
safest to ha!e a test en!ironment to install these /atches on to ensure that they do not
accidentally brea* the system or any a//lications runnin on it. 0nly after it is certain
that the /atch bundle )ill not brea* the system do they recommend releasin the fi2es to
a /roduction en!ironment.
1his method is !ery safe6 and hihly useful to im/lement. Aut6 it is costly6 and re@uires a
homoenous en!ironment to )or* /ro/erly. 1he t)o?ste/ /rocess in!ol!es a test and
de!elo/ment system that has the same hard)are and soft)are confiuration as the
/roduction :taret; system. 1he three?ste/ /rocess oes one ste/ further and adds a third
system that se/arates system?s/ecific testin from the de!elo/ment en!ironment.
4.1.1.1 Automated Patch Management
Any one of the <#I tools mentioned for Solaris )ill /ro!ide an easy /rocess to automate
/atch manaement. 1he Solaris Patch Manaer 1ool /ro!ides all the necessary features
in one a//lication. Sun Patch <hec* and PatchDia can be used to find /atches to install6
but installation )ould ha!e to be done manually.
1he use of a database )ould be ad!isable in the automation /rocess6 as none of the <#I
tools /ro!ide re!ision control. With the addition of the Solaris Flash 1echnoloy6 a
sna/shot of the system could be stored6 reducin considerably the architecture re@uired to
accom/lish this tas*.
(o automation /rocess )ill be able to determine if a /atch is necessary to install. If the
only re@uirement for /atch manaement is that an o/eratin system be runnin )ith the
latest /atches a!ailable6 automation is /ossible. If there is e!er any doubt as to the nature
of a !endor /atch bein re@uired6 the administrator )ill ha!e to determine that /rior to
installation.
4.1.2 Red Hat Patch Management Strategies
1he %ed &at (et)or* is an in!aluable resource for findin errata on !arious /atches. It is
recommended that administrators set u/ an %&( Alert (otification 1ool to routinely
chec* for system u/dates. If the Alert (otification 1ool is una!ailable :due to absence of
an 5?Windo) or any other reason;6 it is ad!isable to lo into the %ed &at (et)or*
reularly to !ie) system status. 0nce a system is reistered6 this is a !ery @uic* /rocess.
1.
When ne) /atches are found6 se!eral of the abo!e tools :%&(6 %&( Alert (otification
1ool6 %ed &at 4/date Aent; can be used to find a descri/tion of it. If it is determined to
be necessary6 the /atch can be scheduled :%&(; or do)nloaded :%&(6 Alert (otification
1ool6 4/date Aent6 %PM; to the system and installed.
4.1.2.1 Automated Patch Management
1o com/letely automate the %ed &at /rocess6 the %ed &at 4/date Aent has a command
line tool6 up2date6 to handle this. 1his /roram is an installable /ac*ae usin %PM6 if it
)as not /art of the custom installation made on a system.
1he up2date tool can be used to @uery e2istin /ac*aes6 find ne) /ac*aes6 do)nload
it6 and install it in se/arate actions. With a little inenuity and a database6 confiuration
manaement is a !ery accom/lishable tas*.
1he %ed &at tool set /ro!ides the same limitations as Sun has for Solaris. It is still the
res/onsibility of the administrator to determine if a non?critical /atch is necessary to
install. 1he safest stratey is to al)ays install /atches throuh one of the tools /ro!ided6
as they tend to handle conflicts automatically.
5! +e'erences
1. Solaris Patch Manaement" %ecommended Strateies
Ihtt/"BB))).sun.comBser!iceBsu//ortBsoft)areB/atchmanaementB/mstrateies1..
.2./dfJ
2. %ed &at (et)or* 3.$" 4/date %eference Fuide Ihtt/s"BBrhnBredhatBcomBhel/Brhn?
u/date?ur?en./dfJ
3. %PM &o)?1o Ihtt/"BB))).r/m.orB%PM?&0W10BJ
4. %ed &at (et)or* 1our Ihtt/"BB))).redhat.comBsoft)areBrhnBtourBJ
$. Solaris Patch Manaer
Ihtt/"BB))).sun.comBser!iceBsu//ortBsoft)areB/atchmanaementB/atchmanaer.h
tmlJ
11