Project

General

Profile

Actions

Task #7545

closed

Switch production LDAPs to cdist-managed alpine

Added by Timothée Floure almost 5 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Target version:
-
Start date:
12/31/2019
Due date:
% Done:

0%

Estimated time:
PM Check date:

Description

Our production LDAP nodes do not seem to be managed by cdist (anymore?): * No relevant mention in `grep -R __ungleich_ldap dot-cdist/` or `grep -R ldap1 dot-cdist/` * Deployed configuration do not exactly match `__ungleich_ldap` type.

=> Investigate and update dot-cdist to handle production ldap{1,2}.ungleich.ch

Actions #1

Updated by Timothée Floure almost 5 years ago

  • Status changed from New to In Progress
Actions #2

Updated by Timothée Floure almost 5 years ago

  • Status changed from In Progress to Waiting

I cleaned up and revamped the __ungleich_ldap type to run on alpine + deployed new ldap-stagin[1,2] nodes. I'm waiting to deploy a fix to __ungleich_nftables for firewalling and monitoring of the new setup.

I would like to move the production environment to this new deployment scheme next week when I am in Glarus.

Actions #3

Updated by Timothée Floure over 4 years ago

  • Subject changed from Investigate why production ldap{1,2}.ungleich.ch are not managed by dot-cdist to Switch production LDAPs to cdist-managed alpine

This is at the top of my TODO next time I come to Glarus, I don't want this to be delayed anymore.

Actions #4

Updated by Timothée Floure over 4 years ago

  • Status changed from Waiting to In Progress
Actions #5

Updated by Timothée Floure over 4 years ago

ldap3.ungleich.ch is now syncing with existing ldap1 and ldap2, although some objects fail to sync:

On ldap3.ungleich.ch:

Jul 24 11:42:57 alpine local4.debug slapd[26141]: syncrepl_message_to_entry: rid=002 mods check (objectClass: value #4 invalid per syntax)
Jul 24 11:42:57 alpine local4.debug slapd[26141]: do_syncrepl: rid=002 rc 21 retrying
Actions #6

Updated by Timothée Floure over 4 years ago

OUs sync properly but not user entries:

```
Jul 24 11:43:50 alpine local4.debug slapd26218: syncrepl_entry: rid=002 be_search (0)
Jul 24 11:43:50 alpine local4.debug slapd26218: syncrepl_entry: rid=002 ou=customer,dc=ungleich,dc=ch
Jul 24 11:43:50 alpine local4.debug slapd26218: syncrepl_entry: rid=002 entry unchanged, ignored (ou=customer,dc=ungleich,dc=ch)
Jul 24 11:43:50 alpine local4.debug slapd26218: syncrepl_message_to_entry: rid=002 DN: uid=kjg,ou=users,dc=ungleich,dc=ch, UUID: b6a5cd66-6630-1038-9dc5-01997400fff6
Jul 24 11:43:50 alpine local4.debug slapd26218: >>> dnPrettyNormal: <uid=kjg,ou=users,dc=ungleich,dc=ch>
Jul 24 11:43:50 alpine local4.debug slapd26218: <<< dnPrettyNormal: <uid=kjg,ou=users,dc=ungleich,dc=ch>, <uid=kjg,ou=users,dc=ungleich,dc=ch>
Jul 24 11:43:50 alpine local4.debug slapd26218: syncrepl_message_to_entry: rid=002 mods check (objectClass: value #4 invalid per syntax)
Jul 24 11:43:50 alpine local4.debug slapd26218: daemon: activity on 1 descriptor
Jul 24 11:43:50 alpine local4.debug slapd26218: daemon: activity on:
Jul 24 11:43:50 alpine local4.debug slapd26218:
Jul 24 11:43:50 alpine local4.debug slapd26218: daemon: epoll: listen=7 active_threads=0 tvp=zero
Jul 24 11:43:50 alpine local4.debug slapd26218: daemon: epoll: listen=8 active_threads=0 tvp=zero
Jul 24 11:43:50 alpine local4.debug slapd26218: daemon: epoll: listen=9 active_threads=0 tvp=zero
Jul 24 11:43:50 alpine local4.debug slapd26218: do_syncrepl: rid=002 rc 21 retrying
```

Actions #7

Updated by Timothée Floure over 4 years ago

Issue tracked down to `objectClass: ldapPublicKey`. The schema might have to be synced by hand / put into cdist.

Actions #8

Updated by Timothée Floure over 4 years ago

Diff on files in /etc/(open)ldap/schema:

I /tmp » diff a b
13a14,15
> guacConfigGroup.ldif
> guacConfigGroup.schema
17a20
> ldapns.schema
23a27,28
> openssh-ldap.ldif
> openssh-ldap.schema
28d32
< xaa

=> Adding to cdist.

Actions #9

Updated by Timothée Floure over 4 years ago

ldap3.ungleich.ch is now synced to ldap1 and ldap2. I will replace ldap2 and ldap1 in a few days. I'll announce and try to do it early in the morning.

Actions #10

Updated by Timothée Floure almost 4 years ago

  • Status changed from In Progress to Waiting
  • Priority changed from High to Normal

Small update: this has still to be processed.

Actions #11

Updated by Timothée Floure over 3 years ago

  • Status changed from Waiting to Closed

This is rotten - we will move the LDAP nodes to k8s. See #9473.

Actions

Also available in: Atom PDF