Number of commits found: 19

Remove portbuild scripts from pcvs, as they now live in svn/projects.

Although I was going to try to avoid it, it turns out that it is
impossble to have merely "server.conf" and "client.conf" control
everything on a head node.  Some pieces must be refactored into
"common.conf".

Generalize the packge building scripts to be able to be run on more than
one 'head' node, rather than just pointyhat itself.

Constants are factored out into installation-specific files known as
portbuild/conf/server.conf and portbuild/conf/client.conf.  There is
only one server.conf file.  Individual <arch> directories may have
their own client.conf files, or may symlink to ../conf/client.conf.

While here, rework the code a bit to parameterize arch-specific tasks.

Feature safe:   yes

Harden these a bit: make them identify on which host they were running;
skip unncessary steps.

* Cleanup
* Catch up to build ID directory changes
* Improved support for ZFS
* Desupport X11BASE

Support builds using zfs and tmpfs backing store

zfs:

* Enabled by use_zfs=1 in portbuild.conf

* Populate build chroots by cloning a zfs snapshot instead of maintaining
  many duplicate copies.  In principle this is very efficient since
  everything is copy-on-write and zfs snapshot creation is almost
  instantaneous.  There might be additional overheads from building on zfs
  though.  Currently the snapshot base is hard-wired to y/${branch}@base
  but should be parametrized.  This also must be populated beforehand, e.g.
  during machine startup

* Clean build chroots by just destroying the snapshot.

tmpfs:

* Enabled by use_tmpfs=1 and tmpfs_size in portbuild.conf

* The previous md strategy of mounting in used/, populating and then
  remounting (to avoid possible races from multiple builds claiming the
  same chroot) doesn't work here because tmpfs instances are destroyed at
  umount.  I am not entirely sure the simpler approach is free from races.

Also attempt to clean /root/.ccache in case it is in use.  When cleaning
on a machine that has use_md_swap=1, allow for the possibility of reusing
a md between builds if md_persistent=1.  This requires a patch from pjd
to support BIO_DELETE in md devices, but it is a big optimization when
it can be used.

Go back to force unmounting because not doing so was too unreliable.

Clean up linprocfs on amd64 as well.

* In kill_procs(), pass in the directory and mountpoint as separate
  arguments (cosmetic)

* Detect if a chroot was used to run a jailed build, and first attempt
  to gracefully shut it down by killing everything within using pgrep(1)
  This has a much higher chance of succeeding that relying on fstat to
  identify processes that might interfere with our attempts to clean up
  mountpoints, which is fragile (libkvm-dependent), and inherently
  unreliable at best.

Instead of passing in a "noclean" boolean, pass in a "clean" level:
  0 = don't clean chroot
  1 = sanitize commonly-modified directories
  2 = remove entire chroot

Pull in buildenv for LOCALBASE/X11BASE locations

Don't bother cleaning up doc mounts, they are not needed.

* Add support for use_md_swap

Silence some possible errors from chflags -R

* Instead of using umount -f to unmount things, first use fstat to
look for processes holding open references within the FS and kill
them, then use regular umount.  This is necessary now that devfs
cannot be force-unmounted, and has the benefit that processes can't
hang around holding references to files between port builds.

* Reduce possibility for error by testing for presence of executable
ldconfig inside the chroot before attempting to run it (e.g. it may not
be there if the chroot was not completely initialized)

Remove traling spaces.

Be silent about attempts to unmount filesystems from within the chroot

Refuse to "clean" / if something goes wrong upstream and we are passed
the wrong path

Approved by:    portmgr (self)

Clean up the specified chroot (umount filesystems, and scrub the
directories likely to contain changed files).

Number of commits found: 19

8 vulnerabilities affecting 120 ports have been reported in the past 14 days

^* - modified, not new

All vulnerabilities

Last updated:
2019-05-23 20:44:01