[SSSD] [PATCHES] DYNDNS: support mult. interfaces for dyndns_iface opt
Pavel Reichl
preichl at redhat.com
Thu Jul 9 09:15:53 UTC 2015
Hello,
please see attached patches.
1st patch adds return value ENOENT to sss_iface_addr_list_get() so I can
provide more concrete debug message for missing interface or if
interface is not suitable (missing IP address)
2nd patch:
* I introduced new public function sss_iface_addr_concatenate(), I'm
aware that this function is probably not reusable but I needed to work
around that 'struct sss_iface_addr' in defined in source file only.
* I had troubles with correctly handling creating talloc hiearchy of IPs
of different interfaces. I decided to use first address of first found
interface as a parent talloc context for other interfaces. I attached
talloc report output to illustrate this.
>
> 1.
> full talloc report on 'struct sdap_dyndns_get_addrs_state' (total
> 16 bytes in 1 blocks)
> 2.
> full talloc report on 'struct sdap_dyndns_get_addrs_state' (total
> 376 bytes in 19 blocks)
> 3.
> struct sss_iface_addr contains 360 bytes in 18
> blocks (ref 0) 0xbc0650
> 4.
> struct sss_iface_addr contains 120 bytes in 6 blocks
> (ref 0) 0xbecee0
> 5.
> struct sss_iface_addr contains 80 bytes in 4 blocks
> (ref 0) 0xbeb920
> 6.
> struct sss_iface_addr contains 40 bytes in 2
> blocks (ref 0) 0xbd03f0
> 7.
> ../src/providers/dp_dyndns.c:219 contains 16 bytes in
> 1 blocks (ref 0) 0xbd0470
> 8.
> ../src/providers/dp_dyndns.c:219 contains 16 bytes in 1
> blocks (ref 0) 0xbeb9a0
> 9.
> ../src/providers/dp_dyndns.c:219 contains 16 bytes in 1 blocks
> (ref 0) 0xbecf60
>10.
> struct sss_iface_addr contains 120 bytes in 6 blocks
> (ref 0) 0xbd0640
>11.
> struct sss_iface_addr contains 80 bytes in 4 blocks
> (ref 0) 0xbd19a0
>12.
> struct sss_iface_addr contains 40 bytes in 2
> blocks (ref 0) 0xbcfb00
>13.
> ../src/providers/dp_dyndns.c:219 contains 16 bytes in
> 1 blocks (ref 0) 0xbed300
>14.
> ../src/providers/dp_dyndns.c:219 contains 16 bytes in 1
> blocks (ref 0) 0xbd1a20
>15.
> ../src/providers/dp_dyndns.c:219 contains 16 bytes in 1 blocks
> (ref 0) 0xbd06c0
>16.
> struct sss_iface_addr contains 80 bytes in 4 blocks
> (ref 0) 0xbd0eb0
>17.
> struct sss_iface_addr contains 40 bytes in 2 blocks
> (ref 0) 0xbd1900
>18.
> ../src/providers/dp_dyndns.c:219 contains 16 bytes in 1
> blocks (ref 0) 0xbec4f0
>19.
> ../src/providers/dp_dyndns.c:219 contains 16 bytes in 1 blocks
> (ref 0) 0xbeca10
>20.
> ../src/providers/dp_dyndns.c:219 contains 16 bytes in 1 blocks
> (ref 0) 0xbe6ae0
>
* I was thinking whether it would be a good idea to handle the case when
processing of interfaces provided in dyndns_iface yields no address at
all by continuing to detect DYNDNS address from LDAP connection?
Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20150709/902e07f2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-DYNDNS-sss_iface_addr_list_get-return-ENOENT.patch
Type: text/x-patch
Size: 3408 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20150709/902e07f2/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-DYNDNS-support-mult.-interfaces-for-dyndns_iface-opt.patch
Type: text/x-patch
Size: 7776 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20150709/902e07f2/attachment-0001.bin>
More information about the sssd-devel
mailing list