Bump 389-ds-base to 1.3.7.8-1

[stlaz]

Bump 389-ds-version due to problems with replication and connections
not being closed.

https://pagure.io/freeipa/issue/7165
https://pagure.io/freeipa/issue/7228

[abbra]

Looking at logs. It looks like we have a race between dogtag and ipa-server-install. I.e. we install dogtag, then issue a cert for dirsrv and then configure dirsrv to use SSL/TLS. At some stage we restart dirsrv instance to make TLS configuration active but dogtag has own connections open to LDAP and they didn't recover from LDAP server disappearing (for some time) during restart. So dogtag thinks no LDAP store is available anymore and continues to give us 500 error code on requests we send.

Obviously, as we get these errors 500, at some point we gave up and stop installation.

[tbordaz]

RC could be that the PR-CI instance is running an old version of nss.
At least it worth to try using nss-3.34 that is the version DS 1.3.7.8-1 is built with.

on PR-CI, it is using nss-3.33.0-1.0

on nss-3.34 http://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.34_release_notes
two new fields were added at the end of SSLChannelInfo ( originalKeaGroup , resumed )

DS is using a nss-3-34 structure

42 "ns-slapd" hit Breakpoint 4, handle_handshake_done (prfd=0x55f4ad71ddd0, clientData=0x55f4ad6c3d70)
at ldap/servers/slapd/auth.c:407
407     if ((slapd_ssl_getChannelInfo(prfd, &channelInfo, sizeof(channelInfo))) != SECSuccess) {
(gdb) print channelInfo
$15 = {length = 0, protocolVersion = 0, cipherSuite = 0, authKeyBits = 0, keaKeyBits = 0, creationTime = 0, lastAccessTime = 0, 
  expirationTime = 0, sessionIDLength = 0, sessionID = '\000' <repeats 31 times>, compressionMethodName = 0x0, 
  compressionMethod = ssl_compression_null, extendedMasterSecretUsed = 0, earlyDataAccepted = 0, keaType = ssl_kea_null, 
  keaGroup = 0, symCipher = ssl_calg_null, macAlgorithm = ssl_mac_null, authType = ssl_auth_null, signatureScheme = ssl_sig_none, 
  originalKeaGroup = 0, resumed = 0}

While in NSS it expects a smallest struct

0x00007f599d4b869b  35  in sslinfo.c
(gdb) x/20i 0x00007f599d4b8670
   0x7f599d4b8670 <SSL_GetChannelInfo>: push   %r15
   0x7f599d4b8672 <SSL_GetChannelInfo+2>:   push   %r14
   0x7f599d4b8674 <SSL_GetChannelInfo+4>:   push   %r13
   0x7f599d4b8676 <SSL_GetChannelInfo+6>:   push   %r12
   0x7f599d4b8678 <SSL_GetChannelInfo+8>:   mov    %edx,%r13d
   0x7f599d4b867b <SSL_GetChannelInfo+11>:  push   %rbp
   0x7f599d4b867c <SSL_GetChannelInfo+12>:  push   %rbx
   0x7f599d4b867d <SSL_GetChannelInfo+13>:  sub    $0xf8,%rsp
   0x7f599d4b8684 <SSL_GetChannelInfo+20>:  mov    %fs:0x28,%rax
   0x7f599d4b868d <SSL_GetChannelInfo+29>:  mov    %rax,0xe8(%rsp)
   0x7f599d4b8695 <SSL_GetChannelInfo+37>:  xor    %eax,%eax
   0x7f599d4b8697 <SSL_GetChannelInfo+39>:  lea    -0x4(%r13),%eax
=> 0x7f599d4b869b <SSL_GetChannelInfo+43>:  cmp    $0x6c,%eax
   0x7f599d4b869e <SSL_GetChannelInfo+46>:  ja     0x7f599d4b89a8 <SSL_GetChannelInfo+824>
   0x7f599d4b86a4 <SSL_GetChannelInfo+52>:  test   %rsi,%rsi
   0x7f599d4b86a7 <SSL_GetChannelInfo+55>:  mov    %rsi,%rbx
   0x7f599d4b86aa <SSL_GetChannelInfo+58>:  je     0x7f599d4b89a8 <SSL_GetChannelInfo+824>
   0x7f599d4b86b0 <SSL_GetChannelInfo+64>:  callq  0x7f599d4b3500 <ssl_FindSocket>
   0x7f599d4b86b5 <SSL_GetChannelInfo+69>:  test   %rax,%rax
   0x7f599d4b86b8 <SSL_GetChannelInfo+72>:  mov    %rax,%rbp
(gdb) print $eax
$17 = 116
(gdb) print 0x6c
$18 = 108

[tiran]

Wow, good catch :)

Smells like a packaging bug in 389-DS.

[tbordaz]

Yes, either a required version of dependency or need to build DS with 3.33. I am not sure...

[tbordaz]

DS ticket https://pagure.io/389-ds-base/issue/49498

[tiran]

PR #1520 will bump the required version to 1.3.7.9-1. It's scheduled for IPA 4.6.4, too. I'm closing this PR as duplicate.