Hi,
am I correct in thinking that the -Werror=implicit-{function-declaration,int}
part of this change was rescinded? The change page does not reflect this.
Zbyszek
After a discussion with the Change owner, this Change is going to be
considered as System Wide. The reason is a need for change of the
order of modules in nsswitch.conf,.
Regards,
Jan
On Tue, Jan 31, 2017 at 1:17 PM, Jan Kurik <jkurik(a)redhat.com> wrote:
> = Proposed Self Contained Change: SSSD fast cache for local users =
> https://fedoraproject.org/wiki/Changes/SSSDCacheForLocalUsers
>
> Change owner(s):
> * Stephen Gallagher <sgallagh AT redhat DOT com>
> * Jakub Hrozek <jhrozek AT redhat DOT com>
>
> Enable resolving all users through the sss NSS modules for better performance.
>
>
> == Detailed Description ==
> SSSD ships with a very fast memory cache for a couple of releases now.
> However, using this cache conflicts with nscd's caching and nscd has
> been disabled by default. That degrades performance, because every
> user or group lookup must open the local files.
>
> This change proposes leveraging a new "files" provider SSSD will ship
> in the next version in order to resolve also users from the local
> files. That way, the "sss" NSS module can be configured before the
> files module in nsswitch.conf and the system could leverage sss_nss
> caching for both local and remote users.
>
> The upstream design of the files provider can be found at:
> https://fedorahosted.org/sssd/wiki/DesignDocs/FilesProvider
>
> Below is a mini-FAQ that lists the most common questions we've received so far:
>
> Q: Does SSSD take over /etc/passwd and /etc/files?
> A: No. SSSD just monitors them with inotify and copies the records
> into its cache.
>
> Q: Does SSSD need to be running all the time now? What if it crashes?
> A: SSSD needs to be running in order to benefit from this
> functionality. However, the nss_sss module is built in such a way that
> even if sssd is not running, nss_sss should fail over to nss_files
> pretty quickly (we'll quantify "pretty quickly" in a more scientific
> fashion soon)
>
> Q: Do I need to configure SSSD now?
> A: No, we'll ship a default configuration.
>
>
> == Scope ==
> * Proposal owners:
> Jakub Hrozek and Stephen Gallagher work on the design and coding
>
> * Other developers:
> The SSSD upstream will participate in code review of the change
>
> * Release engineering:
> None required
>
> * Policies and guidelines:
> None needed
>
> * Trademark approval:
> None needed
> --
> Jan Kuřík
> Platform & Fedora Program Manager
> Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
Greetings,
This e-mail is intended to inform you about the upcoming Bugzilla changes
happening on 2017-02-21 (Rawhide bug rebase) and what you need to do,
if anything.
We will be automatically changing the version for most rawhide bugs to
Fedora 26.
This will result in regular bugs reported against rawhide during the Fedora 26
development cycle being changed to version ‘26' instead of their current
assignment, ‘rawhide’. This is to align with the branching of Fedora 26 from
rawhide and to more accurately tell where in the lineage of releases the bug was
last reported.
Note that this procedure does not apply to bugs that are open for the ‘Package
Review’ or 'kernel' components or bugs that have the ''FutureFeature''
or ''Tracking'' keywords
set. These will stay open as rawhide bugs indefinitely.
If you do not want your bugs changed to version ‘26‘, add the ''FutureFeature''
keyword. If you need help changing a large amount of bugs manually, we’d be glad
to help.
The process was re-approved by FESCo https://pagure.io/fesco/issue/1096 .
Jan
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed Self Contained Change: SSSD fast cache for local users =
https://fedoraproject.org/wiki/Changes/SSSDCacheForLocalUsers
Change owner(s):
* Stephen Gallagher <sgallagh AT redhat DOT com>
* Jakub Hrozek <jhrozek AT redhat DOT com>
Enable resolving all users through the sss NSS modules for better performance.
== Detailed Description ==
SSSD ships with a very fast memory cache for a couple of releases now.
However, using this cache conflicts with nscd's caching and nscd has
been disabled by default. That degrades performance, because every
user or group lookup must open the local files.
This change proposes leveraging a new "files" provider SSSD will ship
in the next version in order to resolve also users from the local
files. That way, the "sss" NSS module can be configured before the
files module in nsswitch.conf and the system could leverage sss_nss
caching for both local and remote users.
The upstream design of the files provider can be found at:
https://fedorahosted.org/sssd/wiki/DesignDocs/FilesProvider
Below is a mini-FAQ that lists the most common questions we've received so far:
Q: Does SSSD take over /etc/passwd and /etc/files?
A: No. SSSD just monitors them with inotify and copies the records
into its cache.
Q: Does SSSD need to be running all the time now? What if it crashes?
A: SSSD needs to be running in order to benefit from this
functionality. However, the nss_sss module is built in such a way that
even if sssd is not running, nss_sss should fail over to nss_files
pretty quickly (we'll quantify "pretty quickly" in a more scientific
fashion soon)
Q: Do I need to configure SSSD now?
A: No, we'll ship a default configuration.
== Scope ==
* Proposal owners:
Jakub Hrozek and Stephen Gallagher work on the design and coding
* Other developers:
The SSSD upstream will participate in code review of the change
* Release engineering:
None required
* Policies and guidelines:
None needed
* Trademark approval:
None needed
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
Hello,
today after updating my system, dnf started segfaulting. I debugged it
a bit and found out that it is not dnf/libdnf's fault, but glibc's[0].
If dnf started crashing for you, just use --refresh in command-line or
downgrade glibc from -29 to -28.
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1417870
--
-Igor Gnatenko
Hi everyone!
The submission deadline for System Wide Changes of Fedora 26 [1] is
today (January 31st). Alpha release of Fedora 26 is planned then on
March 14th.
As the deadline applies for System Wide Changes it is always good to
have most of Self Contained Changes proposed as well. In case you'll
need any help with your Change proposals, feel free to contact me.
[1] https://fedoraproject.org/wiki/Releases/26/Schedule
Best Regards,
Jan
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
With pkgconf, dynafed fails to build. Configure appears to find things, but
needed include dirs do not seem to be added to the build:
https://kojipkgs.fedoraproject.org//work/tasks/6524/17426524/build.log
-- Checking for module 'gfal2>=2.1.7'
-- Found gfal2, version 2.12.3
cd /builddir/build/BUILD/dynafed-1.2.3/src/plugins/lfcclient && /usr/bin/c++
-DUGR_PLUGIN_DIR_DEFAULT=\"/usr/lib/ugr\" -D_FILE_OFFSET_BITS=64
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -Dugrlocplugin_lfc_EXPORTS
-I/builddir/build/BUILD/dynafed-1.2.3/src/plugins/lfcclient
-I/builddir/build/BUILD/dynafed-1.2.3
-I/builddir/build/BUILD/dynafed-1.2.3/src
-I"/builddir/build/BUILD/dynafed-1.2.3/src/\$PROTOBUF_INCLUDE_DIRS}"
-I/builddir/build/BUILD/dynafed-1.2.3/src/.
-I/builddir/build/BUILD/dynafed-1.2.3/src/utils -I/usr -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -march=armv7-a -mfpu=vfpv3-d16
-mfloat-abi=hard -fPIC -std=c++0x -o
CMakeFiles/ugrlocplugin_lfc.dir/UgrLocPlugin_lfc.cc.o -c
/builddir/build/BUILD/dynafed-1.2.3/src/plugins/lfcclient/UgrLocPlugin_lfc.cc
In file included from
/builddir/build/BUILD/dynafed-1.2.3/src/plugins/lfcclient/UgrLocPlugin_lfc.cc:22:0:
/builddir/build/BUILD/dynafed-1.2.3/src/plugins/lfcclient/UgrLocPlugin_lfc.hh:25:22:
fatal error: gfal_api.h: No such file or directory
#include <gfal_api.h>
^
This uses cmake, so may be an unexpected interaction there.
See also https://apps.fedoraproject.org/koschei/package/dynafed
Thanks!
--
Orion Poplawski
Technical Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com