Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.7.0
priority: major => minor

Fields changed

milestone: SSSD 1.8.0 => SSSD 1.9.0
patch: => 0

That should be libnl-3, which was released about the time this ticket was opened.

rhbz: =>

Replying to [comment:3 ohnonotanotheraccount]:

That should be libnl-3, which was released about the time this ticket was opened.

Agreed, IIRC libnl2 was not considered API stable, while libnl3 is.

We might need to do this sooner:

http://lists.fedoraproject.org/pipermail/devel/2011-November/159249.html

milestone: SSSD 1.9.0 => NEEDS_TRIAGE

Fields changed

summary: Support libnl 2.0 => Support libnl 3.x

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.7.0

Dan W will have libnl 3.x test RPMs ready next week and will make them available so we can start porting.

owner: somebody => jhrozek

Fields changed

milestone: SSSD 1.7.0 => SSSD 1.8.0

Fields changed

type: defect => enhancement

Fields changed

blockedby: =>
blocking: =>
milestone: SSSD 1.8.0 => SSSD 1.9.0 NEEDS_TRIAGE

"Nice to have" for 1.9.

milestone: SSSD 1.9.0 NEEDS_TRIAGE => SSSD 1.9.0

Fields changed

feature_milestone: =>
milestone: SSSD 1.9.0 => SSSD Deferred

Fields changed

rhbz: => 0

A nice bonus we'll get when we switch to libnl3 will be no spurious messages on IPv6 networks.

Currently, if an interface uses IPv6 autoconfiguration, we might receive updates for the existing prefix. From kernel's point of view, this is a change in configuration, too and the kernel emits a message. libnl-1.x does not filter it at all, while libnl-3.x does.

From a conversation I had with the libnl upstream maintainer:

13:44 <tgr> yeah, you may have received an update for that prefix that's all
13:44 <jhrozek> I see
13:44 <tgr> so the valid lifetime has been bumped but you can't really
see that from userspace
13:45 <tgr> nevertheless it's a change in the kernel's view of the
addressing table
13:46 <jhrozek> right, so there's no way to discard exactly this type
of message?
13:46 <tgr> are you only interested in changes to your own static addresses?
13:47 <tgr> you can check for IFA_F_PERMANENT
13:49 <jhrozek> basically I'm looking for a way to distinguish between
"this is a different address than we've had before" versus "update for a
prefix of an existing address"
13:49 <tgr> libnl3 can do that for you                 
13:49 <tgr> it compares the notification against the known address and
invokes a callback when there is a diff

It seems that libnl3 is available in Fedora at last, just as a parallel option:
http://koji.fedoraproject.org/koji/buildinfo?buildID=298902

Please see https://bugzilla.redhat.com/show_bug.cgi?id=868409#c9

Converting our code to use libnl3 might be a good step forward.

design: =>
design_review: => 0
fedora_test_page: =>
milestone: SSSD Deferred => NEEDS_TRIAGE

Need to do it for Fedora rawhide.

milestone: NEEDS_TRIAGE => SSSD 1.10 beta
priority: minor => blocker

Fields changed

selected: => Must

Fields changed

owner: jhrozek => okos

Fields changed

status: new => assigned

Fields changed

patch: 0 => 1

• master: 539b1be

Comment #15 has been split into ticket #1851.

resolution: => fixed
review: => 0
status: assigned => closed

Fields changed

summary: Support libnl 3.x => [RFE] Support libnl 3.x

As discussed with jhrozek, converting to task.

summary: [RFE] Support libnl 3.x => Support libnl 3.x
type: enhancement => task

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1854

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.