Hi,
I want to know your opinion!
Updating packages from source with a local copy of the FreeBSD
ports tree offers great flexibility. You can choose from almost
20.000 ports and different versions of the same software. Besides
that you can optionally configure the software and environment
with just the options that fit your needs.
But when it comes to larger environments this flexibility sometimes
lead to annoying surprises. Especially when trying to upgrade a
large farm of servers with different sets of ports installed and
even different port-options for the same software.
There is a good chance that updates will behave differently from
server to server. Thus automating the maintenance becomes tricky.
I decided to stop updating from the local ports tree. Instead I set
up a server with Tinderbox. I've defined some Tinderbox BUILDs
to represent the different package sets:
7.1_freebsd_i386_build1 (apache22, php5, ...)
7.1_freebsd_i386_build2 (database ports)
7.1_freebsd_i386_build3 (apache13, php4, ...)
Additionally I configured the port options and build environment
to match my needs. This makes every of the above build a unique set
with different dependencies.
Now I have ready-to-use package sets that just needs to be installed.
I found the remote fetching feature of pkg_add somewhat useful.
Also the -PP option found in portupgrade helps installing
the packages and keeping them in sync with the server that builds the
package sets.
But this is not enough. pkg_add does it's job quite well, but you have
to do each update manually. Portupgrade automates the update process,
but it depends on a local copy of the portstree... What if the local
ports tree does not exactly match the version I used for building the
packages? How do I tell all my servers to use a specific version of the
ports tree? [...]
Well, I think for this purpose I'd need somethink like yum or
the smart package manager. Both use a repository that provides
information about the packages it holds, and the client basically just
takes care for installing, deleting, updating and resolving conflicts.
So the basic idea would be to take the tinderbox approach and build a
toolset around it that collects the meta-data from the +CONTENS file
of every package. This data could be saved as an XML file. The Origin
of a package (shells/zsh) is the unique identifier and the package name
(zsh-4.3.9_5) is the base for version comparison.
The client would just do the same: generate a XML file from the all
files found in /var/db/pkg/*/+CONTENTS. Afterwards it downloads the XML
file from the repository. So this is the base for comparing versions,
beeing aware of conflicts, and so on...
Of course the repository XML file could also contain information from
/usr/ports/MOVED so we know about origin changes or removed ports...
Basically it's just meant as a addition to the ports system, not as
a replacement, because the whole repository idea really depends on the
ports system.
I think this is not only interesting for server farms, but also for
other distributions of FreeBSD: desktop versions of FreeBSD, ...
fraenki
I want to know your opinion!
Updating packages from source with a local copy of the FreeBSD
ports tree offers great flexibility. You can choose from almost
20.000 ports and different versions of the same software. Besides
that you can optionally configure the software and environment
with just the options that fit your needs.
But when it comes to larger environments this flexibility sometimes
lead to annoying surprises. Especially when trying to upgrade a
large farm of servers with different sets of ports installed and
even different port-options for the same software.
There is a good chance that updates will behave differently from
server to server. Thus automating the maintenance becomes tricky.
I decided to stop updating from the local ports tree. Instead I set
up a server with Tinderbox. I've defined some Tinderbox BUILDs
to represent the different package sets:
7.1_freebsd_i386_build1 (apache22, php5, ...)
7.1_freebsd_i386_build2 (database ports)
7.1_freebsd_i386_build3 (apache13, php4, ...)
Additionally I configured the port options and build environment
to match my needs. This makes every of the above build a unique set
with different dependencies.
Now I have ready-to-use package sets that just needs to be installed.
I found the remote fetching feature of pkg_add somewhat useful.
Also the -PP option found in portupgrade helps installing
the packages and keeping them in sync with the server that builds the
package sets.
But this is not enough. pkg_add does it's job quite well, but you have
to do each update manually. Portupgrade automates the update process,
but it depends on a local copy of the portstree... What if the local
ports tree does not exactly match the version I used for building the
packages? How do I tell all my servers to use a specific version of the
ports tree? [...]
Well, I think for this purpose I'd need somethink like yum or
the smart package manager. Both use a repository that provides
information about the packages it holds, and the client basically just
takes care for installing, deleting, updating and resolving conflicts.
So the basic idea would be to take the tinderbox approach and build a
toolset around it that collects the meta-data from the +CONTENS file
of every package. This data could be saved as an XML file. The Origin
of a package (shells/zsh) is the unique identifier and the package name
(zsh-4.3.9_5) is the base for version comparison.
The client would just do the same: generate a XML file from the all
files found in /var/db/pkg/*/+CONTENTS. Afterwards it downloads the XML
file from the repository. So this is the base for comparing versions,
beeing aware of conflicts, and so on...
Of course the repository XML file could also contain information from
/usr/ports/MOVED so we know about origin changes or removed ports...
Basically it's just meant as a addition to the ports system, not as
a replacement, because the whole repository idea really depends on the
ports system.
I think this is not only interesting for server farms, but also for
other distributions of FreeBSD: desktop versions of FreeBSD, ...
fraenki
However it does not solve it for me, because NFS can't be used everywhere.