plague-client kill hangs
by Josh Boyer
I tried killing a job on the buildsys recently and got some funny
results. The job seemed to actually be killed, and I got an email
stating so. However, the plague-client never returned to the command
line. I'm not sure if it was waiting for a response from the server or
what. Here's the backtrace I got when Ctrl-C'ing it:
jwboyer@yoda FC-4]$ plague-client kill 218
Traceback (most recent call last):
File "/usr/bin/plague-client", line 334, in ?
kill(server, email, jobid)
File "/usr/bin/plague-client", line 179, in kill
(err, msg) = server.kill_job(email, jobid)
File "/usr/lib/python2.4/xmlrpclib.py", line 1096, in __call__
return self.__send(self.__name, args)
File "/usr/lib/python2.4/xmlrpclib.py", line 1383, in __request
verbose=self.__verbose
File "/usr/lib/python2.4/xmlrpclib.py", line 1131, in request
errcode, errmsg, headers = h.getreply()
File "/usr/lib/python2.4/httplib.py", line 1133, in getreply
response = self._conn.getresponse()
File "/usr/lib/python2.4/httplib.py", line 862, in getresponse
response.begin()
File "/usr/lib/python2.4/httplib.py", line 333, in begin
version, status, reason = self._read_status()
File "/usr/lib/python2.4/httplib.py", line 291, in _read_status
line = self.fp.readline()
File "/usr/lib/python2.4/socket.py", line 325, in readline
data = recv(1)
File "/usr/lib/python2.4/site-packages/plague/SSLConnection.py", line 74, in recv
ret = self.__dict__["conn"].recv(bufsize)
KeyboardInterrupt
I'll be gone for the rest of today, but I can play around with stuff
tonight and tomorrow if someone thinks of something.
josh
18 years, 4 months
permissions in mock
by Jeff Pitman
Hi:
Anyone else notice in the build.log that there are areas where
permission is denied when doing stuff. The two most notable are 1.
checking for unpackaged files, and 2. stripping binary libs. It has to
do with the buildroot, but, I have not tracked it down yet.
I'm using the CVS version of mock.
--
-jeff
18 years, 4 months
SSL setup
by Josh Boyer
Ok, either I'm a complete idiot (highly possible) or the instructions on
setting up SSL in the README file of plague are a bit out of date.
I generated the keys and CA as listed in the steps at the bottom of the
README, but it seems that the builder expects the key and cert to be in
one file instead of two separate ones.
/usr/bin/plague-builder -c /etc/plague/builder/CONFIG.py
/etc/plague/builder/certs/builder_key_and_cert.pem does not exist or is
not readable.
Is the README up to date? If not, could someone point out the
highlights of what isn't so I can try to get this running again. I'm
just doing a simple setup of 1 builder and 1 server on the same host.
thx,
josh
18 years, 4 months
plague enhancements...
by Dan Williams
Hi,
I've committed code to include the last 20 lines of the relevant build logs in
the failure email. Should make it a bit easier at first glance to find out what
went wrong.
Second, the build system is aware of what targets (and what arches on those
targets) the builder can actually do, which means we now deal with noarch
packages correctly in a build system as complex as Extras, with lots of targets
and lots of arches.
This _does_ mean that you have to specify the same target names (ie,
"development" not "devel") as is used in the mock config file names in
/etc/mock. If you want to alias anything, do it in whatever you call
plague-client with. I'm not really inclined to add target alias support to the
server itself (other than the CVS target aliases where its actually necessary).
Dan
18 years, 4 months
New build system notes...
by Dan Williams
Hi,
So, a few quick notes. If you're setting it up, you'll need a couple things:
Python 2.3 or 2.4
(consider issues with 2.2 bugs, I'll fix them)
sqlite
sqlite-python
mock from CVS as of 07-01-2005
lighttpd (1)
yum >= 2.2.1
pyOpenSSL (2)
(1) This is technically optional, and use of lighttpd is off by default.
However, the RPM currently requires lighttpd, but you can "--nodeps" the plague
packages to ignore this. We should fix this.
(2) IMPORTANT: You'll need to patch pyOpenSSL with the patch attached to this
email, which enables threadsafety for pyOpenSSL. Without the patch, it _will_
not work and the build server will randomly crash.
Dan
18 years, 4 months
mock --target question
by Dan Williams
Seth,
When mock builds an SRPM with "rpmbuild -ba --target %s" where %s is
config_opts['target_arch'], that arch will always be "i386" or "x86_64" since it
comes directly from the mock config file.
So how does the build system build i486, i586, i686 packages then with mock? If
the build system wants to have mock build an i586 package, the builder has to
choose the "fedora-5-i386-core.cfg" mock config, which has target_arch == i386,
which gets passed to rpmbuild's --target argument. So how would an i586 package
ever come out of mock unless it specified ExclusiveArch: i586?
Do we need to have another mock argument for --arch or am I missing some
rpmbuild magic here?
Dan
18 years, 4 months
Read-only / + !CAP_MKNOD support for mock
by Enrico Scholz
Hello,
the patch which is available at
http://ensc.de/fedora/mock-namespace.diff
changes some things so that mock is a little bit more secure:
* everything except /var/lib/mock can be read-only now; this is done by
- avoiding modification of /etc/mtab* by using the '-n' switch for
'mount'
- executing all mach operations in an own namespace; so the cleanup
of mounts happens automatically without relying on /etc/mtab
- workarounding the 'rpm --root'-touches-the-rpmdb-of-the-host bug;
namespaces mentioned above make it possible to bind-mount the
buildroot-rpmdb into the host
* mock works with removed CAP_MKNOD capabilities; instead of, a precreated
/dev template will be bind-mounted into the buildroot. Ideally, this
precreated template is a mounted cramfs as it can not be modified but
still allows the devices to work (this would not be the case e.g. with a
read-only mounted ext3 fs)
With these modifications, 'mock' can be used within VServers[1]. Please note
that the patch above protects only the filesystem but not processes. So you
will have to restart the buildsystem after each build (takes around 2-3
seconds with vservers and 1-2 minutes with regular hosts). Else, every
hostile package can take control over subsequent builds.
Footnotes:
[1] http://linux-vservers.org
18 years, 5 months
