On 11/24/2010 10:59 AM, Jinze Xue wrote:
I want to move all data from a old koji build system to a new os,
what's
the best way to do?
A koji system generally includes multiple hosts, so I'm not sure which
ones you are need to migrate. I'm also not sure what os you're moving
from and to, or how.
For build hosts, it's generally just a matter of preserving the files
under /etc/koji: mainly kojid.conf, but possibly also some key files for
authentication. Once the new OS is installed/upgraded, make sure
koji-builder is installed and that the config files are intact.
For host(s) running koji-hub and/or koji-web it is much the same.
Preserve the necessary config files, and restart the services after the
migration.
For your postgresql server, well, you should probably refer to the
postgresql manual for completeness. Short version... you'll want to back
up your koji database with pg_dump before you do anything. If the
version of postgres in the new os is not too different, you can probably
manage with just preserving all the /var/lib/pgsql/ content. If not, you
can restore from your dump with pg_restore. You'll also need to preserve
key postgres config settings, particularly those that allow koji-hub to
access the database.
and who have documents about configs and steps to build cvs system
for a
koji build system ? send me ,thanks very much !!!!!!!
Most of the complication here comes from koji's support of the somewhat
messy dist-cvs system that Fedora used to use. However, you don't have
to use such a complicated setup. You can skip all the common dir stuff
if you make sure all the cvs modules you build handle the following sanely:
1) issuing 'make sources' in the checkout dir does something sane (or
at least is an error-free no-op) [*]
2) the checkout contains exactly one spec file
3) the checkout contains all the necessary files for rpmbuild to build
the srpm from that spec file
[*] in the allowed_scms config for your build hosts, you can change the
'make sources' command to something else for individual scms.
I should point out that all of this is true for git and svn as well.