[Freeipa-devel] [freeipa PR#1630][opened] [testing_rawhide] Nightly PR
URL: https://github.com/freeipa/freeipa/pull/1630
Author: freeipa-pr-ci
Title: #1630: [testing_rawhide] Nightly PR
Action: opened
PR body:
"""
None
"""
To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/1630/head:pr1630
git checkout pr1630
From 61a59368a09fa2d3de7971d2e855ed82e3d728c6 Mon Sep 17 00:00:00 2001
From: root
Date: Sat, 24 Feb 2018 02:23:03 +
Subject: [PATCH] automated commit
---
.freeipa-pr-ci.yaml | 256 ++--
1 file changed, 246 insertions(+), 10 deletions(-)
diff --git a/.freeipa-pr-ci.yaml b/.freeipa-pr-ci.yaml
index cc4e1ddd1f..0e88145873 100644
--- a/.freeipa-pr-ci.yaml
+++ b/.freeipa-pr-ci.yaml
@@ -15,9 +15,17 @@ topologies:
name: ipaserver
cpu: 1
memory: 2400
+ master_2repl_1client: &master_2repl_1client
+name: master_2repl_1client
+cpu: 5
+memory: 9100
+ master_3repl_1client: &master_3repl_1client
+name: master_3repl_1client
+cpu: 6
+memory: 11500
jobs:
- fedora-27/build:
+ fedora-rawhide/build:
requires: []
priority: 100
job:
@@ -25,20 +33,248 @@ jobs:
args:
git_repo: '{git_repo}'
git_refspec: '{git_refspec}'
-template: &ci-master-f27
- name: freeipa/ci-master-f27
- version: 1.0.3
+template: &ci-master-frawhide
+ name: freeipa/ci-master-frawhide
+ version: 0.0.4
timeout: 1800
topology: *build
- fedora-27/webui_tests:
-requires: [fedora-27/build]
+ fedora-rawhide/test_server_del:
+requires: [fedora-rawhide/build]
+priority: 50
+job:
+ class: RunPytest
+ args:
+build_url: '{fedora-rawhide/build_url}'
+test_suite: test_integration/test_server_del.py
+template: *ci-master-frawhide
+timeout: 8000
+topology: *master_2repl_1client
+
+ fedora-rawhide/test_installation:
+requires: [fedora-rawhide/build]
+priority: 50
+job:
+ class: RunPytest
+ args:
+build_url: '{fedora-rawhide/build_url}'
+test_suite: test_integration/test_installation.py
+template: *ci-master-frawhide
+timeout: 18000
+topology: *master_3repl_1client
+
+ fedora-rawhide/TestServerInstall:
+requires: [fedora-rawhide/build]
+priority: 50
+job:
+ class: RunPytest
+ args:
+build_url: '{fedora-rawhide/build_url}'
+test_suite: test_integration/test_caless.py::TestServerInstall
+template: *ci-master-frawhide
+timeout: 12000
+topology: *master_1repl
+
+ fedora-rawhide/TestReplicaInstall:
+requires: [fedora-rawhide/build]
+priority: 50
+job:
+ class: RunPytest
+ args:
+build_url: '{fedora-rawhide/build_url}'
+test_suite: test_integration/test_caless.py::TestReplicaInstall
+template: *ci-master-frawhide
+timeout: 5400
+topology: *master_1repl
+
+ fedora-rawhide/TestClientInstall:
+requires: [fedora-rawhide/build]
+priority: 50
+job:
+ class: RunPytest
+ args:
+build_url: '{fedora-rawhide/build_url}'
+test_suite: test_integration/test_caless.py::TestClientInstall
+template: *ci-master-frawhide
+timeout: 5400
+topology: *master_1repl
+
+ fedora-rawhide/TestIPACommands:
+requires: [fedora-rawhide/build]
+priority: 50
+job:
+ class: RunPytest
+ args:
+build_url: '{fedora-rawhide/build_url}'
+test_suite: test_integration/test_caless.py::TestIPACommands
+template: *ci-master-frawhide
+timeout: 5400
+topology: *master_1repl
+
+ fedora-rawhide/TestCertInstall:
+requires: [fedora-rawhide/build]
+priority: 50
+job:
+ class: RunPytest
+ args:
+build_url: '{fedora-rawhide/build_url}'
+test_suite: test_integration/test_caless.py::TestCertInstall
+template: *ci-master-frawhide
+timeout: 5400
+topology: *master_1repl
+
+ fedora-rawhide/TestPKINIT:
+requires: [fedora-rawhide/build]
+priority: 50
+job:
+ class: RunPytest
+ args:
+build_url: '{fedora-rawhide/build_url}'
+test_suite: test_integration/test_caless.py::TestPKINIT
+template: *ci-master-frawhide
+timeout: 5400
+topology: *master_1repl
+
+ fedora-rawhide/TestServerReplicaCALessToCAFull:
+requires: [fedora-rawhide/build]
+priority: 50
+job:
+ class: RunPytest
+ args:
+build_url: '{fedora-rawhide/build_url}'
+test_suite: test_integration/test_caless.py::TestServerReplicaCALessToCAFull
+template: *ci-master-frawhide
+timeout: 5400
+topology: *master_1repl
+
+ fedora-rawhide/TestBackupAndRestore:
+requires: [fedora-rawhide/build]
+priority: 50
+job:
+ class: RunPytest
+ args:
+build_url: '{fedora-rawhide/build_url}'
+test
[Freeipa-devel] [freeipa PR#1624][closed] [testing_rawhide] Nightly PR
URL: https://github.com/freeipa/freeipa/pull/1624 Author: freeipa-pr-ci Title: #1624: [testing_rawhide] Nightly PR Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/1624/head:pr1624 git checkout pr1624 ___ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
[Freeipa-devel] [freeipa PR#1629][opened] [testing_master] Nightly PR
URL: https://github.com/freeipa/freeipa/pull/1629
Author: freeipa-pr-ci
Title: #1629: [testing_master] Nightly PR
Action: opened
PR body:
"""
None
"""
To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/1629/head:pr1629
git checkout pr1629
From fca7baef7431bc46c7b7c44f24f8f1ccf6e14484 Mon Sep 17 00:00:00 2001
From: root
Date: Fri, 23 Feb 2018 23:00:07 +
Subject: [PATCH] automated commit
---
.freeipa-pr-ci.yaml | 244 +++-
1 file changed, 240 insertions(+), 4 deletions(-)
diff --git a/.freeipa-pr-ci.yaml b/.freeipa-pr-ci.yaml
index cc4e1ddd1f..d77d8d8273 100644
--- a/.freeipa-pr-ci.yaml
+++ b/.freeipa-pr-ci.yaml
@@ -15,6 +15,14 @@ topologies:
name: ipaserver
cpu: 1
memory: 2400
+ master_2repl_1client: &master_2repl_1client
+name: master_2repl_1client
+cpu: 5
+memory: 9100
+ master_3repl_1client: &master_3repl_1client
+name: master_3repl_1client
+cpu: 6
+memory: 11500
jobs:
fedora-27/build:
@@ -31,14 +39,242 @@ jobs:
timeout: 1800
topology: *build
- fedora-27/webui_tests:
+ fedora-27/test_server_del:
requires: [fedora-27/build]
priority: 50
job:
- class: RunWebuiTests
+ class: RunPytest
args:
build_url: '{fedora-27/build_url}'
-test_suite: test_webui/test_realmdomains.py test_webui/test_dns.py
+test_suite: test_integration/test_server_del.py
template: *ci-master-f27
timeout: 8000
-topology: *ipaserver
\ No newline at end of file
+topology: *master_2repl_1client
+
+ fedora-27/test_installation:
+requires: [fedora-27/build]
+priority: 50
+job:
+ class: RunPytest
+ args:
+build_url: '{fedora-27/build_url}'
+test_suite: test_integration/test_installation.py
+template: *ci-master-f27
+timeout: 10800
+topology: *master_3repl_1client
+
+ fedora-27/TestServerInstall:
+requires: [fedora-27/build]
+priority: 50
+job:
+ class: RunPytest
+ args:
+build_url: '{fedora-27/build_url}'
+test_suite: test_integration/test_caless.py::TestServerInstall
+template: *ci-master-f27
+timeout: 12000
+topology: *master_1repl
+
+ fedora-27/TestReplicaInstall:
+requires: [fedora-27/build]
+priority: 50
+job:
+ class: RunPytest
+ args:
+build_url: '{fedora-27/build_url}'
+test_suite: test_integration/test_caless.py::TestReplicaInstall
+template: *ci-master-f27
+timeout: 5400
+topology: *master_1repl
+
+ fedora-27/TestClientInstall:
+requires: [fedora-27/build]
+priority: 50
+job:
+ class: RunPytest
+ args:
+build_url: '{fedora-27/build_url}'
+test_suite: test_integration/test_caless.py::TestClientInstall
+template: *ci-master-f27
+timeout: 5400
+topology: *master_1repl
+
+ fedora-27/TestIPACommands:
+requires: [fedora-27/build]
+priority: 50
+job:
+ class: RunPytest
+ args:
+build_url: '{fedora-27/build_url}'
+test_suite: test_integration/test_caless.py::TestIPACommands
+template: *ci-master-f27
+timeout: 5400
+topology: *master_1repl
+
+ fedora-27/TestCertInstall:
+requires: [fedora-27/build]
+priority: 50
+job:
+ class: RunPytest
+ args:
+build_url: '{fedora-27/build_url}'
+test_suite: test_integration/test_caless.py::TestCertInstall
+template: *ci-master-f27
+timeout: 5400
+topology: *master_1repl
+
+ fedora-27/TestPKINIT:
+requires: [fedora-27/build]
+priority: 50
+job:
+ class: RunPytest
+ args:
+build_url: '{fedora-27/build_url}'
+test_suite: test_integration/test_caless.py::TestPKINIT
+template: *ci-master-f27
+timeout: 5400
+topology: *master_1repl
+
+ fedora-27/TestServerReplicaCALessToCAFull:
+requires: [fedora-27/build]
+priority: 50
+job:
+ class: RunPytest
+ args:
+build_url: '{fedora-27/build_url}'
+test_suite: test_integration/test_caless.py::TestServerReplicaCALessToCAFull
+template: *ci-master-f27
+timeout: 5400
+topology: *master_1repl
+
+ fedora-27/TestBackupAndRestore:
+requires: [fedora-27/build]
+priority: 50
+job:
+ class: RunPytest
+ args:
+build_url: '{fedora-27/build_url}'
+test_suite: test_integration/test_backup_and_restore.py::TestBackupAndRestore
+template: *ci-master-f27
+timeout: 7200
+topology: *master_1repl
+
+ fedora-27/TestBackupAndRestoreWithDNS:
+requires: [fedora-27/build]
+priority: 50
+job:
+ class: RunPytest
+ args:
+build_url: '{fedora-27/build_url}'
+test_suite: test_integration/test_backup_and_restore.py::TestBackupAndRe
[Freeipa-devel] [freeipa PR#1623][closed] [testing_master] Nightly PR
URL: https://github.com/freeipa/freeipa/pull/1623 Author: freeipa-pr-ci Title: #1623: [testing_master] Nightly PR Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/1623/head:pr1623 git checkout pr1623 ___ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
[Freeipa-devel] Re: FreeIPA nightly tests as PRs
Petr Vobornik via FreeIPA-devel writes: > Felipe made nightly testing working as PRs in freeipa main Git Hub > repo. Is there really not a better way to do this than spamming freeipa-devel with two more PRs every day? Travis has cronjob support; wouldn't this be a better fit there? Why does it need to be a PR? Like I suspect many users, I will be muting these. Thanks, --Robbie signature.asc Description: PGP signature ___ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
[Freeipa-devel] [freeipa PR#1628][opened] [Backport][ipa-4-6] ipa host-add: do not raise exception when reverse record not added
URL: https://github.com/freeipa/freeipa/pull/1628
Author: tiran
Title: #1628: [Backport][ipa-4-6] ipa host-add: do not raise exception when
reverse record not added
Action: opened
PR body:
"""
This PR was opened automatically because PR #1521 was pushed to master and
backport to ipa-4-6 is required.
"""
To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/1628/head:pr1628
git checkout pr1628
From 6f8f60801e05b227e05ab557f10301d6a25fbe03 Mon Sep 17 00:00:00 2001
From: Florence Blanc-Renaud
Date: Tue, 30 Jan 2018 12:49:35 +0100
Subject: [PATCH] ipa host-add: do not raise exception when reverse record not
added
When ipa host-add --random is unable to add a reverse record (for instance
because the server does not manage any reverse zone), the command
adds the host but exits (return code=1) with an error without actually
outputing the random password generated.
With this fix, the behavior is modified. The commands succeeds (return code=0)
but prints a warning.
This commit also adds a unit test.
https://pagure.io/freeipa/issue/7374
---
ipalib/messages.py | 11 +
ipaserver/plugins/host.py| 10 +++-
ipatests/test_xmlrpc/test_host_plugin.py | 42 ++--
3 files changed, 49 insertions(+), 14 deletions(-)
diff --git a/ipalib/messages.py b/ipalib/messages.py
index 2e44da3a27..9e2c990d6d 100644
--- a/ipalib/messages.py
+++ b/ipalib/messages.py
@@ -476,6 +476,17 @@ class CertificateInvalid(PublicMessage):
"%(reason)s")
+class FailedToAddHostDNSRecords(PublicMessage):
+"""
+**13030** Failed to add host DNS records
+"""
+
+errno = 13030
+type = "warning"
+format = _("The host was added but the DNS update failed with: "
+ "%(reason)s")
+
+
def iter_messages(variables, base):
"""Return a tuple with all subclasses
"""
diff --git a/ipaserver/plugins/host.py b/ipaserver/plugins/host.py
index 291a90a2ab..306105d67a 100644
--- a/ipaserver/plugins/host.py
+++ b/ipaserver/plugins/host.py
@@ -700,7 +700,6 @@ def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options):
def post_callback(self, ldap, dn, entry_attrs, *keys, **options):
assert isinstance(dn, DN)
-exc = None
if dns_container_exists(ldap):
try:
parts = keys[-1].split('.')
@@ -719,18 +718,15 @@ def post_callback(self, ldap, dn, entry_attrs, *keys, **options):
update_sshfp_record(domain, unicode(parts[0]), entry_attrs)
except Exception as e:
-exc = e
+self.add_message(messages.FailedToAddHostDNSRecords(reason=e))
if options.get('random', False):
try:
-entry_attrs['randompassword'] = unicode(getattr(context, 'randompassword'))
+entry_attrs['randompassword'] = unicode(
+getattr(context, 'randompassword'))
except AttributeError:
# On the off-chance some other extension deletes this from the
# context, don't crash.
pass
-if exc:
-raise errors.NonFatalError(
-reason=_('The host was added but the DNS update failed with: %(exc)s') % dict(exc=exc)
-)
set_certificate_attrs(entry_attrs)
set_kerberos_attrs(entry_attrs, options)
rename_ipaallowedtoperform_from_ldap(entry_attrs, options)
diff --git a/ipatests/test_xmlrpc/test_host_plugin.py b/ipatests/test_xmlrpc/test_host_plugin.py
index 0acb6cf100..50b1cf6659 100644
--- a/ipatests/test_xmlrpc/test_host_plugin.py
+++ b/ipatests/test_xmlrpc/test_host_plugin.py
@@ -31,7 +31,7 @@
import pytest
from ipapython import ipautil
-from ipalib import api, errors
+from ipalib import api, errors, messages
from ipapython.dn import DN
from ipapython.dnsutil import DNSName
from ipatests.test_util import yield_fixture
@@ -646,11 +646,13 @@ def test_create_host_with_ip(self, dns_setup_nonameserver, host4):
"""
try:
command = host4.make_create_command()
-with raises_exact(errors.NonFatalError(
-reason=u'The host was added but the DNS update failed with'
-': All nameservers failed to answer the query for DNS '
-'reverse zone %s' % missingrevzone)):
-command(ip_address=ipv4_in_missingrevzone_ip)
+result = command(ip_address=ipv4_in_missingrevzone_ip)
+msg = result['messages'][0]
+assert msg['code'] == messages.FailedToAddHostDNSRecords.errno
+expected_msg = ("The host was added but the DNS update failed "
+"with: All nameservers failed to answer the query "
+"for DNS reverse zone {}").format(missingrevzone)
+assert msg['message'] == expected_msg
[Freeipa-devel] [freeipa PR#1521][closed] ipa host-add: do not raise exception when reverse record not added
URL: https://github.com/freeipa/freeipa/pull/1521 Author: flo-renaud Title: #1521: ipa host-add: do not raise exception when reverse record not added Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/1521/head:pr1521 git checkout pr1521 ___ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
[Freeipa-devel] [freeipa PR#1626][closed] Silence some GCC warnings
URL: https://github.com/freeipa/freeipa/pull/1626 Author: tiran Title: #1626: Silence some GCC warnings Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/1626/head:pr1626 git checkout pr1626 ___ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
[Freeipa-devel] Re: FreeIPA nightly tests as PRs
On pe, 23 helmi 2018, Rob Crittenden via FreeIPA-devel wrote: Alexander Bokovoy via FreeIPA-devel wrote: On pe, 23 helmi 2018, Petr Vobornik via FreeIPA-devel wrote: Hi all, Felipe made nightly testing working as PRs in freeipa main Git Hub repo. e.g.: https://github.com/freeipa/freeipa/pull/1624 https://github.com/freeipa/freeipa/pull/1623 This is good. We can see the results publicly in comparison to "upstream Jenkins". I also believe that it will be more stable. But time will tell it. A disadvantage is more noise in mail notifications, but that is not that drastic. Let's discuss some aspects. First one is definitions of the tests (.freeipa-pr-ci.yaml) and how to extend them. We currently use 3 definitions: * gating, the definition in repo * nightly master tests * nighly rawhide tests Gating definition is in repo. But both nightly are not. What is the way how other team members can extend this definition? Where are they kept? Could we also put them into a repo? Yes, we can put them in the repo. What about the following solution: 1. create a directory with tests definitions, e.g. /ipatests/definitions 2. put these 3 files there - gating - nightly_master - nightly_rawhide 3. make .freeipa-pr-ci.yaml a symlink to /ipatest/definitions/gating 4. for nightly testing do PR which would change only the symlink Benefits: - anybody can extend nightly test suite - the nighlty test suite can be extended right away in a PR which adds the tests - nightly tests won't fail on merge conflict when somebody extends current gating spec Possible alternative is to make it more complex and use something like includes instead of symlinks, but that would need update of PR-CI and I don't see a real benefit in comparison to the symlink solution. I think symlink approach should be fine (relative symlink, that is). How would the symlinks work with concurrency? What concurrency? A PR CI run is: - git checkout of the pull request - run things in the checkout There are no concurrent runners with different test definitions for the same test run checkout. What does a nightly/rawhide PR look like? Is that a one-off or something that would be scheduled? Here are the changes from the current run: https://github.com/freeipa/freeipa/pull/1624/files Even in this state a simple sequence of - rebase against master - push the rebase to PR1624 performed nightly would cause this PR to re-run. So, yes, someone needs to schedule this periodic rebase but that's all. -- / Alexander Bokovoy ___ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
[Freeipa-devel] [freeipa PR#1627][opened] [Backport][ipa-4-6] Don't return None on mismatched interactive passwords
URL: https://github.com/freeipa/freeipa/pull/1627
Author: tiran
Title: #1627: [Backport][ipa-4-6] Don't return None on mismatched interactive
passwords
Action: opened
PR body:
"""
This PR was opened automatically because PR #1622 was pushed to master and
backport to ipa-4-6 is required.
"""
To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/1627/head:pr1627
git checkout pr1627
From 3a07fe3e260c2ee33109a98862007d32303990c3 Mon Sep 17 00:00:00 2001
From: Rob Crittenden
Date: Thu, 22 Feb 2018 13:49:43 -0500
Subject: [PATCH] Don't return None on mismatched interactive passwords
This will cause the command to continue with no password set
at all which is not what we want.
We want to loop forever until the passwords match or the
user gives up and types ^D or ^C.
https://pagure.io/freeipa/issue/7383
Signed-off-by: Rob Crittenden
---
ipalib/cli.py | 1 -
1 file changed, 1 deletion(-)
diff --git a/ipalib/cli.py b/ipalib/cli.py
index 2da641046f..3fde581974 100644
--- a/ipalib/cli.py
+++ b/ipalib/cli.py
@@ -627,7 +627,6 @@ def prompt_password(self, label, confirm=True):
return pw1
else:
self.print_error(_('Passwords do not match!'))
-return None
else:
return self.decode(sys.stdin.readline().strip())
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
[Freeipa-devel] [freeipa PR#1622][closed] Don't return None on mismatched interactive passwords
URL: https://github.com/freeipa/freeipa/pull/1622 Author: rcritten Title: #1622: Don't return None on mismatched interactive passwords Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/1622/head:pr1622 git checkout pr1622 ___ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
[Freeipa-devel] Re: FreeIPA nightly tests as PRs
Alexander Bokovoy via FreeIPA-devel wrote: > On pe, 23 helmi 2018, Petr Vobornik via FreeIPA-devel wrote: >> Hi all, >> >> Felipe made nightly testing working as PRs in freeipa main Git Hub repo. >> >> e.g.: >> https://github.com/freeipa/freeipa/pull/1624 >> https://github.com/freeipa/freeipa/pull/1623 >> >> This is good. We can see the results publicly in comparison to >> "upstream Jenkins". I also believe that it will be more stable. But >> time will tell it. A disadvantage is more noise in mail notifications, >> but that is not that drastic. >> >> Let's discuss some aspects. First one is definitions of the tests >> (.freeipa-pr-ci.yaml) and how to extend them. >> >> We currently use 3 definitions: >> * gating, the definition in repo >> * nightly master tests >> * nighly rawhide tests >> >> Gating definition is in repo. But both nightly are not. >> >> What is the way how other team members can extend this definition? >> Where are they kept? >> >> Could we also put them into a repo? > Yes, we can put them in the repo. > >> >> What about the following solution: >> 1. create a directory with tests definitions, e.g. /ipatests/definitions >> 2. put these 3 files there >> - gating >> - nightly_master >> - nightly_rawhide >> 3. make .freeipa-pr-ci.yaml a symlink to /ipatest/definitions/gating >> 4. for nightly testing do PR which would change only the symlink >> >> Benefits: >> - anybody can extend nightly test suite >> - the nighlty test suite can be extended right away in a PR which adds >> the tests >> - nightly tests won't fail on merge conflict when somebody extends >> current gating spec >> >> Possible alternative is to make it more complex and use something like >> includes instead of symlinks, but that would need update of PR-CI and >> I don't see a real benefit in comparison to the symlink solution. > I think symlink approach should be fine (relative symlink, that is). > How would the symlinks work with concurrency? What does a nightly/rawhide PR look like? Is that a one-off or something that would be scheduled? rob ___ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
[Freeipa-devel] Re: authconfig replacement design
On 02/23/2018 01:53 PM, Martin Kosek wrote: On 02/23/2018 01:45 PM, Pavel Březina wrote: On 02/23/2018 01:29 PM, Martin Kosek wrote: On 02/23/2018 01:25 PM, Alexander Bokovoy wrote: On pe, 23 helmi 2018, Pavel Březina via FreeIPA-devel wrote: On 02/23/2018 12:57 PM, Martin Kosek wrote: On 02/21/2018 10:25 AM, Pavel Březina via FreeIPA-devel wrote: couple of scenarious here: - install server install it and configure with authselect. there is no --no-sssd option for the server installation - upgrade server bakup authselect configuration. apply authselect sssd profile overwriting what was there before. Why do you call authselect during server update? Shouldn't the system be already configured? In FreeIPA server, we want to make sure that authselect profile is activated, so that this FreeIPA server's PAM stack receives further updates in case the authselect profile gets some fixes in. If it still has the manual PAM configuration via old authconfig, it would not receive such updates. Is that true? It is true. But the same applies currently with authconfig. So if authconfig is run again during server update than sure, it should be there. We do not run authconfig on each server upgrade. An idea to re-write configuration every upgrade sounds interesting but I don't think we are close to get it properly implemented before we switch to Ansible installer... I think that here I was thinking more about one-off upgrade, as part of authconfig->authselect migration. My assumption was that authselect would then take care of updating the PAM configuration if template changes. We explicitly said in F28 change page that existing configuration will not be changed if user is upgrading from lower fedora version, unless authconfig(compat)/authselect is run after the upgrade. And this looks as a safe thing to do on a general Fedora workstation. However, when that workstation is either a FreeIPA Client or FreeIPA Server, I would think that we want to update to the latest, greatest, maintained PAM stack - i.e. authselect. So we could do this when updating ipa server, however I don't think it is desirable to automatically change current configuration on an rpm update in F28 if this is not what would happen with authconfig. I would not limit ourselves with what authconfig does. authselect works a bit differently, it uses static, tested PAM stack, instead of manual PAM stack changes. In this case, switching to this tested PAM stack for FreeIPA Server and Client in my mind links well to authselect goals - i.e. have these "tested stacks (profiles) that solve a use-case and are well tested and supported" (https://fedoraproject.org/wiki/Changes/Authselect) on as many Servers and Clients as possible and thus limiting Bugzillas about misconfigured PAM stack. Upgrade is the main concern here of course - how to detect a situation when administrator went beyond "authconfig --enable sssd" and actually did some manual PAM changes we would break during upgrade. That is what needs to be evaluated, for Client and Server. Yes, I agree that we want to switch to authselect. However changing configuration that went beyond authconfig --enable sssd is what makes me worried here. Pavel, did we work out the upgrade story of authselect, for the cases when we need to fix something in SSSD/winbind template? Or would it be admin's task to refresh the PAM stack when the template changes? There is no story written per say. But this should be handled by rpm during upgrade. You mean authselect rpm? Yes. If there are changes in shipped profiles, updating to newer version should update select profile (if it is one of these shipped profiles) on the system. ___ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
[Freeipa-devel] Re: authconfig replacement design
On 02/23/2018 01:45 PM, Pavel Březina wrote: > On 02/23/2018 01:29 PM, Martin Kosek wrote: >> On 02/23/2018 01:25 PM, Alexander Bokovoy wrote: >>> On pe, 23 helmi 2018, Pavel Březina via FreeIPA-devel wrote: On 02/23/2018 12:57 PM, Martin Kosek wrote: > On 02/21/2018 10:25 AM, Pavel Březina via FreeIPA-devel wrote: >>> >>> >>> couple of scenarious here: >>> - install server >>> install it and configure with authselect. there is no --no-sssd >>> option >>> for the server installation >>> - upgrade server >>> bakup authselect configuration. apply authselect sssd profile >>> overwriting what was there before. >> >> Why do you call authselect during server update? Shouldn't the >> system be >> already configured? > > In FreeIPA server, we want to make sure that authselect profile is > activated, so that this FreeIPA server's PAM stack receives further > updates in case the authselect profile gets some fixes in. If it still > has the manual PAM configuration via old authconfig, it would not > receive such updates. Is that true? It is true. But the same applies currently with authconfig. So if authconfig is run again during server update than sure, it should be there. >>> We do not run authconfig on each server upgrade. An idea to re-write >>> configuration every upgrade sounds interesting but I don't think we are >>> close to get it properly implemented before we switch to Ansible >>> installer... >> >> I think that here I was thinking more about one-off upgrade, as part of >> authconfig->authselect migration. My assumption was that authselect >> would then take care of updating the PAM configuration if template >> changes. > > We explicitly said in F28 change page that existing configuration will > not be changed if user is upgrading from lower fedora version, unless > authconfig(compat)/authselect is run after the upgrade. And this looks as a safe thing to do on a general Fedora workstation. However, when that workstation is either a FreeIPA Client or FreeIPA Server, I would think that we want to update to the latest, greatest, maintained PAM stack - i.e. authselect. > So we could do > this when updating ipa server, however I don't think it is desirable to > automatically change current configuration on an rpm update in F28 if > this is not what would happen with authconfig. I would not limit ourselves with what authconfig does. authselect works a bit differently, it uses static, tested PAM stack, instead of manual PAM stack changes. In this case, switching to this tested PAM stack for FreeIPA Server and Client in my mind links well to authselect goals - i.e. have these "tested stacks (profiles) that solve a use-case and are well tested and supported" (https://fedoraproject.org/wiki/Changes/Authselect) on as many Servers and Clients as possible and thus limiting Bugzillas about misconfigured PAM stack. Upgrade is the main concern here of course - how to detect a situation when administrator went beyond "authconfig --enable sssd" and actually did some manual PAM changes we would break during upgrade. That is what needs to be evaluated, for Client and Server. >> Pavel, did we work out the upgrade story of authselect, for the cases >> when we need to fix something in SSSD/winbind template? Or would it be >> admin's task to refresh the PAM stack when the template changes? > > There is no story written per say. But this should be handled by rpm > during upgrade. You mean authselect rpm? ___ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
[Freeipa-devel] Re: authconfig replacement design
On 02/23/2018 01:29 PM, Martin Kosek wrote: On 02/23/2018 01:25 PM, Alexander Bokovoy wrote: On pe, 23 helmi 2018, Pavel Březina via FreeIPA-devel wrote: On 02/23/2018 12:57 PM, Martin Kosek wrote: On 02/21/2018 10:25 AM, Pavel Březina via FreeIPA-devel wrote: couple of scenarious here: - install server install it and configure with authselect. there is no --no-sssd option for the server installation - upgrade server bakup authselect configuration. apply authselect sssd profile overwriting what was there before. Why do you call authselect during server update? Shouldn't the system be already configured? In FreeIPA server, we want to make sure that authselect profile is activated, so that this FreeIPA server's PAM stack receives further updates in case the authselect profile gets some fixes in. If it still has the manual PAM configuration via old authconfig, it would not receive such updates. Is that true? It is true. But the same applies currently with authconfig. So if authconfig is run again during server update than sure, it should be there. We do not run authconfig on each server upgrade. An idea to re-write configuration every upgrade sounds interesting but I don't think we are close to get it properly implemented before we switch to Ansible installer... I think that here I was thinking more about one-off upgrade, as part of authconfig->authselect migration. My assumption was that authselect would then take care of updating the PAM configuration if template changes. We explicitly said in F28 change page that existing configuration will not be changed if user is upgrading from lower fedora version, unless authconfig(compat)/authselect is run after the upgrade. So we could do this when updating ipa server, however I don't think it is desirable to automatically change current configuration on an rpm update in F28 if this is not what would happen with authconfig. Pavel, did we work out the upgrade story of authselect, for the cases when we need to fix something in SSSD/winbind template? Or would it be admin's task to refresh the PAM stack when the template changes? There is no story written per say. But this should be handled by rpm during upgrade. ___ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
[Freeipa-devel] Re: authconfig replacement design
On 02/23/2018 01:25 PM, Alexander Bokovoy wrote: > On pe, 23 helmi 2018, Pavel Březina via FreeIPA-devel wrote: >> On 02/23/2018 12:57 PM, Martin Kosek wrote: >>> On 02/21/2018 10:25 AM, Pavel Březina via FreeIPA-devel wrote: > > > couple of scenarious here: > - install server > install it and configure with authselect. there is no --no-sssd > option > for the server installation > - upgrade server > bakup authselect configuration. apply authselect sssd profile > overwriting what was there before. Why do you call authselect during server update? Shouldn't the system be already configured? >>> >>> In FreeIPA server, we want to make sure that authselect profile is >>> activated, so that this FreeIPA server's PAM stack receives further >>> updates in case the authselect profile gets some fixes in. If it still >>> has the manual PAM configuration via old authconfig, it would not >>> receive such updates. Is that true? >> >> It is true. But the same applies currently with authconfig. So if >> authconfig is run again during server update than sure, it should be >> there. > We do not run authconfig on each server upgrade. An idea to re-write > configuration every upgrade sounds interesting but I don't think we are > close to get it properly implemented before we switch to Ansible > installer... I think that here I was thinking more about one-off upgrade, as part of authconfig->authselect migration. My assumption was that authselect would then take care of updating the PAM configuration if template changes. Pavel, did we work out the upgrade story of authselect, for the cases when we need to fix something in SSSD/winbind template? Or would it be admin's task to refresh the PAM stack when the template changes? ___ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
[Freeipa-devel] Re: authconfig replacement design
On pe, 23 helmi 2018, Pavel Březina via FreeIPA-devel wrote: On 02/23/2018 12:57 PM, Martin Kosek wrote: On 02/21/2018 10:25 AM, Pavel Březina via FreeIPA-devel wrote: couple of scenarious here: - install server install it and configure with authselect. there is no --no-sssd option for the server installation - upgrade server bakup authselect configuration. apply authselect sssd profile overwriting what was there before. Why do you call authselect during server update? Shouldn't the system be already configured? In FreeIPA server, we want to make sure that authselect profile is activated, so that this FreeIPA server's PAM stack receives further updates in case the authselect profile gets some fixes in. If it still has the manual PAM configuration via old authconfig, it would not receive such updates. Is that true? It is true. But the same applies currently with authconfig. So if authconfig is run again during server update than sure, it should be there. We do not run authconfig on each server upgrade. An idea to re-write configuration every upgrade sounds interesting but I don't think we are close to get it properly implemented before we switch to Ansible installer... -- / Alexander Bokovoy ___ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
[Freeipa-devel] Re: FreeIPA nightly tests as PRs
On pe, 23 helmi 2018, Petr Vobornik via FreeIPA-devel wrote: Hi all, Felipe made nightly testing working as PRs in freeipa main Git Hub repo. e.g.: https://github.com/freeipa/freeipa/pull/1624 https://github.com/freeipa/freeipa/pull/1623 This is good. We can see the results publicly in comparison to "upstream Jenkins". I also believe that it will be more stable. But time will tell it. A disadvantage is more noise in mail notifications, but that is not that drastic. Let's discuss some aspects. First one is definitions of the tests (.freeipa-pr-ci.yaml) and how to extend them. We currently use 3 definitions: * gating, the definition in repo * nightly master tests * nighly rawhide tests Gating definition is in repo. But both nightly are not. What is the way how other team members can extend this definition? Where are they kept? Could we also put them into a repo? Yes, we can put them in the repo. What about the following solution: 1. create a directory with tests definitions, e.g. /ipatests/definitions 2. put these 3 files there - gating - nightly_master - nightly_rawhide 3. make .freeipa-pr-ci.yaml a symlink to /ipatest/definitions/gating 4. for nightly testing do PR which would change only the symlink Benefits: - anybody can extend nightly test suite - the nighlty test suite can be extended right away in a PR which adds the tests - nightly tests won't fail on merge conflict when somebody extends current gating spec Possible alternative is to make it more complex and use something like includes instead of symlinks, but that would need update of PR-CI and I don't see a real benefit in comparison to the symlink solution. I think symlink approach should be fine (relative symlink, that is). -- / Alexander Bokovoy ___ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
[Freeipa-devel] Re: authconfig replacement design
On 02/23/2018 12:57 PM, Martin Kosek wrote: On 02/21/2018 10:25 AM, Pavel Březina via FreeIPA-devel wrote: couple of scenarious here: - install server install it and configure with authselect. there is no --no-sssd option for the server installation - upgrade server bakup authselect configuration. apply authselect sssd profile overwriting what was there before. Why do you call authselect during server update? Shouldn't the system be already configured? In FreeIPA server, we want to make sure that authselect profile is activated, so that this FreeIPA server's PAM stack receives further updates in case the authselect profile gets some fixes in. If it still has the manual PAM configuration via old authconfig, it would not receive such updates. Is that true? It is true. But the same applies currently with authconfig. So if authconfig is run again during server update than sure, it should be there. - upgrade client not applicable. only new binaries are copied onto the system I would think that we want the same as on the FreeIPA server. I.e. if we detect that FreeIPA client is configured with SSSD, we switch to a supported authselect PAM stack and thus receive further updates, without being stuck with manual authconfig PAM stack. Martin ___ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
[Freeipa-devel] Re: authconfig replacement design
On 02/21/2018 03:39 PM, Rob Crittenden via FreeIPA-devel wrote: >>> - install client >>> a) if we replace rpm dependancy on authconfig with aushselect we can >>> go only this way: new installations done with authselect. if --no-sssd >>> option is provided, then fail. >> --no-sssd option is already deprecated and should not be used, you don't >> have to think about that scenario. You can therefore go the a) way and >> remove the option as a whole so that you can be sure it won't fiddle >> with new installations. > I can't seem to find anywhere that this deprecation was announced or > discussed other than the ticket and commit, > dfc271fdf4514481c11c342fabda135feeb44de6. > > Did anyone ask users, or anyone, if they use this option? > > In any case it isn't even clear that the option *is* deprecated. It just > doesn't show as an option to ipa-client -install (hiding is not > deprecating). > > IMHO to properly deprecate something it should yell loudly whenever > invoked with a dire warning that it will disappear in the future. This mostly seems as a review feedback that could have come in https://pagure.io/freeipa/issue/5860 but did not. But it does not change anything on the fact that the option is deprecated. > There is also no man page mention of deprecation, in fact the option is > still there. > > So even if the deprecation is fine and considered, removing the option > completely has had no visible discussion. Let's discuss it then. From Fedora/RHEL point of view, I do not see big value in spending much time in maintaining, supporting or developing non-SSSD scenarios. Fedora itself does not support these scenarios any more, after the authselect Fedora change. These very corner cases are left for manual administrator configuration. The non-SSSD work and code should be left to FreeIPA platform code, for platforms that do not use or want to use SSSD. ___ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
[Freeipa-devel] FreeIPA nightly tests as PRs
Hi all, Felipe made nightly testing working as PRs in freeipa main Git Hub repo. e.g.: https://github.com/freeipa/freeipa/pull/1624 https://github.com/freeipa/freeipa/pull/1623 This is good. We can see the results publicly in comparison to "upstream Jenkins". I also believe that it will be more stable. But time will tell it. A disadvantage is more noise in mail notifications, but that is not that drastic. Let's discuss some aspects. First one is definitions of the tests (.freeipa-pr-ci.yaml) and how to extend them. We currently use 3 definitions: * gating, the definition in repo * nightly master tests * nighly rawhide tests Gating definition is in repo. But both nightly are not. What is the way how other team members can extend this definition? Where are they kept? Could we also put them into a repo? What about the following solution: 1. create a directory with tests definitions, e.g. /ipatests/definitions 2. put these 3 files there - gating - nightly_master - nightly_rawhide 3. make .freeipa-pr-ci.yaml a symlink to /ipatest/definitions/gating 4. for nightly testing do PR which would change only the symlink Benefits: - anybody can extend nightly test suite - the nighlty test suite can be extended right away in a PR which adds the tests - nightly tests won't fail on merge conflict when somebody extends current gating spec Possible alternative is to make it more complex and use something like includes instead of symlinks, but that would need update of PR-CI and I don't see a real benefit in comparison to the symlink solution. -- Petr Vobornik ___ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
[Freeipa-devel] Re: authconfig replacement design
On 02/21/2018 10:25 AM, Pavel Březina via FreeIPA-devel wrote: >> >> >> couple of scenarious here: >> - install server >> install it and configure with authselect. there is no --no-sssd option >> for the server installation >> - upgrade server >> bakup authselect configuration. apply authselect sssd profile >> overwriting what was there before. > > Why do you call authselect during server update? Shouldn't the system be > already configured? In FreeIPA server, we want to make sure that authselect profile is activated, so that this FreeIPA server's PAM stack receives further updates in case the authselect profile gets some fixes in. If it still has the manual PAM configuration via old authconfig, it would not receive such updates. Is that true? >> - upgrade client >> not applicable. only new binaries are copied onto the system I would think that we want the same as on the FreeIPA server. I.e. if we detect that FreeIPA client is configured with SSSD, we switch to a supported authselect PAM stack and thus receive further updates, without being stuck with manual authconfig PAM stack. Martin ___ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
[Freeipa-devel] [freeipa PR#1474][closed] Prepare migration of NSS databases to sql format
URL: https://github.com/freeipa/freeipa/pull/1474 Author: tiran Title: #1474: Prepare migration of NSS databases to sql format Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/1474/head:pr1474 git checkout pr1474 ___ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
[Freeipa-devel] [freeipa PR#1625][closed] [Backport][ipa-4-5] - test_x509: test very long OID
URL: https://github.com/freeipa/freeipa/pull/1625 Author: Rezney Title: #1625: [Backport][ipa-4-5] - test_x509: test very long OID Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/1625/head:pr1625 git checkout pr1625 ___ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
[Freeipa-devel] [freeipa PR#1626][opened] Silence some GCC warnings
URL: https://github.com/freeipa/freeipa/pull/1626
Author: tiran
Title: #1626: Silence some GCC warnings
Action: opened
PR body:
"""
The ipadb_free() and ipadb_alloc() functions are only used with
KRB5_KDB_DAL_MAJOR_VERSION 5.
```
ipa_extdom_common.c:103:5: warning: enumeration value ‘NSS_STATUS_RETURN’ not
handled in switch [-Wswitch]
ipa_kdb.c:639:13: warning: ‘ipadb_free’ defined but not used [-Wunused-function]
ipa_kdb.c:634:14: warning: ‘ipadb_alloc’ defined but not used
[-Wunused-function]
```
Signed-off-by: Christian Heimes
"""
To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/1626/head:pr1626
git checkout pr1626
From 511ae84cee785640a0dfe024e1a19cdda8a11b59 Mon Sep 17 00:00:00 2001
From: Christian Heimes
Date: Fri, 23 Feb 2018 10:04:26 +0100
Subject: [PATCH] Silence some GCC warnings
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The ipadb_free() and ipadb_alloc() functions are only used with
KRB5_KDB_DAL_MAJOR_VERSION 5.
ipa_extdom_common.c:103:5: warning: enumeration value ‘NSS_STATUS_RETURN’ not handled in switch [-Wswitch]
ipa_kdb.c:639:13: warning: ‘ipadb_free’ defined but not used [-Wunused-function]
ipa_kdb.c:634:14: warning: ‘ipadb_alloc’ defined but not used [-Wunused-function]
Signed-off-by: Christian Heimes
---
daemons/ipa-kdb/ipa_kdb.c | 2 ++
daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c | 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/daemons/ipa-kdb/ipa_kdb.c b/daemons/ipa-kdb/ipa_kdb.c
index 222900ae7a..00c732624b 100644
--- a/daemons/ipa-kdb/ipa_kdb.c
+++ b/daemons/ipa-kdb/ipa_kdb.c
@@ -631,6 +631,7 @@ static krb5_error_code ipadb_get_age(krb5_context kcontext,
return 0;
}
+#if KRB5_KDB_DAL_MAJOR_VERSION == 5
static void *ipadb_alloc(krb5_context context, void *ptr, size_t size)
{
return realloc(ptr, size);
@@ -640,6 +641,7 @@ static void ipadb_free(krb5_context context, void *ptr)
{
free(ptr);
}
+#endif
/* KDB Virtual Table */
diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
index 1b93dce186..525487c9e4 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
@@ -109,9 +109,9 @@ int __nss_to_err(enum nss_status errcode)
return ERANGE;
case NSS_STATUS_UNAVAIL:
return ETIMEDOUT;
+default:
+return -1;
}
-
-return -1;
}
int getpwnam_r_wrapper(struct ipa_extdom_ctx *ctx, const char *name,
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
[Freeipa-devel] [freeipa PR#1615][closed] Remove deprecated -p option from ipa-dns-install
URL: https://github.com/freeipa/freeipa/pull/1615 Author: tiran Title: #1615: Remove deprecated -p option from ipa-dns-install Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/1615/head:pr1615 git checkout pr1615 ___ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
