Re: Signing built RPMs or how to create signed RPMs.
by Oliver Falk
Hi!
How small the Austrian IT landscape is... I know the guy who provides this patch.
Shall I kick him for not submitting the patch upstream? ;-)
-of
Paul B Schroeder <paulbsch(a)vbridges.com> schrieb:
>Vijay..
>
>Your version of koji is using this:
>ftp://ftp.pramberger.at/software/patches/koji-1.2.2-rpmsign.tar.gz
>
>Cheers...Paul...
>
>
>On 12/16/2010 02:25 AM, Vijay N Majagaonkar wrote:
>> I can send you diff of koji python file :)
>> Just for update siging of RPM file is working with our buid system
>>
>>
>> V!jay
>>
>> On Dec 16, 2010, at 1:49 AM, Mike McLean<mikem(a)redhat.com> wrote:
>>
>>> On 12/14/2010 09:29 PM, Vijay N. Majagaonkar wrote:
>>>> yea it has option --sigkey, in older version of koji,
>>>> "koji-1.2.6-1.20090109.1409.46.fc9.noarch" this version i have installed in
>>>> server,
>>>>
>>>>
>>>> I understand why you asked this question, even i don't find this option on
>>>> my client box that has newer version installed :)
>>>
>>> I've search git and no commit has ever added it. In fact no command has
>>> ever had a --sigkey option (only --key, --keytab, or --sigs). The
>>> version you have installed on your server has either been strangely
>>> modified (it's not even clear what associating a sigkey with a tag would
>>> mean) or is experiencing some sort of bug.
>>>
>>> You should compare /usr/bin/koji on your server to the version of
>>> cli/koji from the koji-1.2.6-1.fc9 tag in git.
>>> https://fedorahosted.org/koji/browser/cli/koji?rev=7899fb704fd33ace3654b5...
>>> --
>>> buildsys mailing list
>>> buildsys(a)lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/buildsys
>> --
>> buildsys mailing list
>> buildsys(a)lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/buildsys
>
>--
>---
>Paul B Schroeder
><paulbsch "at" vbridges "dot" com>
>--
>buildsys mailing list
>buildsys(a)lists.fedoraproject.org
>https://admin.fedoraproject.org/mailman/listinfo/buildsys
13 years, 4 months
koji sign plugin
by Paul B Schroeder
As a follow up to the recent thread on singing RPMs in koji...and the many times this question pops
up on the list. I've written some code that uses the koji plugin framework for signing packages.
I'm betting this may be useful to many folks that don't want/need sigul. It might also be useful
to get this into the koji-hub-plugins package?
At any rate, here is the code and an example config file.. sign.py goes into your PluginPath.
The config file needs to be readable by the apache user and should probably be chmoded 600. Also,
make sure you add sign to the Plugins option in hub.conf. Oh, you'll want to install pexpect too.
sign.py:
# Koji callback for GPG signing RPMs before import
#
# Author:
# Paul B Schroeder <paulbsch "at" vbridges "dot" com>
from koji.plugin import register_callback
import logging
config_file = '/usr/lib/koji-hub-plugins/sign.conf'
def sign(cbtype, *args, **kws):
if kws['type'] != 'build':
return
# Get the tag name from the buildroot map
import sys
sys.path.insert(0, '/usr/share/koji-hub')
from kojihub import get_buildroot
br_id = kws['brmap'].values()[0]
br = get_buildroot(br_id)
tag_name = br['tag_name']
# Get GPG info using the config for the tag name
from ConfigParser import ConfigParser
config = ConfigParser()
config.read(config_file)
rpm = config.get(tag_name, 'rpm')
gpgbin = config.get(tag_name, 'gpgbin')
gpg_path = config.get(tag_name, 'gpg_path')
gpg_name = config.get(tag_name, 'gpg_name')
gpg_pass = config.get(tag_name, 'gpg_pass')
# Get the package paths set up
from koji import pathinfo
uploadpath = pathinfo.work()
rpms = ''
for relpath in [kws['srpm']] + kws['rpms']:
rpms += '%s/%s ' % (uploadpath, relpath)
# Get the packages signed
import pexpect
logging.getLogger('koji.plugin.sign').info('Attempting to sign packages'
' (%s) with key "%s"' % (rpms, gpg_name))
rpm_cmd = "%s --resign --define '_signature gpg'" % rpm
rpm_cmd += " --define '_gpgbin %s'" % gpgbin
rpm_cmd += " --define '_gpg_path %s'" % gpg_path
rpm_cmd += " --define '_gpg_name %s' %s" % (gpg_name, rpms)
pex = pexpect.spawn(rpm_cmd, timeout=1000)
pex.expect('(E|e)nter (P|p)ass (P|p)hrase:', timeout=1000)
pex.sendline(gpg_pass)
i = pex.expect(['good', 'failed', 'skipping', pexpect.TIMEOUT])
if i == 0:
logging.getLogger('koji.plugin.sign').info('Package sign successful!')
elif i == 1:
logging.getLogger('koji.plugin.sign').error('Pass phrase check failed!')
elif i == 2:
logging.getLogger('koji.plugin.sign').error('Package sign skipped!')
elif i == 3:
logging.getLogger('koji.plugin.sign').error('Package sign timed out!')
else:
logging.getLogger('koji.plugin.sign').error('Unexpected sign result!')
if i != 0:
raise Exception, 'Package sign failed!'
pex.expect(pexpect.EOF)
register_callback('preImport', sign)
sign.conf:
[DEFAULT]
rpm = /bin/rpm
gpgbin = /usr/bin/gpg
gpg_path = /usr/lib/koji-hub-plugins/sign_gnupg
gpg_name = My Company, Inc. <support(a)mycompany.com>
gpg_pass = my_passphrase
# Defaults can be overridden on a per-tag basis
[dist-foo-build]
gpg_name = My Other Company, Inc. <support(a)myothercompany.com>
gpg_pass = my_other_passphrase
Cheers...Paul...
--
---
Paul B Schroeder
<paulbsch "at" vbridges "dot" com>
13 years, 4 months
Kojid & NFSv4 with sec=krb5p
by Anthony Joseph Messina
I have been able to set up a private Koji instance using Kerberos and
have /mnt/koji shared via NFSv4 using sec=krb5p -- with manual
intervention after kojid startup, however, I have some questions
regarding automation.
The /mnt/koji directory is exported with (/etc/exports)
/export *.example.com(fsid=0,sec=krb5p)
/export/home *.example.com(rw,nohide,sec=krb5p)
...
/export/koji *.example.com(ro,nohide,sec=krb5p,all_squash)
...
The kojibuilder user on each of the kojid hosts needs read access to
this directory, so I attempted to use the following script at startup
(and via cron jobs to keep the kojibuilder (uidnumber 492) user's
credentials refreshed):
------------
#!/bin/bash
KRB5CCNAME="/tmp/krb5cc_492"
export KRB5CCNAME
/usr/bin/kinit -k -t /etc/kojibuilder.keytab \
kojibuilder/build.example.com(a)EXAMPLE.COM
chown kojibuilder:kojibuilder $KRB5CCNAME
chcon -t user_tmp_t $KRB5CCNAME
-----------
But unless I 'su - kojibuilder' and run the above script, the
kojibuilder user is not able to access the krp5p mount. Once I run the
script as the kojibuilder user, then kojid builds won't fail with mock
errors.
Are there other users who have a better solution for this? Right now,
the kojihub is exporting other mounts to actual users and it doesn't
appear that I can enforce krb5p on all other exports except this one.
Thanks. -A
--
Anthony - http://messinet.com - http://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E
13 years, 4 months
Reimporting deleted builds into Koji
by Alan Franzoni
Hello,
it sometimes happens that the now working garbage collector deletes a
build - mostly for an externally imported package - that we'd not
really mean to delete.
It seems impossible to import back that build from a src+binary rpm -
koji says it's already there - and there seems no obvious way to
change the state and revert the deletion.
As a workaround we copied the packages back where koji expected them
and changed the "state" column in the "build" database table back to 1
(completed).
Is there any better way to do it? Isn't there a "koji forget-build" command?
--
Alan Franzoni
--
contact me at public(a)[mysurname].eu
13 years, 4 months
Speeding up koji-generated mock builds
by Alan Franzoni
Hello,
I'm trying to get our koji instance faster; since we build a lot of
packages, we'd like to reduce the latency.
There're some things that usually make mock faster: the options I
tinkered with and seem to improve performance are root_cache,
yum_cache and tmpfs.
All of those are disabled by default when generating mock config
through koji, and there seems no way to override them:
https://fedorahosted.org/koji/browser/koji/__init__.py#L1276
So here come the questions:
1) Am i missing anything?
2) are all those options intentionally locked out?
3) would a patch which let them be configured be accepted into your git repo?
4) any other way to speedup mock?
Thanks!
--
Alan Franzoni
--
contact me at public(a)[mysurname].eu
13 years, 4 months
Re: time to implement a 'yum' object in mock?
by Seth Vidal
On Mon, 2010-12-13 at 09:48 -0600, Clark Williams wrote:
> On Mon, 13 Dec 2010 10:33:52 -0500
> seth vidal <skvidal(a)fedoraproject.org> wrote:
>
> > On Sun, 2010-12-12 at 10:08 -0600, Clark Williams wrote:
> > > Seth,
> > >
> > > I was scanning BZ's for mock this weekend (yes, I occasionally do
> > > that) and saw the one (519258) where we fail due to the fact that we're
> > > scanning the output of yum and not correctly handling being in the
> > > German locale. I was wondering how much code would be involved in
> > > importing yum modules and making direct calls into the yum API?
> > >
> > > A quick look at the code in py/mock/backend.py shows that we only call
> > > yum with the following commands:
> > >
> > > install
> > > update
> > > resolvedep
> > > groupinstall
> > >
> > > It's the resolvedep command that's failing, so it's possible that all
> > > we really need to do is create a function that correctly resolves
> > > dependencies without depending on any particular output.
> > >
> > > Thoughts?
> >
> >
> > Once you get the yum object setup to talk to the chroot it should be
> > easy to do the rest. The only question I have is if there is any selinux
> > reason to not have mock do it b/c of the capabilities yum is afforded?
> >
> > -sv
> >
> >
>
> I'm not sure I parsed that question correctly. With the selinux plugin
> enabled, mock sets up the chroot so that selinux is "disabled" inside
> it, regardless of the state of selinux on the actual host running mock.
okay - if it is disabled that's fine - my main concern was making sure
no labeling the yum executable has was going to impact things if mock
was calling it directly.
> The reason I am pondering directly accessing yum is that currently we
> parse the output of the resolvedep command and string processing is
> notoriously fragile once you leave the C locale. If we just make calls
> into yum and get back objects representing the missing dependencies
> (rather than parsing yum output as we do now) we side-step all the
> locale issues.
it gets rid of MOST locale issues - but it hands you more of the bizarro
unicode issues :(. I would recommend making sure you enforce locale=C if
you're going to use yum as a module to minimize unicodedecode
tracebacks.
The other thing that might be worth considering is using yum as an cli
interface for the install/update calls but use the api for resolvedep.
The only reason is resolvedep doesn't have much in the way of a callback
so it is easy - the callback for install/update is a bit more involved
if you want quasi-useful feedback in the mock log.
-sv
13 years, 4 months
Re: time to implement a 'yum' object in mock?
by Seth Vidal
On Sun, 2010-12-12 at 10:08 -0600, Clark Williams wrote:
> Seth,
>
> I was scanning BZ's for mock this weekend (yes, I occasionally do
> that) and saw the one (519258) where we fail due to the fact that we're
> scanning the output of yum and not correctly handling being in the
> German locale. I was wondering how much code would be involved in
> importing yum modules and making direct calls into the yum API?
>
> A quick look at the code in py/mock/backend.py shows that we only call
> yum with the following commands:
>
> install
> update
> resolvedep
> groupinstall
>
> It's the resolvedep command that's failing, so it's possible that all
> we really need to do is create a function that correctly resolves
> dependencies without depending on any particular output.
>
> Thoughts?
Once you get the yum object setup to talk to the chroot it should be
easy to do the rest. The only question I have is if there is any selinux
reason to not have mock do it b/c of the capabilities yum is afforded?
-sv
13 years, 4 months
Private Koji instance with private SCM: Make sources? Private lookaside?
by Anthony Joseph Messina
I have have used Git for my RPM sources, patches, specs, etc. for some
time and have just recently installed Koji. I am able to build from
SRPM (since I'm the admin), but I'd like to connect my Koji instance to
the git scm.
I am currently using the following in kojid.conf:
allowed_scms=messinet.com:/rpms/*:no pkgs.fedoraproject.org:/*:no
When I do this, koji/mock successfully gets the patches and spec file,
but the "Make sources" command doesn't get any of the tar.gz sources.
1) What is the output of the Make sources command (what does it do)?
2) How do I specify a private lookaside cache, similar to what is used
in Fedora?
3) If there is no way to specify a place to get the source tar.gz files,
and I were to create a custom command (rather than Make sources), can I
simply tell it to curl/wget the sources?
Thank you for your help. -A
--
Anthony - http://messinet.com - http://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E
13 years, 4 months
[PATCH] Ticket #41 add --lines= and --tail to watch-logs
by Patrick Wong
I was interested in participating in an open source project, and I happened
to come across Koji while looking around. To get myself started, I decided
to look at the active tickets and fix one of them. In this case, Ticket #41
add --lines= and --tail to watch-logs. I am pretty new to this, so I picked
something a little easier. Attached is my patch. If you have any suggestions
for improvements I would be very appreciative of it.
- Patrick
13 years, 4 months
[PATCH] Add s390 as legal target arch
by Dan Horák
s390 is legal target architecture in Fedora/s390x
---
py/mock.py | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/py/mock.py b/py/mock.py
index 7957a05..911407e 100755
--- a/py/mock.py
+++ b/py/mock.py
@@ -383,7 +383,7 @@ legal_arches = {
'ppc64' : ('ppc', 'ppc64'),
'sparc' : ('sparc'),
'sparc64': ('sparc', 'sparc64'),
- 's390x' : ('s390x'),
+ 's390x' : ('s390', 's390x'),
}
decorate(traceLog())
--
1.7.3.2
13 years, 4 months