# Managing updates on a production system



## am1990 (Jan 25, 2014)

Hello, I'm new here so sorry in advance if this is the wrong section I'm posting in :/

I have to set[]up a server rack running FreeBSD 10.0 for my company's production system. I have some questions about how to manage updates/security updates in FreeBSD. I'm a bit confused about the different managers available, more in deep I'd like to know in what the programs below differs:

freebsd-update
portsnap
portmaster
portaudit

I found a script on another forum that should care about all updates in a system (in a crontab). Is it correct and may be useful in a production server?


```
#!/bin/sh

LOG_FILE="/var/log/freebsd-update.log"
MAIL_ADDR="your@ema.il"

rm ${LOG_FILE}

echo "Starting updates: `date`" | tee -a ${LOG_FILE}
echo "***"
echo "*** Checking for FreeBSD patches..."
/usr/sbin/freebsd-update cron | tee -a ${LOG_FILE}
/usr/sbin/freebsd-update install | tee -a ${LOG_FILE}

echo "***"
echo "*** Updating ports tree..."
/usr/sbin/portsnap cron update | tee -a ${LOG_FILE}

echo "***"
echo "*** Looking for ports to update..."
/usr/local/sbin/portmaster -adH --no-confirm --delete-build-only | tee -a ${LOG_FILE}

echo "***"
echo "*** Checking installed ports for known security problems..."
/usr/local/sbin/portaudit -Fva | tee -a ${LOG_FILE}
echo "Finished updates: `date`" | tee -a ${LOG_FILE}

# the mail is usually sent by the cronjob anyway... else uncomment this line:
# mail -s 'Server update' ${MAIL_ADDR} < ${LOG_FILE}

# do we have a new UPDATING? i might want to read it :-)

if ( test ! -e /usr/ports/UPDATING.md5 ) ; then
  md5 -q /usr/ports/UPDATING > /usr/ports/UPDATING.md5
else
  currentmd5=$(cat /usr/ports/UPDATING.md5)
  newmd5=$(md5 -q /usr/ports/UPDATING)
  if [ $currentmd5 != $newmd5 ] ; then
    mail -s 'New UPDATING file!' ${MAIL_ADDR} < /usr/ports/UPDATING
  fi
fi
```

Thanks a lot in advance for the reply and nice to meet you all


----------



## wblock@ (Jan 25, 2014)

*Re: Manage updates production system*

Reading /usr/ports/UPDATING last is a recipe for problems.  And just blindly throwing -a at portmaster is not going to help.  I feel the same way about freebsd-update, that updates should be done when the operator is there to handle problems.


----------



## am1990 (Jan 25, 2014)

*Re: Manage updates production system*

How about the differences between freebsd-update, portmaster, portsnap and portaudit? Also, in a production system which is the best way to manage updates then?


----------



## wblock@ (Jan 25, 2014)

*Re: Manage updates production system*

The utilities listed update different things.

freebsd-update(8) does binary updates to the operating system itself.  (I don't use this, I do source-based upgrades.)
portsnap(8) updates the ports tree, /usr/ports, the files that are used for building applications.  This can be run at almost any time.
portmaster(8) is a tool for updating applications that have been installed from ports.
portaudit(1) is a tool that compares the versions of installed applications for known vulnerabilities.  When installed, it runs automatically and reports in the daily status emails.

"Best" is a really difficult condition.  It depends on the number of systems involved, how much downtime costs, and what resources are available.


----------



## NewGuy (Jan 25, 2014)

*Re: Manage updates production system*

You probably want to run `freebsd-update` to apply binary updates to the base operating system and `pkg` to update additional packages added to the system. Using tools like portsnap are fine if you installed software from source code, but if you're installing binary packages then the pkg utility is your friend.


----------



## am1990 (Jan 25, 2014)

*Re: Manage updates production system*

What about pkgtools (portinstall, portupgrade) and PKGNG instead? If I've understood correctly these are for binary installed packages right? If it's not why using these or the others we talked about instead? (there are too many ways with dealing with installed software in FreeBSD  ,  just trying to get my head around the options)


----------



## wblock@ (Jan 26, 2014)

*Re: Manage updates production system*

PKGNG *is* pkg.  It will be the package manager for new FreeBSD versions.  You can use ports, which build applications from source, or you can get binary, pre-built packages.  Both are installed with pkg.

If you're using binary packages, there is no reason to update the ports tree.  If you want to use ports, you will have to update the ports tree using portsnap(8) or svn, follow UPDATING, and use a port upgrading tool.  I recommend ports-mgmt/portmaster as the smallest and "usually does the right thing automatically" option.


----------



## am1990 (Jan 26, 2014)

*Re: Manage updates production system*

So this is just another way of installing binary packages?

Also, on a FreeBSD 10.0-RELEASE VM I'm running if I use `pkg install` to say install nginx I'll get the binary package not the one from the ports but you said pkg is for binary *and* port packages, what am I missing?


----------



## NewGuy (Jan 26, 2014)

*Re: Manage updates production system*

It might help to think of it this way: When people talk about working with ports they are usually talking about building programs from their source code. Typically you won't want to do this as it takes more work/steps and time. Most people will probably want to use packages. Packages are the same software as what is available through ports, but the software is pre-built for you.

So unless you have a reason for working with source code and build configuration options you will want to use pkg as it will work with the pre-built binary packages.


----------



## rusty (Jan 26, 2014)

*Re: Manage updates production system*



			
				am1990 said:
			
		

> so http://www.freebsd.org/doc/handbook/packages-using.html this is just another way of installing binary packages?
> 
> Also, on a FreeBSD 10.0-RELEASE vm I'm running if I use `pkg install` to say install nginx I'll get the binary package not the one from the ports but you said `pkg` is for bonary *and* port packages, what am I missing?



Couple of examples, One could use pkg to remove compiled ports and/or their depend_e_ncies (these are us_u_ally installed when building from ports). You could also use it to check security notifications for binary and/or compiled programs.


----------



## wblock@ (Jan 26, 2014)

*Re: Manage updates production system*

With ports, you build and compile from source.  Internally, it generates a binary package, which pkg then installs.
With binary packages, you download a precompiled binary package, which pkg then installs.

The difference is where the package is created.  With ports, you have built it yourself, on your system, and it is built with the current libraries and optimizations for that system.  Binary packages are built on a cluster of machines that might have different versions of software than your system.

On a single system, I do not feel that ports take significantly more time than binary packages.  It often seems that people spend far more time trying to get binary packages to work than it would have taken to just build the port and be done with it.


----------



## am1990 (Jan 26, 2014)

*Re: Manage updates production system*

Uhm, ok I might have understood now. When I `make install` inside a port I compile the program and then `pkg install` it. When I `pkg install`, pkg fetches the binary package from the net and install it. So this is why if I do a `pkg info` I get the list of installed packages, even the ones I built from sources(ports).

Also, regarding portaudit, I've read that with 10.0-RELEASE and PKGNG there's no need for it anymore since there's `pkg audit`. Correct?


----------



## kpa (Jan 26, 2014)

*Re: Manage updates production system*

Yes that's pretty much it allthough when you build a port there's no binary package built unless you tell the ports(7) system to build one. Instead what happens is that `make install` does its work and installs the software and then the packaging system registers the installed files as a package. The end result is the same as if you installed from a binary package.


----------

