Date: Wed, 01 Mar 2006 22:21:44 -0800 From: Chris Maness <chris@chrismaness.com> To: Randy Pratt <bsd-unix@comcast.net> Cc: freebsd-questions@freebsd.org Subject: Re: Tracking Security in Ports and Base System Message-ID: <44068EF8.7080601@chrismaness.com> In-Reply-To: <20060301203749.bdb1b01f.bsd-unix@comcast.net> References: <43EA9782.7060708@chrismaness.com> <20060208203027.H73762@tripel.monochrome.org> <50124.67.126.165.122.1141236591.squirrel@squirrel.kq6up.org> <20060301143752.aafe3226.bsd-unix@comcast.net> <20060301142822.O90298@ns1.internetinsite.com> <20060301203749.bdb1b01f.bsd-unix@comcast.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Randy Pratt wrote: > On Wed, 1 Mar 2006 14:31:55 -0800 (PST) > Chris Maness <chris@chrismaness.com> wrote: > > >> On Wed, 1 Mar 2006, Randy Pratt wrote: >> >> >>> On Wed, 1 Mar 2006 10:09:51 -0800 (PST) >>> chris@chrismaness.com wrote: >>> >>> >>>>> On Wed, 8 Feb 2006, Chris Maness wrote: >>>>> >>>>> >>>>>> How should I set up cvsup to just track security updates for ports. And >>>>>> >>>> would the best thing to do after I synced CVS, do portupgrade -a so >>>> that everything selected gets rebuilt. >>>> >>>>> I'm not sure there is a way to do this for ports, other than manually >>>>> >>>> checking what's been changed and whether you consider that to be a >>>> security upgrade, then upgrading each applicable port by hand. As far as >>>> I understand, there is only one tag for ports ("tag=."), which gets you >>>> the "current" ports tree. I *can* guarantee that others know more about >>>> this than I do. >>>> >>> There is a port which does this for you (security/portaudit): >>> >>> portaudit provides a system to check if installed ports are >>> listed in a database of published security vulnerabilities. >>> >>> After installation it will update this security database >>> automatically and include its reports in the output of the >>> daily security run. >>> >>> >>>>>> What is the equivalent for the base system? >>>>>> >>>>> Much simpler: just track RELENG_your_release to get security updates and >>>>> >>>> bug fixes and nothing else. For example, mine is RELENG_5_4 and >>>> >>>>> therefore tracks 5.4-RELEASE. >>>>> >>> Additionally, I'd suggest subscribing to one of these mailing list so >>> that you are notified when a SA is issued: >>> >>> security-advisories@freebsd.org >>> freebsd-announce@freebsd.org >>> >>> HTH, >>> >>> Randy >>> -- >>> >>> >> Thanks, I do have port audit installed. I was refering to system >> security. The base system + FreeBSD userland. I wanted to do this >> because I did get a notice from the security list today. Do I do a make >> buildworld, to update the system? Do I do this in /usr/src ? >> > > The only thing that portaudit does is to apprise you of potential > problems. You would need to update ports (/usr/ports) to fix those > issues. I probably misunderstood your question. I'll attempt to > go into more detail. > > Just so we're talking the same language, I call anything that is > built/installed from /usr/src the 'base system'. Some people break > this down into kernel+userland. Perhaps this is the userland to > which you refer. > > I call anything built/installed from /usr/ports "third-party > applications" or the "ports tree". Some people also call this userland > applications. > > Each one is updated independent of the other. > > If you want to update the things from /usr/src (base system), refer > to the Handbook (Chapter 21 The Cutting Edge ). In particular: > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html > > It may appear complicated because of all the explanation given there > and the different branches covered but its a pretty easy process once > you work thru it. I suggest going through the document and make > yourself a crib sheet. Here's an example of how one might > look: > > cvsup -g -L 2 stable-supfile > > # READ this!! > less /usr/src/UPDATING > > #If an old backup exists (/etc.old) remove it > rm -rf /etc.old > #Make a new backup of /etc > cp -Rp /etc /etc.old > > adjkerntz -i > > cd /usr/obj > chflags -R noschg * > rm -rf * > > cd /usr/src > make buildworld > > #Check custom kernel config for changes after cvsup > #modify as needed. If using GENERIC kernel, just leave > #off the "KERNCONF=CUSTOM" part. > cd /usr/src > make buildkernel KERNCONF=CUSTOM > make installkernel KERNCONF=CUSTOM > > # need to be in single user mode at this point > # either reboot to single user mode according to the handbook > # or alternatively "shutdown now" according to the handbook > cd /usr/src > make installworld > > mergemaster > > reboot > > Please don't use the above as a substitute for reading the Handbook > in detail and applying it to your own situation. In all cases, the > Handbook takes precedence over the above. I also do not recommend > using a scripted approach until you are comfortable with the > process. > > Note that the preceeding does not update anyting that was installed > from the ports tree (/usr/ports/...). The usual tool for doing > ports updating is sysutils/portupgrade. A typical update would > be like: > > #make sure dependencies are in order before starting > #Fix any problems before starting an update. > pkgdb -F > > #update the ports tree > #Note that the ports tree uses only one tag "." > #/usr/share/examples/cvsup/ports-supfile > cvsup -g -L 2 ports-supfile > > #Read UPDATING > less /usr/ports/UPDATING > > #Backup the package database > tar-czvf /home/username/backup_dbpkg.tgz /var/db/pkg > > #Create a ports INDEX > cd /usr/ports > make index > > #Create the ports database > portsdb -u > > #Update all ports that are out-of-date > portupgrade -a > > #Clean out old ports source tarballs > portsclean -DD > > #Finally check that dependencies are still happy > pkgdb -F > > It is *so important* that you read the UPDATING files that I cannot > stress that enough. The /usr/ports/UPDATING may contain information > that may impact the process of updating ports; ie, there may be > special things that have to be done. Some of the most recent > entries are examples of that. The libtool update is a example of > a major impact. > > Normally you would only build the ports that needed updated, but > in the case of the libtool update, its probably best to use > > portupgrade -fa > > which forces *all* ports to be rebuilt. Obviously, this can take > a lot of time depending on the number of ports you have installed, > and the hardware you're using. > > At other times the ports/UPDATING may contain other specific > instructions to do before updating other ports. > > When using the UPDATING files (ports or src), they are in reverse > chronological order (newest first). Find where you last updated (or > installed) then read back toward the top of the file noting anything > that may apply to your situation. > > There is also information in the Handbook regarding the ports system > which may be of interest to you. > > As a side note, I know that there are other paths to updating > ports and other tools that sometimes reduce the work but rather than to > confuse the OP, I'm choosing not to mention them. If I omitted > something in my description, feel free to jump in. > > I hope this helps give you some insight into the processes. Of course, > in reading all the information and references, if you still have > questions, be sure and ask the list ;-) > > Best regards, > > Randy > -- > Thanks for the blow by blow. I found a similar list in the make file, and did the deed. Seems like every thing's working.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44068EF8.7080601>