Koji server installation
by Degremont, Guillaume
Hello,
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)
[koji@murray ~]$
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
[koji]
;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
;client certificate
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.
Reagrds,
Guillaume Degremont
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 ^^
15 years, 4 months
mock 0.9 backport to F7/F8 -- Feb 1
by Michael E Brown
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.
--
Michael
15 years, 6 months
cache plugin behavior?
by Clark Williams
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael,
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?
Clark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkfIK6sACgkQHyuj/+TTEp1sxACg4cOB0uX5lsBSwprCenpVIVCS
FnMAniBN93OFe9gf6znQreK26yzcB0b9
=Peks
-----END PGP SIGNATURE-----
15 years, 7 months
rebuilding from old cvs tags
by Mike McLean
I ran into an interesting problem while replicating some older Fedora
builds in a test environment. Consider this build:
http://koji.fedoraproject.org/koji/buildinfo?buildID=6144
It was built by task 1648 using this cvs url:
cvs://cvs.fedoraproject.org/cvs/pkgs?rpms/sparse/devel#sparse-0_3-1_fc7
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,
not .fc9.
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?
15 years, 7 months
odd build failures under koji/mock
by Doug Chapman
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:
mv $RPM_BUILD_ROOT/%{_libdir}/openser/perl/*
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.
any ideas?
The full build log of the failure can be seen at:
http://ia64.koji.fedoraproject.org/koji/getfile?taskID=14457&name=build.log
- Doug
15 years, 7 months
[OT?] removing plague jobs...
by Fernando Lopez-Lezcano
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...
-- Fernando
[*] something like "plague-remove <jobid>"
15 years, 7 months
scanning logical volumes from initrd nash script
by Fabio
Hi...
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 ? ....
Thank you
15 years, 8 months
Local packages
by Gary Thomas
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:
xorg-x11-server-1.3.0.0-40.fc8.src.rpm
I make my little change and rebuild, creating:
xorg-x11-server-1.3.0.0-40_AM.fc8.src.rpm
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.
xorg-x11-server-1.3.0.0-40.fc8.src.rpm
is chosen, even when both it and
xorg-x11-server-1.3.0.0-40_AM.fc8.src.rpm
are present.
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
------------------------------------------------------------
15 years, 8 months
Dazed and confused....
by Bryce
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?
Phil
=--=
15 years, 8 months
