about fedorahosted-to-github mirror
by Jakub Hrozek
Hi,
I was looking at options we have for setting up an automated way to
mirror our fedorahosted.org repo to github.com. Unfortunately, the
github mirror functionality seems to be discontinued[*], so the next
best thing to do is to set up a github deploy key:
https://developer.github.com/guides/managing-deploy-keys/#deploy-keys
The private key would be on the machine we'd mirror from, the public key
would be uploaded to github. My question is -- do we want to set up the
push job on fedorahosted.org or one of our machines?
1) fedorahosted.org
[+] We don't have to manage the machine, dedicated admins do
[-] We'd have to give read ACL to an identity that pushes /all/
fedorahosted.org projects.
2) Our own (CI?) machines
[+] We manage the machine with the private key. We keep control of the
key.
[-] We manage the machine with the private key. We're developers, not
admins.
I would personally prefer 1) because if the git user on fedorahosted is
compromised, all bets are off anyway and the concern about a push key to
our /mirror/ repo would not be the primary one. But at the same time, I
don't feel comfortable doing the decision without asking the
list.
So -- is anyone opposed to me asking fedorahosted.org to generate a keypair
and giving us the public key that I would upload to github?
Thanks!
[*] github has gained enough traction already, so they don't care about
this functionality anymore..
8 years, 4 months
[PATCH] KRB5: Handle preauth request timeout more gracefully
by Jakub Hrozek
Hi,
this is more or less a cosmetic issue, but it can be irritating
nonetheless. If the krb5_child process times out during preauth, we
would print an EINVAL error message. I think the error should be more
graceful (and I don't insist on PAM_CRED_UNAVAIL).
8 years, 4 months
[PATCH] Keep external members of IPA groups
by Jakub Hrozek
Hi,
it seems like https://fedorahosted.org/sssd/ticket/2492 was not fixed
completely. Attached are two patches that do the trick for me -- they
are not polished (at the very least, the first one needs a test..) but I
would like to get another opinion if they at least aim in the right
direction.
So my groups on IPA server are set like this:
[jhrozek@unidirect] sssd $ [(ext_mem)] ipa group-show topgr --all --raw
dn: cn=topgr,cn=groups,cn=accounts,dc=ipa,dc=test
cn: topgr
gidnumber: 240000024
member: cn=ext_ipa_gr,cn=groups,cn=accounts,dc=ipa,dc=test
ipaUniqueID: 193b7c04-91e9-11e5-bc59-5254005f7b59
objectClass: ipaobject
objectClass: top
objectClass: ipausergroup
objectClass: posixgroup
objectClass: groupofnames
objectClass: nestedgroup
[jhrozek@unidirect] sssd $ [(ext_mem)] ipa group-show ext_ipa_gr --all --raw
dn: cn=ext_ipa_gr,cn=groups,cn=accounts,dc=ipa,dc=test
cn: ext_ipa_gr
ipaexternalmember: S-1-5-21-1897531548-1940899517-361317264-500
ipaUniqueID: ad2bd978-91e8-11e5-9d52-5254005f7b59
memberof: cn=topgr,cn=groups,cn=accounts,dc=ipa,dc=test
objectClass: ipaobject
objectClass: top
objectClass: nestedgroup
objectClass: ipausergroup
objectClass: groupofnames
objectClass: ipaexternalgroup
The SID S-1-5-21-1897531548-1940899517-361317264-500 is an AD user
(administrator)
Now when I do:
sudo sss_cache -E
$ id -G administrator(a)win.trust.test
$ sudo sss_cache -G
$ getent group 240000024
Then the "topgr" group gets resolved and the code gets into sdap_save_grpmem:
908 /* This is a temporal solution until the IPA provider is able to
909 * resolve external group membership.
910 * https://fedorahosted.org/sssd/ticket/2522
911 */
912 if (opts->schema_type == SDAP_SCHEMA_IPA_V1) {
913 ret = sysdb_attrs_get_string(attrs, SYSDB_SID_STR, &group_sid);
914 if (ret != EOK) {
915 DEBUG(SSSDBG_TRACE_FUNC, "Failed to get group sid\n");
916 group_sid = NULL;
Here we set the group_sid variable to NULL, because topgr, being an IPA
group, doesn't have a SID...
917 }
918
919 if (group_sid != NULL) {
920 ret = retain_extern_members(memctx, dom, group_name, group_sid,
921 &userdns, &nuserdns);
Which means we don't call retain_extern_members at all.
922 if (ret != EOK) {
923 DEBUG(SSSDBG_TRACE_INTERNAL,
924 "retain_extern_members failed: %d:[%s].\n",
925 ret, sss_strerror(ret));
926 }
927 }
928 }
But since the whole block of code was added in the same commit, I guess
it must have some purpose..so is going on without a SID the right thing
to do? What was the use-case of the original code?
8 years, 4 months
A RHEL-6.8 preview repo
by Jakub Hrozek
Hi,
At the moment, we plan for RHEL-6.8 to ship with SSSD 1.13. To get some
early testing, here is an automatically-updated COPR repo with the preview
packages:
https://copr.fedoraproject.org/coprs/jhrozek/SSSD-6.8-preview/
We will be glad for test results and/or bug reports, but please read the
repo description carefully before putting these packages on your systems,
especially the "NOT SUPPORTED by Red Hat" part.
For convenience, I copied the description below:
Q: What is the OS and release these packages are supposed to run with?
A: RHEL-6.7 or CentOS-6.7.
Q: How often are these packages updated?
A: When a new build happens in RHEL, except when the fix should not be
released in public yet (think CVE)
Q: Are all RHEL-6.8 features or bug fixes included?
A: Looking at 1.13.x Trac milestones might give a rough idea, but it's best
to contact Red Hat Support and ask about a particular feature/bug status.
Q: Can I update from these packages to RHEL-6.8 proper?
A: That is not supported and we won't do any special work towards making
the upgrade path smooth. These packages are meant to be tried in a test
VM or similar environment.
Q: I found a bug in these packages!
A: Thank you for trying them out! Please file a bug report in SSSD Trac
or ask for help on the sssd-users list
8 years, 4 months
[PATCH] CONTRIB: Add clang-format support
by Petr Cech
Hi,
there is little patch which adds clang-format support. More info is in
header of patch.
My previous patch set [PATCH SET] TEST_TOOLS_COLONDB: Add tests for
sss_colondb_* public API is formatted by clang-format.
Regards
Petr
8 years, 4 months
