[WIP] Upgrade rfc2307 schema #4502
Conversation
|
This PR is a work in progress. I'm running it against Rawhide because we unpushed 389-ds 1.4.3.5 from Fedora 32 to prevent the damage. However, testing on Rawhide currently needs modifications to how we run some services (chronyd and nis-domainname), thus there are patches that handle this part as well. nis-domainname.service is broken for Debian as well, according to @tjaalton, so I guess this will be a general fix. We can simply remove the test but I'd prefer to keep it because the change for nis-domainname is needed to even being able to install FreeIPA server on some platforms (it doesn't work without this fix in rootless podman containers, for example). |
freeipa-pr-ci
added
the
needs rebase
abbra
force-pushed
the
upgrade-rfc2307-schema
branch
from
703e475
to
83364d1
Compare
abbra
removed
the
needs rebase
|
This LGTM. Do you intend to backport this to ipa-4-8 as well? |
|
Not yet. This is not enough -- I have a larger fix that also accounts for removal of attributes/objectclasses from 99user.ldif. I need to collect all changes and update this PR. |
abbra
force-pushed
the
upgrade-rfc2307-schema
branch
from
83364d1
to
55e7a76
Compare
abbra
force-pushed
the
upgrade-rfc2307-schema
branch
2 times, most recently
from
325754f
to
44ff1f6
Compare
When RFC2307bis-based schema was added to FreeIPA and Fedora Directory in 2008, wrong OIDs were used for nisDomain attribute and nisDomainObject compared to the actual RFC2307bis schema. FreeIPA installed own schema version by default as rfc2307bis.ldif first and then as 15rfc2307bis.ldif. Fedora Directory (later 389-ds) kept it as 60nis.ldif in optional content and never installed into a working instance. Recently, 389-ds decided to unify various RFC 2307-related schema files and install them by default. As result, FreeIPA-provided nisDomain attribute and nisDomainObject objectclass started to conflict with the ones installed by default by 389-ds. All other attributes from 15rfc2307bis.ldif are not in use by FreeIPA. Since they are provided in 389-ds starting with 1.4.3.5 anyway, it makes no sense to keep them shipped. This commit updates 15rfc2307bis.ldif to only contain two entries which FreeIPA depends on. - attribute 'nisDomain' - objectclass 'nisDomainObject' The definition of 'nisDomain' attribute was updated to be compatible with 389-ds 1.4.3.5. RN: RFC 2307bis schema as shipped by FreeIPA was using incorrect OIDs RN: for nisDomain attribute and nisDomainObject. This difference makes RN: FreeIPA conflicting with 389-ds 1.4.3.5 or later. To solve the conflict, RN: nisDomain attribute and nisDomainObject OIDs were corrected. The RN: rest of the schema is removed as FreeIPA does not use it. RFC 2307bis RN: schema will come as part of 389-ds 1.4.3.5 or later. Fixes: https://pagure.io/freeipa/issue/8258 Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Related: https://pagure.io/freeipa/issue/8258 Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Chrony daemon tries to use adjtimex() which doesn't work in the container we run in Docker environment on Azure Pipelines. nis-domainname also tries to modify kernel-specific parameter that doesn't really work in runc-based containers. Use systemd container detection to avoid starting these services in the containers. Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
abbra
force-pushed
the
upgrade-rfc2307-schema
branch
from
44ff1f6
to
560431a
Compare
|
Azure pipeline fails because of new 389-ds-base 1.4.4.0 in Rawhide which fails to set itself up in Docker container due to a fix to https://pagure.io/389-ds-base/issue/49731 which enabled database default home directory to be on |
abbra
force-pushed
the
upgrade-rfc2307-schema
branch
2 times, most recently
from
0b0df4d
to
da2c619
Compare
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
abbra
force-pushed
the
upgrade-rfc2307-schema
branch
from
da2c619
to
82a67e1
Compare
|
This PR is currently on hold. 389-ds team decided to revert RFC2307compat schema promotion due to issues with upgrade in multi-master replication. |
freeipa-pr-ci
added
the
needs rebase
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
This issue has been automatically closed as stale it has not had recent activity. |
Update nisDomain and nisDomainObject to follow actual RFC2307bis schema
When RFC2307bis-based schema was added to FreeIPA and Fedora Directory in 2008, wrong OIDs were used for nisDomain attribute and nisDomainObject compared to the actual RFC2307bis schema. FreeIPA installed own schema version by default as rfc2307bis.ldif first and then as 15rfc2307bis.ldif. Fedora Directory (later 389-ds) kept it as 60nis.ldif in optional content and never installed into a working instance.
Recently, 389-ds decided to unify various RFC 2307-related schema files and install them by default. As result, FreeIPA-provided nisDomain attribute and nisDomainObject objectclass started to conflict with the ones installed by default by 389-ds.
All other attributes from 15rfc2307bis.ldif are not in use by FreeIPA. Since they are provided in 389-ds starting with 1.4.3.5 anyway, it makes no sense to keep them shipped.
This pull request updates 15rfc2307bis.ldif to only contain two entries which FreeIPA depends on.
The definition of 'nisDomain' attribute and 'nisDomainObject' objectclass were updated to be compatible with 389-ds 1.4.3.5+.
Fixes: http://pagure.io/freeipa/issue/8258
This issue needs resolution from 389-ds side as well, we aren't agreed fully yet how to solve multiple-master replication problem. For details please see https://pagure.io/389-ds-base/issue/50933, https://pagure.io/389-ds-base/pull-request/51009, https://pagure.io/389-ds-base/pull-request/50934#comment-115218, and two Fedora 32 bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1821548 and https://bugzilla.redhat.com/show_bug.cgi?id=1820176