Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 15 Apr 2011 21:20:33 +0200
From: Piotr Meyer <>
Subject: Re: usage of BSD ports for Owl

On Fri, Apr 15, 2011 at 10:17:04PM +0400, (GalaxyMaster) wrote:
> My concern is how pkgsrc would handle bulk installation on a bunch of
> servers?  updates?  I never worked with ports before, so my questions
> may be dumb, but with binary packages it's quite trivial to support a
> park of servers and do updates/modification of a set of package across
> these servers.  Recently, I needed to install 30+ systems in a day.  If
> we had ports, would I need to build packages on each of these 30+ boxes?

Fortunately, updating or bulk installing pkgsrc may be very easy. Whole
installation resides in /usr/pkg directory (typically) and can be tarred, 
rsynced and moved without problems - especially when pkgsrc-meta data are
also located in /usr/pkg (it's configurable but not default).

In my case: I have separated build environment (in some cases it's
simply chroot). After building new version I upgrade packages in test 
environment. If all things are OK I use simply script that made rsync 
from 'template' to rest of servers. I never build packages on 'production'
server, even if this is standalone install - it's unreliable, pkgsrc
can automagically (re|un)installs upgraded packages, it's Bad Idea for
running service ;)

When I plan Really Big Changes I always can preserve old root by 
mv /usr/pkg /usr/pkg.[date] and install totally new version in /usr/pkg.

The biggest pkgsrc advantages for me, are:
- OS-agnostic nature of pkgsrc. It's not FreeBSD project, it's not
  gentoo-specific project: pkgsrc is usable in various linux distros
  (I work mostly with Debian/RHEL-based), Haiku, DragonFly and even

- automatic builds: You can set every option in global config file
  (mk.conf) and then built 'empty' package that depends on all needed
  applications. I most cases all finishes without user interaction.
  For example I have my own makefiles that simply builds complete
  mail (postfix, dovecot, amavisd, clamav) or www servers (php and all
  typically requested modules) after one 'make package'.

- pkgsrc is easily configurable:
  Packages are defined by makefiles[1] (global config is makefile too). 
  Typical options for individual packages looks like following ('-' means

PKG_OPTIONS.nginx=              ssl pcre
PKG_OPTIONS.php=                suhosin
PKG_OPTIONS.screen=             ncurses
PKG_OPTIONS.mysql5=             -embedded-server -ndb-cluster

   pkgsrc is highly configurable, many daemons allow precise settings,
   for example:

# uids and gidas
PKG_UID.nginx=   788
PKG_GID.nginx=   788

   Sets prefferred uid and gid for user/group nginx (used by - surprise 
   - nginx daemon ;)
- pkgsrc has 'vulnerabilities' file, maintaned by security team and tools
  for reporting (also during builds) vulnerable packages.a
  IMVHO it's biggest advantage.

  Typical audit session (usually run from cron):
  $ audit-package 
  Package rsync-3.0.4nb1 has a denial-of-service vulnerability, 

  Sample build (in linux environment 'bmake package'):
  # make package
=> Bootstrap dependency digest>=20010302: found digest-20080510
WARNING: Deprecated variable _ACCEPTABLE found, use SKIP_LICENSE_CHECK=yes
===> Checking for vulnerabilities in rsync-3.0.7
Package rsync-3.0.7 has a denial-of-service vulnerability, see
ERROR: Define ALLOW_VULNERABLE_PACKAGES in mk.conf or IGNORE_URL in pkg_install.conf(5) if this package is absolutely essential.

*** Error code 1

make: stopped in /usr/pkgsrc/net/rsync

1 -

PS. Yes, I declared simple howto for Owl, but I was very busy in last 

PS2. Web frontend for pkgsrc:
     Mailing lists archives:
     pkgsrc-work-in-progress project:

Piotr 'aniou' Meyer

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.