The following patch is adding support for PAM authentication for the
koji-hub and BasicAuth for the koji-web.
This is useful for our internal use case as it allows us to login without
the overhead of setting up either a CA or a kerberos realm for our users.
The configuration is backwards compatible and hopefully similar to the
other authntication methods.
To active PAM support on hub you define the option:
PAMService = koji
in hub.conf. The value will be the name of the PAM service. Note the call
to the PAM module is done via unpriviledged call thus the use of pam_unix
won't be possible.
Note that activating this option will have as result that username/password
combinations from the DB will no longer be checked (similarly to when
activating kerberos or SSL client auth).
The BasicAuth for koji-web requires 2 changes:
a) To enable WSGIPassAuthorization for /koji/login in httpd configuration.
That passes the authorization variable from the apache to the application.
b) Set the "BasicAuthRealm" option to the Basic Authentication Realm that
will be presented to the user to login.
Finally python-pam package has been added to the hub's dependencies.
Christos Triantafyllidis (1):
- Added PAM support for hub - Added BasicAuth support for web
hub/hub.conf | 4 +++-
hub/kojixmlrpc.py | 2 ++
koji.spec | 1 +
koji/auth.py | 33 +++++++++++++++++++++++++--------
koji/server.py | 2 ++
www/conf/kojiweb.conf | 5 +++++
www/conf/web.conf | 3 +++
www/kojiweb/index.py | 18 +++++++++++++++++-
www/kojiweb/wsgi_publisher.py | 9 +++++++--
9 files changed, 65 insertions(+), 12 deletions(-)
Quick question, would you consider to use mergerepo_c with option
--all  in koji ?
I am happy to work on a patch if it would be accepted. Maybe, we can
keep default behavior and enable with an option on the tag.
My use case is to be able to ship different release built against fix
external repo package that may not be latest version
(Buildrequires:pkg = 1.0.0 while external repo has already 1.1.0)
Include all packages with the same name and arch if version or
release is different. If used --method argument is ignored!
I would like to ask what is current status of migrating Koji to use DNF for building?
I am mainly interested whether Koji will use DNF for building F23 packages, or you postpone it for F24?
Because in such case I would revert fedora-23-*.cfg default configs in Mock to use Yum so Mock is on pair with Koji.
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
Handle "repo --gpgkey" in kickstart to verify downloaded packages
Especially important for lorax and livecd-tools - those packages will
not verified in any way without setting yum options here.
pungi/gather.py | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
This depends on "repo --gpgkey" pykickstart patch here:
If possible, I'd like to have it also in 3.x branch. Cherry-pick works
just fine (there was a file name change, only that).
diff --git a/pungi/gather.py b/pungi/gather.py
index bcc2861..a5c9df9 100644
@@ -281,7 +281,7 @@ class Pungi(PungiBase):
def _add_yum_repo(self, name, url, mirrorlist=False, groups=True,
cost=1000, includepkgs=None, excludepkgs=None,
+ proxy=None, gpgkey=None):
"""This function adds a repo to the yum object.
name: Name of the repo
url: Full url to the repo
@@ -318,6 +318,10 @@ class Pungi(PungiBase):
thisrepo.exclude = excludepkgs
thisrepo.includepkgs = includepkgs
thisrepo.cost = cost
+ if gpgkey:
+ thisrepo.gpgcheck = True
+ thisrepo.gpgkey = yum.parser.varReplace(gpgkey,
# Yum doesn't like proxy being None
thisrepo.proxy = proxy
@@ -349,6 +353,7 @@ class Pungi(PungiBase):
yumconf.installroot = os.path.join(self.workdir, 'yumroot')
yumconf.uid = os.geteuid()
yumconf.cache = 0
+ yumconf.assumeyes = True
yumconf.failovermethod = 'priority'
yumconf.deltarpm = 0
yumvars = yum.config._getEnvVar()
@@ -379,7 +384,8 @@ class Pungi(PungiBase):
@@ -387,7 +393,8 @@ class Pungi(PungiBase):
self.logger.info('Getting sacks for arches %s' % self.valid_arches)
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
The other day someone suggested that mock should dynamically create
configs from a set of templates, so that we wouldn't have to keep
delivering and deleting a series of config files each time a new Fedora
release goes out. Not sure who it was since I can't find the discussion
in my IRC logs, but might have been dgilmore. Nirik? Don't know...
Anyway, I started thinking about it and it seems doable. Right now
configs are named with three fields:
We could come up with templates for distro-arch that would be used to
generate a config. The idea is someone invokes mock with this command
$ mock -r fedora-73-x86_64 --init
We go look in /etc/mock and find no fedora-73-x86_64.cfg, so we go
grab /etc/mock/template/fedora-x86_64 and substitute in '73' for the
release number, then write /etc/mock/fedora-73-x86_64.cfg. Then we
continue on our way, at least until the build fails due to non-existant
repositories (presuming that we're not talking about the year 2035
Obviously you could fat-finger the release number and generate a bogus
config file. Worse you might want to be using F22 but mis-type '21' and
use a wrong, but existent config. Also, I don't really like the idea of
dynamically creating files in /etc, so we might need to move the
created configs off to a /var/mock/configs directory or something like
The upside though is that we could stop having to add and delete
configs when new Fedora releases come out.
What do you guys think?