<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.linux.redhat.sssd.devel">
    <title>gmane.linux.redhat.sssd.devel</title>
    <link>http://blog.gmane.org/gmane.linux.redhat.sssd.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9686"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9669"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9668"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9666"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9656"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9652"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9645"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9643"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9638"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9636"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9627"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9625"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9619"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9613"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9605"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9604"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9603"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9602"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9595"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9594"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9686">
    <title>ldap_access_filter being ignored?</title>
    <link>http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9686</link>
    <description>&lt;pre&gt;Hello,

I've set up OpenLDAP with PAM.  Problem is, I needed name differentiation,
which sssd offers.

I've since migrated one of the two servers (I'm using replication) to
authenticate PAM using sssd.

I -can- log in just fine.  One problem:  the ldap_access_filter is being
ignored.  I set it up to filter only to members of a certain group, and
it's just plain letting anyone log in if they're a user and have the
correct password for the account.

I've implemented memberOf as an overlay on the master and shadow LDAP
servers.  I've even just totally purged and rebuilt the LDAP database from
original sources, based on something I read that said that if you implement
memberOf, it won't retroactively affect old accounts and groups.  Still no
good.

I am -beyond- frustrated with this, and need it to work.  I'm working with
an OpenSuSE 11.4 box, but I took out their old 1.4 version of sssd and put
in the latest 1.8.3 yesterday.  So I'm working with the latest production
release.

One of the things that bothers me &lt;/pre&gt;</description>
    <dc:creator>Fairlight</dc:creator>
    <dc:date>2012-05-25T20:32:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9669">
    <title>[PATCH] Use uint32_t to copy the service port</title>
    <link>http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9669</link>
    <description>&lt;pre&gt;The sss_client was copying 32bit port value, but the NSS responder was
reading 16bit port value. This was breaking on Big-Endian machines where
we read "the other 16bits".

By the way, is there a reason to use 32bits in the client in the first
place? IIRC a port number is a 16 bit value..
From eb8a81adfa05cfa8b62291bac0052c4e15124a8e Mon Sep 17 00:00:00 2001
From: Jakub Hrozek &amp;lt;jhrozek-H+wXaHxf7aLQT0dZR+AlfA&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
Date: Fri, 25 May 2012 11:51:11 +0200
Subject: [PATCH] Use uint32_t to copy the service port

---
 src/responder/nss/nsssrv_services.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/responder/nss/nsssrv_services.c b/src/responder/nss/nsssrv_services.c
index 2e539f13576d18c97d8c3bff2ced2fd5ed01290f..3a6e1b07866a539b36284446e60b2d507d312275 100644
--- a/src/responder/nss/nsssrv_services.c
+++ b/src/responder/nss/nsssrv_services.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1041,13 +1041,13 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; errno_t parse_getservbyport(TALLOC_CTX *mem_ctx,
     errno_t ret;
     size_t i, j;
     size_t port_and&lt;/pre&gt;</description>
    <dc:creator>Jakub Hrozek</dc:creator>
    <dc:date>2012-05-25T10:46:53</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9668">
    <title>Use variable to control verbosity for things in commondirectory</title>
    <link>http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9668</link>
    <description>&lt;pre&gt;
https://fedorahosted.org/sssd/ticket/394

I was reviewing this ticket and talks about a default value to verbosity.

althought i'm not sure if is about the sssd debug level or other case.

If the case of debug level:

Reading theory in
   http://sgallagh.fedorapeople.org/sssd/1.8.91/man/sssd.conf.5.html 
in section debug_level (integer) mentions that:

  "0x0010 is the default value as well as the lowest allowed value"
  "0x0010: Fatal failures. Anything that would prevent SSSD from starting up or causes it to cease running."

If you want to use a higher debug level is changed in sssd.conf-&amp;gt; debug_level = (desired level is placed).

By not specifying on command line flag, is used the indicated in sssd.conf -&amp;gt;debug_level.

If specified in command line debug_level first uses the command line, this was corrected in the ticket https://fedorahosted.org/sssd/ticket/764

In the case concerned from that, the flag already exists.

util.h
[code]
      /** \def DEBUG_IS_SET(level)
         \brief checks whether level &lt;/pre&gt;</description>
    <dc:creator>Ariel Barria</dc:creator>
    <dc:date>2012-05-25T05:22:19</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9666">
    <title>[PATCH] sss_idmap: add support for samba struct dom_sid</title>
    <link>http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9666</link>
    <description>&lt;pre&gt;Hi,

this patch allows us besides other conversions to convert the dom_sid
structure used by samba to strings and back. This structure is used by
various samba libraries, but there are no public inferfaces for the
conversion. I've seen Simo adding code to the IPA kdb plugin doing these
conversions and I need them for the PAC responder as well. So I thought
it might be useful to put it in a library.

bye,
Sumit
From b33d2e0e6cb18a3c90a9b4fda0d4ae7e60136f97 Mon Sep 17 00:00:00 2001
From: Sumit Bose &amp;lt;sbose&amp;lt; at &amp;gt;redhat.com&amp;gt;
Date: Thu, 24 May 2012 12:39:56 +0200
Subject: [PATCH] sss_idmap: add support for samba struct dom_sid

The samba ndr libraries use struct dom_sid to handle SIDs. Since there
is no public samba library which offers conversion from other
representations, e.g. as string, this is addded to libsss_idmap. There
is only a compile-time dependency to the samba header files to check if
struct dom_sid has the expected format. There is no run-time dependency
to any samba library.
---
 Makefile.am&lt;/pre&gt;</description>
    <dc:creator>Sumit Bose</dc:creator>
    <dc:date>2012-05-24T13:04:36</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9656">
    <title>[RFE] Add 'auth_provider = none' as an option to SSSD</title>
    <link>http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9656</link>
    <description>&lt;pre&gt;
Hi, i would comment for to see if i'm wrong.

Ticket https://fedorahosted.org/sssd/ticket/1339

"auth_provider = none" already exists (it seems)

Reading theory in http://sgallagh.fedorapeople.org/sssd/1.8.91/man/sssd.conf.5.html  mentions that:

auth_provider (string)
"none" disallows password changes explicitly. 
Default: "id_provider" is used if it is set and can handle authentication requests. 

in data_provider_be.c
 [code]
    if (strcasecmp(mod_name, NO_PROVIDER) == 0) {
            ret = ENOENT;
            goto done;
    }
 [/code]
 
and by placing "id_provider = proxy" the default auth_provider= id_provider (proxy) , this ago that request proxy_pam_target.

this is correct?

Thanks.       _______________________________________________
sssd-devel mailing list
sssd-devel&amp;lt; at &amp;gt;lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
&lt;/pre&gt;</description>
    <dc:creator>Ariel Barria</dc:creator>
    <dc:date>2012-05-23T22:30:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9652">
    <title>[PATCH] NSS: Fix segfault when mmap cache cannot beinitialized</title>
    <link>http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9652</link>
    <description>&lt;pre&gt;If the mmap cache cannot be initialized (such as insufficient
permissions or SELinux/AppArmor denial), we are supposed to fall back to
our 1.8 behavior of LDB cache only. However, we weren't properly
checking that the cache had been set up and we were always attempting to
dereference the mmap context in fill_pwent() and fill_grent().

Fixes https://fedorahosted.org/sssd/ticket/1346
_______________________________________________
sssd-devel mailing list
sssd-devel&amp;lt; at &amp;gt;lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
&lt;/pre&gt;</description>
    <dc:creator>Stephen Gallagher</dc:creator>
    <dc:date>2012-05-23T13:03:16</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9645">
    <title>Securing remote domains</title>
    <link>http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9645</link>
    <description>&lt;pre&gt;Hello all,

We're interested in using SSSD to replace our current use of
NSS/PAM/NSCD/NSLCD.  However, we were curious whether or not
SSSD had implemented some critical security checks to protect
against malicious remote domains.

    - What are the semantics of the local domain: that is,
      do I have a guarantee that entries in local will never
      be affected by the network?

    - If the answer to the above is true, how does SSSD resolve
      conflicts between two domains which have entries that claim
      the same UID?  I understand that the max_id/min_id functionality
      is intended to address this partially, but does SSSD do any
      further sanity checks, such as refusing information from
      remote domains that exist in local domains?

    - Additionally, users may come with groups, and it is bad if
      remote domains can spoof ownership in local groups.  Is there
      anyway to lock this down?

    - It is frequently useful for applications running on the system
      to be able to i&lt;/pre&gt;</description>
    <dc:creator>Edward Z. Yang</dc:creator>
    <dc:date>2012-05-23T02:06:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9643">
    <title>New mailing list: sssd-users</title>
    <link>http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9643</link>
    <description>&lt;pre&gt;For quite some time, we have used the sssd-devel mailing list for
development and user configuration issue discussions. As the project has
grown, it becomes more and more clear that we need to separate these
topics into their own lists.

So as of today, we now have a new mailing list for user questions. You
can subscribe at https://fedorahosted.org/mailman/listinfo/sssd-users

This list will be considerably less noisy for our users as they will not
be bombarded with patch review emails and other development-centric
issues.
_______________________________________________
sssd-devel mailing list
sssd-devel&amp;lt; at &amp;gt;lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
&lt;/pre&gt;</description>
    <dc:creator>Stephen Gallagher</dc:creator>
    <dc:date>2012-05-22T17:41:27</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9638">
    <title>[PATCH] LDAP nested groups: Do not process callback with _post deep in the nested structure</title>
    <link>http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9638</link>
    <description>&lt;pre&gt;https://fedorahosted.org/sssd/ticket/1343

I still haven't been able to fully test the patch, but sending out for
review anyway.
From d111b80ff5f49f5efcf3bf7d30abf76533e4d440 Mon Sep 17 00:00:00 2001
From: Jakub Hrozek &amp;lt;jhrozek-H+wXaHxf7aLQT0dZR+AlfA&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
Date: Tue, 22 May 2012 17:41:52 +0200
Subject: [PATCH] LDAP nested groups: Do not process callback with _post deep
 in the nested structure

https://fedorahosted.org/sssd/ticket/1343
---
 src/providers/ldap/sdap_async_groups.c |   22 ++++++++++------------
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/src/providers/ldap/sdap_async_groups.c b/src/providers/ldap/sdap_async_groups.c
index 84eb7cbfd6536f286c5bf4b1f41e150d003130aa..b587f668e678fd0b68eb401174fc2b097b3f4b87 100644
--- a/src/providers/ldap/sdap_async_groups.c
+++ b/src/providers/ldap/sdap_async_groups.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -2498,14 +2498,13 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static errno_t sdap_nested_group_lookup_user(struct tevent_req *req,
                 ret = sdap_nested_group_process_step(req);
             &lt;/pre&gt;</description>
    <dc:creator>Jakub Hrozek</dc:creator>
    <dc:date>2012-05-22T15:43:43</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9636">
    <title>[PATCH] Fixed issue in SELinux user maps</title>
    <link>http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9636</link>
    <description>&lt;pre&gt;There was an issue when IPA provider didn't set PAM_SUCCESS when
successfully finished loading SELinux user maps. This lead to the map
not being read in the responder.

Thanks
Jan
_______________________________________________
sssd-devel mailing list
sssd-devel&amp;lt; at &amp;gt;lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
&lt;/pre&gt;</description>
    <dc:creator>Jan Zelený</dc:creator>
    <dc:date>2012-05-22T14:44:43</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9627">
    <title>sssd &amp; AD frequently disconnecting</title>
    <link>http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9627</link>
    <description>&lt;pre&gt;Hi List,

I am using sssd (F17) with AD and what I observed is that sssd frequently marks my AD server working and then "not working". Symptoms:

(Mon May 21 13:58:43 2012) [sssd[be[default]]] [sdap_id_op_connect_step] (0x4000): beginning to connect
(Mon May 21 13:58:43 2012) [sssd[be[default]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP'
(Mon May 21 13:58:43 2012) [sssd[be[default]]] [get_server_status] (0x1000): Status of server 'dcpra1.XXX' is 'working'
(Mon May 21 13:58:43 2012) [sssd[be[default]]] [get_port_status] (0x1000): Port status of port 389 for server 'dcpra1.XXX' is 'not working'
(Mon May 21 13:58:43 2012) [sssd[be[default]]] [fo_resolve_service_send] (0x0020): No available servers for service 'LDAP'

Sometimes sssd does manage to connect, sometimes not.
I know there is a problem with the AD controller cutting the connection after some timeout that we can not (yet) handle correctly, but this 
also happens shortly after sssd restart.

Is there any explanation to this?
Th&lt;/pre&gt;</description>
    <dc:creator>Ondrej Valousek</dc:creator>
    <dc:date>2012-05-21T12:08:33</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9625">
    <title>Request for community input: Support of RADIUS authentication via SSSD</title>
    <link>http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9625</link>
    <description>&lt;pre&gt;Hello,

As SSSD (the System Security Services Daemon) is gaining ground as a
bridge between applications running on a machine and central
authentication sources such as Active Directory and FreeIPA, questions
about support for other authentication protocols start to come up. One
such protocol is RADIUS (Remote Authentication Dial In User Service).
RADIUS is a popular authentication protocol for enterprise deployments,
notably for VPN (virtual private network) and WPA (WiFI Protected
Access) access.

Some enterprise deployments today also rely on RADIUS for the
authentication of system users. This is most often accomplished through
the use of the pam_radius_auth[1] module for PAM (Pluggable
Authentication Modules).

From a design standpoint, a RADIUS authentication module would be a
simple fit. SSSD would acquire user identities from an LDAP directory
server, but would perform authentication against a RADIUS server, rather
than via LDAP simple-bind or Kerberos TGT acquisition. From a
completeness perspective,&lt;/pre&gt;</description>
    <dc:creator>Dmitri Pal</dc:creator>
    <dc:date>2012-05-22T10:05:55</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9619">
    <title>[PATCH] KRB5: Avoid NULL-dereference with empty keytab</title>
    <link>http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9619</link>
    <description>&lt;pre&gt;Fixes https://fedorahosted.org/sssd/ticket/1330

Both places in the code that consume this function are properly checking
for n_etype_list &amp;gt; 0 before using it.
_______________________________________________
sssd-devel mailing list
sssd-devel&amp;lt; at &amp;gt;lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
&lt;/pre&gt;</description>
    <dc:creator>Stephen Gallagher</dc:creator>
    <dc:date>2012-05-22T00:38:26</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9613">
    <title>sssd &amp; AD frequently disconnecting</title>
    <link>http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9613</link>
    <description>&lt;pre&gt;Hi List,

I am using sssd (F17) with AD and what I observed is that sssd frequently marks my AD server working and then "not working". Symptoms:

(Mon May 21 13:58:43 2012) [sssd[be[default]]] [sdap_id_op_connect_step] (0x4000): beginning to connect
(Mon May 21 13:58:43 2012) [sssd[be[default]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP'
(Mon May 21 13:58:43 2012) [sssd[be[default]]] [get_server_status] (0x1000): Status of server 'dcpra1.XXX' is 'working'
(Mon May 21 13:58:43 2012) [sssd[be[default]]] [get_port_status] (0x1000): Port status of port 389 for server 'dcpra1.XXX' is 'not working'
(Mon May 21 13:58:43 2012) [sssd[be[default]]] [fo_resolve_service_send] (0x0020): No available servers for service 'LDAP'

Sometimes sssd does manage to connect, sometimes not.
I know there is a problem with the AD controller cutting the connection after some timeout that we can not (yet) handle correctly, but this 
also happens shortly after sssd restart.

Is there any explanation to this?
Th&lt;/pre&gt;</description>
    <dc:creator>Ondrej Valousek</dc:creator>
    <dc:date>2012-05-21T12:16:11</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9605">
    <title>[PATCHES] Improvements to SSSDConfig build and install</title>
    <link>http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9605</link>
    <description>&lt;pre&gt;Patch 0001: Make SSSDConfig a package
We were polluting the primary Python space with several
dependencies. We will now install them their own directory/module. This
has been done in such a way that existing scripts that import SSSDConfig
will require no modifications.

Patch 0002: Make default config and schema file locations configurable
Previously, we were hard-coding the sssd.conf and sssd.api.* locations
into the source. With this patch, we will take the default locations
from values specified by autoconf.

Fixes https://fedorahosted.org/sssd/ticket/1008

_______________________________________________
sssd-devel mailing list
sssd-devel&amp;lt; at &amp;gt;lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
&lt;/pre&gt;</description>
    <dc:creator>Stephen Gallagher</dc:creator>
    <dc:date>2012-05-18T13:28:20</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9604">
    <title>[PATCH] 1213-Warn to syslog when dereference requests fail</title>
    <link>http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9604</link>
    <description>&lt;pre&gt;
https://fedorahosted.org/sssd/ticket/1213       _______________________________________________
sssd-devel mailing list
sssd-devel&amp;lt; at &amp;gt;lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
&lt;/pre&gt;</description>
    <dc:creator>Ariel Barria</dc:creator>
    <dc:date>2012-05-18T05:18:31</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9603">
    <title>[PATCH] Always use positional arguments in translatablestrings</title>
    <link>http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9603</link>
    <description>&lt;pre&gt;Some languages might need to change the order of the variables in the
strings. By assigning them a positional value, we make it possible to
reorder them.

I added positional values to the strings that have only a single
variable as well, mostly so it will be a guideline to anyone modifying
those strings.

Fixes https://fedorahosted.org/sssd/ticket/1336

_______________________________________________
sssd-devel mailing list
sssd-devel&amp;lt; at &amp;gt;lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
&lt;/pre&gt;</description>
    <dc:creator>Stephen Gallagher</dc:creator>
    <dc:date>2012-05-17T17:56:44</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9602">
    <title>Developer Tutorials</title>
    <link>http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9602</link>
    <description>&lt;pre&gt;In the interests of helping new developers get up to speed faster, I've
created a new wiki page for development tutorials. So far it includes
links to Pavel Březina's excellent Talloc tutorial and a few guides for
git usage with the SSSD.

All contributions to this effort are welcome and encouraged!

https://fedorahosted.org/sssd/wiki/DevelTutorials
_______________________________________________
sssd-devel mailing list
sssd-devel&amp;lt; at &amp;gt;lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
&lt;/pre&gt;</description>
    <dc:creator>Stephen Gallagher</dc:creator>
    <dc:date>2012-05-17T14:33:38</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9595">
    <title>[PATCH] NSS: Expire in-memory netgroup cache before the nowait timeout</title>
    <link>http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9595</link>
    <description>&lt;pre&gt;The fact that we were keeping it in memory for the full duration
of the cache timeout meant that we would never reap the benefits
of the midpoint cache refresh.
_______________________________________________
sssd-devel mailing list
sssd-devel&amp;lt; at &amp;gt;lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
&lt;/pre&gt;</description>
    <dc:creator>Stephen Gallagher</dc:creator>
    <dc:date>2012-05-16T18:34:30</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9594">
    <title>[PATCH] Use the sysdb attribute name, not LDAP attribute name</title>
    <link>http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9594</link>
    <description>&lt;pre&gt;I found two other places where we used the map name instead of sys_name. The
first is the probable reason of https://fedorahosted.org/sssd/ticket/1338,
although I haven't heard back from Ondrej yet if it fixed his issue
completely.

After I found the first one, I grepped for all occurences of "].name"
and I have found the second one. As far as I can tell, we're using the
maps correctly now.
From 8ad2c3e2b15a81f5f9b2f7018b67bf84f0a2ef1c Mon Sep 17 00:00:00 2001
From: Jakub Hrozek &amp;lt;jhrozek-H+wXaHxf7aLQT0dZR+AlfA&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
Date: Wed, 16 May 2012 17:03:41 +0200
Subject: [PATCH] Use the sysdb attribute name, not LDAP attribute name

---
 src/providers/ldap/sdap_async_autofs.c |    2 +-
 src/providers/ldap/sdap_async_groups.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/providers/ldap/sdap_async_autofs.c b/src/providers/ldap/sdap_async_autofs.c
index 3140596efb07e8433f6e044dc2e2c8bba8735886..d8a2d0eec75c3e42cd3dc39930d20a0a51e2c541 100644
--- a/src/providers/ldap/sdap_async&lt;/pre&gt;</description>
    <dc:creator>Jakub Hrozek</dc:creator>
    <dc:date>2012-05-16T17:38:36</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9586">
    <title>[PATCH] RPM: Allow running 'make rpms' on RHEL 5 machines</title>
    <link>http://comments.gmane.org/gmane.linux.redhat.sssd.devel/9586</link>
    <description>&lt;pre&gt;Our previous detection for this was flawed, because the %{rhel}
macro did not exist on the version of RPM shipped with RHEL 5, but
it worked when building for RHEL 5 through mock. This new patch
relies on grepping /etc/redhat-release for the version
information.

Fixes https://fedorahosted.org/sssd/ticket/1206
_______________________________________________
sssd-devel mailing list
sssd-devel&amp;lt; at &amp;gt;lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
&lt;/pre&gt;</description>
    <dc:creator>Stephen Gallagher</dc:creator>
    <dc:date>2012-05-15T15:54:10</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.linux.redhat.sssd.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.linux.redhat.sssd.devel</link>
  </textinput>
</rdf:RDF>

