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, 11 months
[PATCH] Add anaconda-runtime to the package list for buildinstall
by Mark McLoughlin
With e.g.:
repo --name=rawhide --baseurl=http://foo
%packages
%end
You get:
OSError: Got an error from /usr/lib/anaconda-runtime/buildinstall:
and trying out the buildinstall command directly, you see:
Running buildinstall...
No Match for argument anaconda-runtime
Nothing to download
The issue here is that one of the first things buildinstall
tries to do is install anaconda-runtime from the supplied
repository, so the user must add anaconda-runtime to the
package list or pungi fails.
Automatically add it to the package list rather than
requiring the user to do it.
Signed-off-by: Mark McLoughlin <markmc(a)redhat.com>
---
src/bin/pungi.py | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/src/bin/pungi.py b/src/bin/pungi.py
index 91ca403..bcbe6fd 100755
--- a/src/bin/pungi.py
+++ b/src/bin/pungi.py
@@ -77,6 +77,10 @@ def main():
# Actually do work.
if not opts.sourceisos:
+ if opts.do_all or opts.do_buildinstall:
+ # buildinstall requires anaconda-runtime (rh #443371)
+ ksparser.handler.packages.add(["anaconda-runtime"])
+
if opts.do_all or opts.do_gather:
mygather = pypungi.gather.Gather(config, ksparser)
mygather.getPackageObjects()
--
1.5.4.5
15 years, 11 months
arch specific packages pulled in by pungi
by Doug Chapman
When building an install image using pungi and the example rawhide-
fedora.ks that is provided we found that elilo does not get pulled in on
our ia64 builds. For those not familiar with ia64 elilo is the
bootloader used instead of grub.
What is the best way to fix this? For now we just added it to the
rawhide-fedora.ks we are using but I am wondering if there is a more
appropriate fix for packages like this that are required for boot.
Since I don't see grub as part of the example rawhide-fedora.ks supplied
with pungi I am wondering if there is some other mechanism pungi uses to
know to pull packages like this in. If so that seems like the right way
to handle elilo.
This will also be an issue for x86 systems that boot with elilo.
thanks,
- Doug
16 years
fun with CVS branching
by Bill Nottingham
Two things from this mass branching that showed up:
1) Something weird happened, and all the modules entries pw*-z
got deleted from the modules file halfway through. We get to try
and put them back. Um, yay?
2) The modules file, *as it stands now*, is nearly 3MB checked out,
and nearly *1.2GB* under RCS. That can't be good.
The reason for this is to allow for the creation of pseudo-modules
for each 'branch', i.e., so 'cvs co FC-5' generates a:
FC-5/bash
FC-5/automake
FC-5/autoconf
...
tree, where the FC-5/<package> directory is the 'normal' <package>/FC-5
dir.
(Note that the 'devel' meta-branch is done in an Entirely Different
manner.)
So, the question would be... is this worth it? Do we want to keep
supporting this?
Bill
16 years
Makefile.common change
by Dennis Gilmore
The way we currently check for branches is broken at release time. everything
that was tagged in devel that was branched for F-9 when you try and build in
koji gets a disttag of .fc10 and fails to build due to a mismatch. this has
been a minor issue in the past. but it is a big issue for secondary arch
rampup.
Makefile.common checked for the existence of a branch file which devel does
not have. it is added at branch time. long term we probably need to add
some logic so that we always have a branch file and check it and fall back to
this method if its not there. it will help with always being able to
reproduce a srpm.
Since this is somewhat invasive i wanted to run it by people first. it
worked ok in my testing.
Dennis
16 years
koji clone-tag?
by Doug Chapman
We are working on building a beta release of our ia64 F9 bits. I have
been digging through the wiki for general release engineering processes
and found this:
http://fedoraproject.org/wiki/ReleaseEngineering/SOP/FreezingRawhide?high...
which shows using the command:
koji clone-tag dist-f8 f8-final
however, I find that the clone-tag command does not actually exist. Was
it replaced by something else? We are looking for a way to take the
latest version of all packages and tag them with a tag which will be
used to build the beta release.
- Doug
16 years
[patch] Require createrepo >= 0.4.11
by Jeroen van Meeuwen
I found pungi does not require createrepo >= 0.4.11, although it needs
that; attached is one of the smallest patches, ever ;-)
Kind regards,
Jeroen van Meeuwen
-kanarip
16 years
Mock / Koji issues on EL5
by Jeroen van Meeuwen
Hello there,
I was about to send this mail about all kinds of errors I had not seen
before, until I somehow ended up screwing around in the code and fixed
like 6 things that I did wrong. Still one minor thing though:
On a CentOS 5, up-to-date box, I am running mock-0.9.7-1.el5, and
koji-1.1-2.el5. I could not update to koji-1.2.3-1.el5 because it has a
missing dependency on createrepo >= 0.4.11.
When using the following command (or submitting the build through koji):
mock --configdir=/etc/mock/koji -v -r dist-el5-build-3-3 rebuild
~/rpmbuild/SRPMS/revisor-2.1.0-1rc5.src.rpm
The macros koji writes out in it's mock configuration file is a string,
while mock expects a dict. I think this change made it in
koji-1.2.3-1.el5, but for now...
I changed line 62 in mock/backend.py from:
self.macros = config['macros']
into:
self.macros = {}
if isinstance(config['macros'], str):
_macros = config['macros'].split('\n')
while len(_macros) > 0:
(key, value) = _macros.pop(0).split(' ')
self.macros[key] = value
else:
self.macros = config['macros']
I hope this helps others on el5 running into this problem.
Kind regards,
Jeroen van Meeuwen
-kanarip
16 years
