Skip to content
GitLab
    • Explore Projects Groups Topics Snippets
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • fusiondirectory fusiondirectory
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 39
    • Issues 39
    • List
    • Boards
    • Service Desk
    • Milestones
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Terraform modules
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • fusiondirectoryfusiondirectory
  • fusiondirectoryfusiondirectory
  • Issues
  • #4185
Closed
Open
Issue created 9 years ago by bmortier@bmortierMaintainer
  • New related issue

  • New related issue

The configuration is lost after upgrading to 1.0.9.1

Closed

The configuration is lost after upgrading to 1.0.9.1

I upgraded my fusiondirectory installation on a preproduction machine and my configuration was lost (reverted to the standard one).

I've been able to fix it renaming the configuration object as follows:

dn: ou=fusiondirectory,dc=my,dc=domain
changetype: add
objectClass: organizationalUnit
ou: fusiondirectory

dn: cn=fusiondirectory,ou=configs,dc=my,dc=domain
changetype: modrdn
newrdn: cn=config
deleteoldrdn: 1
newsuperior: ou=fusiondirectory,dc=my,dc=domain

After that the configuration was almost OK (I've had to remove a password fdHook, but that goes into another bug).

(from redmine: issue id 4185, created on 2015-10-05, closed on 2015-10-08)

  • Relations:
    • relates #3317 (closed)
  • Changesets:
    • Revision 20949b86 by Côme Chilliet on 2015-10-06T12:21:33.000Z:
Fixes #4185 Added configuration dn check in --check-ldap
  • Revision accaadff by Côme Chilliet on 2015-10-06T12:22:29.000Z:
Fixes #4185 Added configuration dn check in --check-ldap
  • Revision 4ff33507 by Côme Chilliet on 2015-10-08T08:14:23.000Z:
Fixes #4185 Made error message clearer in case there are two configuration objects
  • Revision 985240a0 by Côme Chilliet on 2015-10-08T08:15:13.000Z:
Fixes #4185 Made error message clearer in case there are two configuration objects
  • Custom Fields:
    • Bug in version: 1.0.9

    Tasks

    ...

    Linked items
    0

    Link issues together to show that they're related. Learn more.

    Activity


    • bmortier
      bmortier @bmortier · 9 years ago
      Author Maintainer

      hello,

      yes this should be detected by the setup and migrated accordingly

      Cheers

      (from redmine: written on 2015-10-05)

      By bmortier on 2017-09-02T15:24:13 (imported from GitLab)

    • bmortier
      bmortier @bmortier · 9 years ago
      Author Maintainer

      Now the command «fusiondirectory-setup --check-ldap» should detect this case and propose to migrate it.

      (from redmine: written on 2015-10-06)

      By Côme Chilliet on 2017-09-02T15:24:13 (imported from GitLab)

    • bmortier
      bmortier @bmortier · 9 years ago
      Author Maintainer

      Little problem when I execute fusiondirectory-setup --check-ldap


      root@jessie-basic:~# fusiondirectory-setup --check-ldap Checking your LDAP tree Role cn=admin,ou=aclroles,dc=labo,dc=opensides,dc=be is an admin ACL role uid=fd-admin,ou=people,dc=labo,dc=opensides,dc=be is a valid admin ! ou=groups,dc=labo,dc=opensides,dc=be not found in your LDAP directory Do you want to create it ?: [Yes/No]? yes groups ! There is a configuration in cn=fusiondirectory,ou=configs,dc=labo,dc=opensides,dc=be in your LDAP directory ! The correct configuration dn is now cn=config,ou=fusiondirectory,dc=labo,dc=opensides,dc=be ! FusionDirectory will not read your configuration at its current dn Do you want to move and rename this entry? [Yes/No]? yes Already exists at /usr/sbin/fusiondirectory-setup line 1037, line 2.

      (from redmine: written on 2015-10-08)

      By Jonathan Swaelens on 2017-09-02T15:24:13 (imported from GitLab)

    • bmortier
      bmortier @bmortier · 9 years ago
      Author Maintainer

      The error message should be more clear now.

      (from redmine: written on 2015-10-08)

      By Côme Chilliet on 2017-09-02T15:24:13 (imported from GitLab)

    • bmortier
      bmortier @bmortier · 9 years ago
      Author Maintainer

      Close issue

      (from redmine: written on 2015-10-08)

      By Jonathan Swaelens on 2017-09-02T15:24:14 (imported from GitLab)

    • bmortier closed 7 years ago

      closed

      By Jonathan Swaelens on 2017-09-02T15:24:14 (imported from GitLab)

    • bmortier added Added label 6 years ago

      added Added label

      By bmortier on 2018-10-05T14:58:24 (imported from GitLab)

    Please register or sign in to reply
    Assignee
    bmortier's avatar
    bmortier
    Assign to
    Labels
    0
    None
    0
    None
      Assign labels
    • Manage project labels

    Milestone
    No milestone
    None
    Due date
    None
    None
    None
    Time tracking
    Confidentiality
    Not confidential

    You are going to turn on confidentiality. Only project members with at least the Reporter role, the author, and assignees can view or be notified about this issue.

    Lock issue
    Unlocked
    Participants
    Reference:

    Menu

    Explore Projects Groups Topics Snippets