I am currently working on deploying a small build system based on mock/koji
The system is very simple, just one server hosting the builds and koji (another buidl system may be added later, but that is not the issue at thje present time).
I am having some troubles deploying koji. The only document I have found is the ServerHowTo (http://fedoraproject.org/wiki/Koji/ServerHowTo).
I retrieved the koji, koji-hub, koji-web and koji-utils packages and installd them successfully on my server.
I configured koji to use SSL following the guidelines.
Not being a SSL expert, I think I did not do any error, but it was tricky since filenames change between the certificate creation section and the kojihub/kojweb/kojid configuration sections.
and I configured all 4 servers (kojihub, kojiweb, kojira, kojid) to be hosted on the same server, named murray.
However, when I try to use koji, I get the following error:
[koji@murray ~]$ koji add-user userTest
Kerberos authentication failed: 'No credentials cache found' (-1765328189)
I have modified the /etc/koji.conf (though it is not mentioned in the How To) as follows, to ensure it will use SSL:
[root@murray ~]# more /etc/koji.conf
;configuration for koji cli tool
;url of XMLRPC server
server = http://murray.mysite.hp.com/kojihub
;url of web interface
weburl = http://murray.mysite.hp.com/koji
;url of package download site
pkgurl = http://murray.mysite.hp.com/packages
;path to the koji top directory
topdir = /mnt/koji
;configuration for SSL athentication
cert = /etc/kojiweb/clients/certs/koji.cert
;certificate of the CA that issued the client certificate
ca = /etc/kojiweb/clients/koji_ca_cert.crt
;certificate of the CA that issued the HTTP server certificate
serverca = /etc/kojiweb/clients/koji_ca_cert.crt
koji_ca_cert.crt being the ca certificate I generated and koji.cert a certificate I generated for the koji user.
This is my first problem. Can anyone help me on this ?
My other problem is with the servers. I configured my apache and started it to have the kojihub and kojiweb started.
I then want to perform some add--user, add-host commands. But I get the message "unable to connect to server".
[root@murray ~]# koji --noauth add-host murray.mysite.hp.com i386 x86_64
Error: Unable to connect to server
With the following logs from httpd:
[Thu Nov 15 10:28:51 2007] [error] [client X.X.X.X] PythonHandler kojixmlrpc: Traceback (most recent call last):
[Thu Nov 15 10:28:51 2007] [error] [client X.X.X.X] PythonHandler kojixmlrpc: File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 299, in HandlerDispatch\n result = object(req)
[Thu Nov 15 10:28:51 2007] [error] [client X.X.X.X] PythonHandler kojixmlrpc: File "/usr/share/koji-hub/kojixmlrpc.py", line 278, in handler\n context.cnx = koji.db.connect(opts.get("KojiDebug",False))
[Thu Nov 15 10:28:51 2007] [error] [client X.X.X.X] PythonHandler kojixmlrpc: File "/usr/lib/python2.4/site-packages/koji/db.py", line 128, in connect\n conn = pgdb.connect(**opts)
[Thu Nov 15 10:28:51 2007] [error] [client X.X.X.X] PythonHandler kojixmlrpc: File "/usr/lib/python2.4/site-packages/pgdb.py", line 383, in connect\n dbtty, dbuser, dbpasswd)
[Thu Nov 15 10:28:51 2007] [error] [client X.X.X.X] PythonHandler kojixmlrpc: InternalError: could not connect to server: Connection refused\n\tIs the server running on host "murray.mysite.hp.com" and accepting\n\tTCP/IP connections on port 5432?\n
Do you know what it comes from ?
I can supply my other conf files, if needed. But I strictly followed the Howto nstructions for the configuration files.
PS: for security related reasons, I replaced the ipaddress with X.X.X.X and changed the hostname and fully qualified domain name with dummy ones ^^
All mock users,
The mock maintainers (Clark, Jesse, me) will upgrade mock in F7/F8 to current 0.9 on/around Feb 1.
The mock 0.9 branch has brewed in rawhide since early Dec, and so far it looks good. The 0.9 branch is now being used on the official build systems, so if there were any major problems, we would expect to have hit them by now.
The *only* difference between 0.8.<latest> and 0.9.<latest> at this point is that we have dropped the old mock setuid wrapper and now use the consolehelper subsystem. For this, you will notice new /etc/pam.d/mock, /etc/consolehelper/mock files which configure mock. The default config is set up to operate exactly the same as the old 0.8 branch: ie. you must be a member of the 'mock' group to run mock. Additionally, with consolehelper comes one new feature: if you are not in the 'mock' group, you will be prompted to enter the root password and it will run. This means you can run mock without worrying about any pre-setup.
-----BEGIN PGP SIGNED MESSAGE-----
I was looking at BZ 233529 on mock and was wondering if the requested behavior seems
valid (it does to me, just wanted a sanity check).
As far as I can tell, the only time the root cache is invalidated is when it ages out
(was looking at the plugin). Does it make sense to also invalidate the cache when the
.cfg that defines it has a newer modification time?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
I ran into an interesting problem while replicating some older Fedora
builds in a test environment. Consider this build:
It was built by task 1648 using this cvs url:
The problem is that if you rebuild this now, you get DIST=fc9, because
devel has moved on. In my case, I am replicating the buildroot, which
includes the package that provides the original DIST=fc7. This leads to
a mismatch. Koji thinks it is building sparse-0.3-1.fc9, but the actual
result is sparse-0.3-1.fc7. The build completes but import fails. I'm
trying to reproduce the build as closely as possible, so I want .fc7,
It occurred to me that Makefile.common could be smarter about this. When
you checkout a specific revision with cvs, that revision is noted in
CVS/Tag. It would be possible (though perhaps messy) for Makefile.common
to note this and behave a little differently.
Why? Better repeatability. If you checkout a specific revision from a
time when dist has a different value, you probably ought to be using
that dist and not the current one.
I suppose the real problem is that although we're building from a
specific revision of the main checkout, we're always using the HEAD of
common. Solving that even more of a mess though (and even if we do, we
still have a whole bunch of builds from unrecorded revisions of common
in the system).
So what do folks think? Am I crazy? Would a Makefile.common patch for
this be welcome?
We have a koji server set up for ia64 where I have been running rawhide
builds through. I am seeing something that I imagine is a regression in
rpmbuild???? that is likely to be seen on the main koji server as well.
Take for example this failed build of openser-1.3.0-8.fc9.src.rpm:
On our ia64 koji server it failed with:
+ mv '/var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/openser/perl/*' /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/perl5/vendor_perl/5.8.8/
mv: cannot stat `/var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/openser/perl/*': No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.7626 (%install)
The line in the specfile that triggered this is:
somehow it appears it took the * path as literal.
Looking at the main koji server at a build of the same package it
expanded the * properly:
+ mv /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib64/openser/perl/OpenSER /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib64/openser/perl/OpenSER.pm /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/perl5/vendor_perl/5.8.8/
My only guess is this is a bug in rpmbuild which was introduced after
openser was built on the main koji server (Feb 9th).
I have several other packages failing in a similar manner, all fail to
expand * properly.
The full build log of the failure can be seen at:
Would this be the right list for this question?
I have a mock/plague build system I'm just configuring and I wonder how
can I get rid of old builds? (ie: erase all related files and clean up
the database). Should be simple[*], I must be missing something obvious...
Thanks for any help...
[*] something like "plague-remove <jobid>"
The initrd nash script 'init' actually scans for logical volumes as follows:
..... code snippet from 'init' script ............
echo Scanning logical volumes
lvm vgscan --ignorelockingfailure
echo Activating logical volumes
lvm vgchange -ay --ignorelockingfailure *<fixed volgroup name>*
....... end of code snippet .....
The volgroup name is fixed, it is written in the script itself.
How to change this script in order to activate the logical volume name
output of the 'vgscan' command?
Nash is not the same as bash and I don't know how to do something like this:
volgroup_name=`lvm vgscan --ignorelockingfailure`
lvm vgchange -ay --ignorelockingfailure $volgroup_name
Have you some suggestion ? ....
I'm trying to build a localized repository:
Fedora + Updates + Local Packages
Some of the local packages are derived from the mainline. I
make some [minor] changes to match my hardware (sadly, my
mods aren't suitable for pushing upstream). I want to keep
the version+revision pretty much intact so I know where the
package came from, etc. For example, I need to have a slightly
modified X server (uncommon hardware, yeah!). So, I started
with the package:
I make my little change and rebuild, creating:
along with the desired binary packages.
I'm trying to run pungi to create a munged/tailored repository,
using the official versions of Fedora & Updates. Sadly, it
seems that the original package always seems to override the
one with my modifications, e.g.
is chosen, even when both it and
Is there a way to set the version so that my package always
wins? That way, I can use the 100% official repositories as
the starting point and only have my little mods.
Thanks for any pointers
n.b. at the moment, I'm just pruning the packages I need to
change out of the official versions (local copies of course),
but this is tedious and fraught with error.
Gary Thomas | Consulting for the
MLB Associates | Embedded world
Just playing around with a miniature version of koji at home, building
off my own box (i386/x86_64) using koji-1.2.5
Issue 1. The kernel, because my build host is defined as arch i386,
x86_64 when I pass a kernel build in, it passes "--target i386" which
leads to the usual train wreck of no i386 config
how do I pass in i686 specifically for the kernel?
Issue 2. One of the fun items in xen is that when you're building the
64bit version there is an odd dependency on pulling in a 32bit
glibc-devel by adding /usr/include/gnu/stubs-32.h to the dependency
list, when building in x86_64 that dependancy cannot get satisfied. How
can I beat the tag into realizing it can pull from the i386 repo to
fulfill that requirement?