-----BEGIN PGP SIGNED MESSAGE-----
Apologies for the slightly alarmist $SUBJECT, but I want to make sure
that this gets read by the appropriate groups.
During today's FESCo meeting, there was the start of a discussion on
how to approve new Products into the Fedora family. As part of this,
it naturally strayed into discussion of what we do about Spins as they
Several ideas were raised (which I'll go through below), but we didn't
feel that this was something that FESCo should answer on its own. We'd
prefer community input on how to handle spins going forward.
So, in no particular order (because it's difficult to say which
questions are the most important):
1) Are Spins useful as they currently exist? There are many problems
that have been noted in the Spins process, most notably that it is
very difficult to get a Spin approved and then has no ongoing
maintenance requiring it to remain functional. We've had Spins at
times go through entire Fedora release cycles without ever being
2) Should Spins be eliminated entirely in favor of Fedora Remixes.
The effect here would be that Spins are no longer an official part of
The Fedora Project but are instead projects unto themselves which are
permitted to consume (possibly large) portions of our tools, packages
and ecosystem. Maintenance and upkeep of these spins then becomes
entirely the responsibility of the downstream community that
constructs them and has no mandatory draw on Fedora's marketing,
ambassadors or quality assurance resources.
3) Should Spins be considered Products-in-development? In other words,
should we only approve Spins that are targeted or destined for
"promotion" to a fully-supported Fedora Product? This is a nuanced
question, as it means different things for different Spins, for
example Spins focusing on a target-audience (Security Spin, Design
Suite Spin) vs. Spins focusing on a technology (LXDE Spin, MATE-Compiz
3b) If we treat Spins as Products-in-development, what do we do with
those Spins that don't fit that criteria?
I'm sure there are other questions that people will come up with on
this thread, but this should provide a good framework for the discussion.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
two patches are attached.
The 1st one is almost he same like patch:
LDAP: Don't fail if subdomain cannot be found by sid
I didn't notice that similar change was done in two separeted patches.
I am not sure if 2nd is right solution, because some conditions are litle bit
confusing for me.
the attached patches address ticket
There are some things I'm still not satisfied with and one of them is
refreshing subdomains. Currently the subdomain refresh happens after
startup and then only if a direct lookup for a user or group happens and
the timeout for subdomain refresh is over. So in theory it's possible
that the user and group objects will be refreshed by the enumeration
task only and there would be no lookup to trigger the subdomain refresh.
With master domain enumeration we've solved this problem by
re-downloading master domain info before the enumeration request. We
could do something similar with subdomains (although a little more
involved becase there is always precisely one subdomain), but I didn't
like doing all the changes in 1.11.3. I can code up additional patch
only for master, though.
Something similar is with fallback from GC to LDAP. Although here I'm
not convinced we need to perform the fallback at all, since there are
already patches on the list that implement the option to disable GC
lookups and there will also be a patch to autodetect POSIX attributes in
These patches must be applied on top of my previous patches.
I've been playing with the SSSD 'ldap_acces_filter' directive.
access_provider = ldap
ldap_access_filter = memberOf=cn=allowedusers,ou=Groups,dc=example,dc=com
I expected a similar functionality to the old ldap.conf:
In the old case, a query was issued to the LDAP backend looking for a
member within cn=HOSTNAME,ou=hosts,dc=example,dc=com (the host object).
In the new case (SSSD), this query is made (excerpt from my OpenLDAP
SRCH base="uid=aborrero,ou=users,dc=example,dc=com" scope=0 deref=0
This means that SSSD is looking inside the user object, instead of the
In sssd-ldap(5) I don't see any additional options to configure this
To migrate to SSSD I would require to filter member which are declared
within host objects.
Could you please give me some advices about this?
Also, please point me to the right mailing list if this is not the one.
Arturo Borrero González
Departamento de Seguridad Informática (nis(a)cica.es)
Centro Informático Científico de Andalucía (CICA)
Avda. Reina Mercedes s/n - 41012 - Sevilla (Spain)
Tfno.: +34 955 056 600 / FAX: +34 955 056 650
Consejería de Economía, Innovación, Ciencia y Empleo
Junta de Andalucía
I found few unused macros: PAM_SM_AUTH, PAM_SM_ACCOUNT, PAM_SM_SESSION,
In my opinion, they were proposed for the same purpose as values from
enum sss_cli_command (SSS_PAM_AUTHENTICATE, SSS_PAM_ACCT_MGMT,
I have one error with current master (I compile with -Werror)
src/tests/cmocka/test_authtok.c:207:48: error: expression which evaluates
to zero treated as a null pointer constant of type 'const uint8_t *'
ret = sss_authtok_set(ts->authtoken, type, '\0', 0);
1 error generated.o
I had an discussion with Pallavi Jha on IRC yesterday and this test should
test empty string(zero length string). Test fof NULL is few lines befor this
Patch is attached.