On Thu, 2011-04-28 at 08:07 +0200, Jan Zelený wrote:
> On Wed, 2011-04-27 at 17:45 +0200, Jakub Hrozek wrote:
> > On 04/27/2011 03:30 PM, Stephen Gallagher wrote:
> > > On Tue, 2011-04-19 at 14:57 -0400, Stephen Gallagher wrote:
> > >> On Tue, 2011-04-12 at 12:33 +0200, Jan Zelený wrote:
> > >>> Can someone please take a look at the patch and ack that all
issues
> > >>> discovered by Simo have been corrected?
> > >>>
> > >>> Also note that in the original email there is another patch,
which
> > >>> hasn't been reviewed yet.
> > >>
> > >> Ack to both patches and pushed to master.
> > >
> > > Unfortunately, I've now discovered several issues with this patch
(too
> > > late).
> > >
> > > First, it causes a crash if SSSD started up in offline mode (e.g.
> > > disconnected laptop) and then goes online (e.g. VPN).
> > >
> > > #0 0x00007fec7adddd28 in sdap_check_online_done (req=0x0)
> > > at ../src/providers/ldap/ldap_id.c:729
> > > #1 0x00007fec7ae0f3e1 in sdap_cli_auth_done (subreq=0x0)
> > > at ../src/providers/ldap/sdap_async_connection.c:1430
> > > #2 0x00007fec7ae0e207 in sdap_auth_done (subreq=0x1ea9570)
> > > at ../src/providers/ldap/sdap_async_connection.c:1007
> > > #3 0x00007fec7ae0c8a9 in simple_bind_done (op=0x1ea9880,
> > > reply=0x1ea97f0, error=0, pvt=0x1ea9570)
> > > at ../src/providers/ldap/sdap_async_connection.c:540
> > > #4 0x00007fec7adf4aa9 in sdap_process_message (ev=0x1e74470,
> > > sh=0x1eb2c70, msg=0x1eb33e0) at ../src/providers/ldap/sdap_async.c:364
> > > #5 0x00007fec7adf4363 in sdap_process_result (ev=0x1e74470,
> > > pvt=0x1eb2c70) at ../src/providers/ldap/sdap_async.c:207
> > > #6 0x00007fec7adf3db6 in sdap_ldap_result (ev=0x1e74470,
> > > fde=0x1eb3140, flags=1, pvt=0x1eb2c70) at
> > > ../src/providers/ldap/sdap_async.c:152 #7 0x000000389ee05d57 in ?? ()
> > > from /usr/lib64/libtevent.so.0 #8 0x000000389ee035b0 in
> > > _tevent_loop_once ()
> > > from /usr/lib64/libtevent.so.0
> > > #9 0x000000389ee0373b in tevent_common_loop_wait ()
> > > from /usr/lib64/libtevent.so.0
> > > #10 0x000000000043d41f in server_loop (main_ctx=0x1e755e0)
> > > at ../src/util/server.c:526
> > > #11 0x000000000040f8d2 in main (argc=6, argv=0x7fffbb9c67a8)
> > > at ../src/providers/data_provider_be.c:1284
> > >
> > >
> > > The problem is that ctx->srv_opts is NULL here (since we've never
made
> > > a connection to the server before this).
> > >
> > > While I was investigating this, I noticed something else as well. This
> > > entire IF block is completely useless as written. In the IF block, you
> > > set ctx->srv_opts attributes, but then immediately after this block,
> > > you replace the contents of ctx->srv_opts with the returned srv_opts
> > > from sdap_cli_connect_recv()
> > >
> > > My guess here is that the assignments in the IF block were supposed to
> > > be setting srv_opts instead of ctx->srv_opts. The only part that
> > > confuses me is where you're setting ctx->srv_opts->last_usn to
> > > srv_opts->last_usn. I thought we had covered before that if the value
> > > of srv_opts->last_usn was ever lower than the stored value, we MUST
set
> > > it to zero. This is because we know that the USN values are not in line
> > > with the ones we have stored, so we have to do a full update to be
> > > safe.
> > >
> > > I'm attaching a patch that I think will resolve the issue (though I
> > > can't test it as I don't have access to a server with USN values).
At
> > > the very least, it resolves the crash above for me.
> >
> > Ack
>
> I'm going to hold off pushing this until I get buy-in from Jan.
Thanks for catching this.
One question though: did you test reconnection to the same server with reset
USN? I'm sure it will work in terms of refreshing the local database, I'm just
not entirely certain that the srv_opts->last_usn will be set to current value
later in the code (which would mean the next reconnection to the same server
wouldn't start refreshing the data). If the test passes, consider the patch
Acked.
I haven't tested it at all. As you can see in my original email, I don't
have a setup to test with. I'm also not entirely sure I covered all my
bases here (hence why I need your input).
I can test this scenario (reconnecting to the same server at least
twice, both
times with USN lower than registered in SSSD) myself, but not until this
evening, I have busy schedule during the day.
Please do.