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
plague: Job waited too long for repo to unlock. Killing it...
by Michael Schwendt
If in a failed job.log you see the message
Job waited too long for repo to unlock. Killing it...
please notify me.
It's a problem in the plague server code that results in a denial of
service for subsequent build jobs. I have a traceback from Dec 28th, but
in the context of the source code it doesn't make sense yet (because a few
lines earlier the code ensures that the files to be copied exist and are
readable). Buildsys runs a slightly modified version that adds a bit more
debug output in this area.
[...]
37683 (grads/ppc): Build result files - [ 'state.log', 'grads-1.9b4-21.el5.src.rpm', 'grads-debuginfo-1.9b4-21.el5.ppc.rpm', 'grads-1.9b4-21.el5.ppc.rpm', 'root.log', 'build.log', 'job.log' ]
37683 (grads/x86_64): Build result files - [ 'root.log', 'build.log', 'grads-debuginfo-1.9b4-21.el5.x86_64.rpm', 'grads-1.9b4-21.el5.x86_64.rpm', 'grads-1.9b4-21.el5.src.rpm', 'state.log', 'job.log' ]
37683 (grads/i386): Build result files - [ 'build.log', 'state.log', 'grads-1.9b4-21.el5.i386.rpm', 'job.log', 'root.log', 'grads-debuginfo-1.9b4-21.el5.i386.rpm', 'grads-1.9b4-21.el5.src.rpm' ]
Repo 'fedora-5-epel': updating repository metadata...
Exception in thread Repo: fedora-5-epel:
Traceback (most recent call last):
File "/usr/lib64/python2.3/threading.py", line 436, in __bootstrap
self.run()
File "/usr/share/plague/server/Repo.py", line 233, in run
self._update_repo()
File "/usr/share/plague/server/Repo.py", line 137, in _update_repo
shutil.copy(src, file_in_dst)
File "/usr/lib64/python2.3/shutil.py", line 72, in copy
copymode(src, dst)
File "/usr/lib64/python2.3/shutil.py", line 49, in copymode
st = os.stat(src)
OSError: [Errno 2] No such file or directory: '/srv/rpmbuild/server_work/fedora-5-epel/37683-grads-1.9b4-21.el5/x86_64/grads-1.9b4-21.el5.x86_64.rpm'
37683 (grads): Job finished.
15 years, 4 months
mock: enable gpgcheck for f8 config file
by Till Maas
Hiyas,
now that the groups repo is not used anymore in mock, imho the gpgcheck option
can be enabled by default and only be disabled for the local repo. It will
only need the required gpg-keys be included in the mock rpm and some more
lines in the config files. I will write a patch for this if you will apply
it.
Regards,
Till
15 years, 5 months
query: mock + libselinux-mock.so LD_PRELOAD... why?
by Michael E Brown
I need a little bit of help understanding what the
'libselinux-mock.so' LD_PRELOAD was supposed to be doing. I released and
pushed out mock-0.8 without this. I have rebuilt most of rawhide with
this new mock version and have not seen anything that I directly can say
was a failure due to this being missing, so I am sort of not seeing the
point.
I have searched around as much as I can to try to understand why
this was put into place. From what I can understand, it was only put in
in the FC2 timeframe to fix some problems with the selinux policy on the
host machine. These *appear* to have been fixed in the host selinux
policy, so again, i dont see a reason to keep this around.
Jesse mentioned on IRC, though, that this might be needed, so I pose
this question. I've a local branch set up with the 0.8.x code and the
LD_PRELOAD put back in. So, I can quickly spin a new release with this
back in if it is actually needed. So far, I havent convinced myself it
is needed, though...
Could somebody please enlighten me?
--
Michael
15 years, 5 months
Pathname-based buildreqs not working?
by Paul Howarth
Yesterday I noticed that mock/yum seem to be having trouble finding
pathname-based buildreqs.
For example, buildreqs of /usr/include/tcpd.h and /usr/include/pcap.h
aren't getting found. I use these to maintain spec compatibility across
various releases, where these files can be found in either tcp_wrappers
or tcp_wrappers-devel, or libpcap or libpcap-devel packages
respectively.
I've tried upgrading to mock 0.8.15 from CVS (F-8 branch) and it hasn't
helped.
Is this intentional behaviour (not getting/reading the filelists
metadata) for speed purposes?
Paul.
15 years, 5 months
[mock patch] add ia64 and alpha to personality_defs
by Doug Chapman
Patch to quiet the "Unable to find predefined setarch personality"
warnings seen on ia64. I added alpha as well while I was at it.
Signed-off-by: Doug Chapman <doug.chapman(a)hp.com>
----
diff -up mock-0.9.3/py/mock/util.py.arches mock-0.9.3/py/mock/util.py
--- mock-0.9.3/py/mock/util.py.arches 2007-12-20 09:26:36.000000000 -0500
+++ mock-0.9.3/py/mock/util.py 2007-12-20 09:27:13.000000000 -0500
@@ -190,6 +190,7 @@ personality_defs = {
'x86_64': PER_LINUX, 'ppc64': PER_LINUX, 'sparc64': PER_LINUX,
'i386': PER_LINUX32, 'i586': PER_LINUX32, 'i686': PER_LINUX32,
'ppc': PER_LINUX32, 'sparc': PER_LINUX32, 'sparcv9': PER_LINUX32,
+ 'ia64' : PER_LINUX, 'alpha' : PER_LINUX,
}
import ctypes
15 years, 5 months
mock issues on ia64 with LoadLibrary("libc.so.6")
by Doug Chapman
I am in the process of trying to build fedora on ia64. I updated to the
latest mock today in order to get the new --copyin functionality which I
think will help with a lot of the dependency issues I am having (very
cool functionality by the way!).
However, I have found that other changes made at some point after
mock-0.7.6-1 breaks mock on ia64.
The problem is it tries to load the libc.so.6 library. On ia64 this
does not exist since it uses libc.so.6.1 (FYI, that is the case both on
F8 and on RHEL5 for ia64). This also concerns me since if the version
of the library changes mock will cease to work on other platforms as
well.
This bit of code is in both util.py and uid.py:
import ctypes
_libc = ctypes.cdll.LoadLibrary("libc.so.6")
If I change it to libc.so.6.1 on my ia64 system it works OK. I tried
just specifying libc.so but python is very unhappy about that (I tried
that on x86_64 also and it is also unhappy with libc.so).
Does anybody have ideas on how we can make this more portable?
thanks,
- Doug
15 years, 5 months
mock not processing /etc/profile.d/*, not a login shell?
by Rex Dieter
With recent versions of mock, (ie, mock-0.8 series), I've noticed change in
behavior, seemingly the mockbuild user doesn't include stuff
from /etc/profile.d/* (my guess is that it's no longer being treated as a
login shell).
I mention this because bunch of kde-related packages that once built fine,
no longer do, because /etc/profile.d/qt.sh apparently isn't getting
source'd into the build environment (and env vars QTDIR, QTLIB, QTINCLUDE
aren't getting set properly).
Can anyone confirm/deny this?
-- Rex
15 years, 5 months
F8 rawhide, error from method.py during kickstart install from cdrom
by Martin Steinmann
F8 RAWHIDE updated. I get the following error from anaconda doing a kickstart install from cdrom:
File "/usr/lib/python2.5/site-packages/pykickstart/commands/method.py", line 81, in parse
(opts, extra) = op.parse_args(args=args)
AttributeError: 'NoneType' object has no attribute 'parse_args'
install exited abnormally [1/1]
This happens right after anaconda started the X server.
The kickstart file used looks fairly straight forward. Could this be a known error?
thanks
--martin
ks.cfg:
#--- Installation method (install, no upgrade) and source (CD-ROM)
install
cdrom
#--- Debugging (uncomment next line to debug in the interactive mode)
#interactive
#--- Language and input support
lang en_US.UTF-8
##langsupport --default=en_US.UTF-8 en_US.UTF-8
keyboard us
##mouse generic3ps/2
#--- X-Windows (use "skipx" directive to skip X-Windows configuration)
skipx
#--- Network configuration
# Add some default or else Anaconda will pop a window and ask
network --device eth0 --bootproto static --ip 192.168.1.176 --netmask 255.255.255.0 --gateway 192.168.1.1 --nameserver 192.168.1.145 --hostname sipx.example.com
#--- Authentication and security
rootpw setup
firewall --disabled
selinux --disabled
authconfig --enableshadow --enablemd5
#--- Time zone
timezone America/New_York
#--- Boot loader
bootloader --location=mbr
#--- Partitioning
#--- NON_RAID Disk partitioning (LVM)
zerombr yes
clearpart --all --initlabel
part /boot --fstype ext3 --size=128
part swap --size=1024
part /recovery --fstype ext3 --size=1024
part / --fstype ext3 --size=4096
part /var --fstype ext3 --size 1 --grow
#--- Reboot the host after installation is done
reboot
#--- Package selection
%packages --resolvedeps
e2fsprogs
<snip>
15 years, 5 months