This is an automated email from the git hooks/post-receive script.
spichugi pushed a commit to branch 389-ds-base-1.4.3
in repository 389-ds-base.
The following commit(s) were added to refs/heads/389-ds-base-1.4.3 by this push:
new cd7b96f Issue 51229 - Server Settings page gets into an unresponsive state
cd7b96f is described below
commit cd7b96f21d2f1e40a299d6d5a1b88bc52196dff3
Author: Simon Pichugin <spichugi(a)redhat.com>
AuthorDate: Tue Aug 18 15:52:32 2020 +0200
Issue 51229 - Server Settings page gets into an unresponsive state
Bug Description: If we switch the tab in Cockpit UI and restart
the instance - we can't go back to the default tab as it's in
an unresponsive loading state.
Fix Description: Do the update on ComponentDidUpdate instead of
ComponentDidMount.
https://pagure.io/389-ds-base/issue/51229
Reviewed by: mreynolds (Thanks!)
---
src/cockpit/389-console/src/server.jsx | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/cockpit/389-console/src/server.jsx b/src/cockpit/389-console/src/server.jsx
index 98cceb6..27193b7 100644
--- a/src/cockpit/389-console/src/server.jsx
+++ b/src/cockpit/389-console/src/server.jsx
@@ -35,7 +35,7 @@ export class Server extends React.Component {
this.selectNode = this.selectNode.bind(this);
}
- componentDidMount() {
+ componentDidUpdate() {
if (this.props.wasActiveList.includes(1)) {
if (this.state.firstLoad) {
this.loadConfig();
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
This is an automated email from the git hooks/post-receive script.
spichugi pushed a commit to branch 389-ds-base-1.4.2
in repository 389-ds-base.
The following commit(s) were added to refs/heads/389-ds-base-1.4.2 by this push:
new a50b014 Issue 51229 - Server Settings page gets into an unresponsive state
a50b014 is described below
commit a50b0149405ad7f851f1807fcda78ab927c4cbbc
Author: Simon Pichugin <spichugi(a)redhat.com>
AuthorDate: Tue Aug 18 15:52:32 2020 +0200
Issue 51229 - Server Settings page gets into an unresponsive state
Bug Description: If we switch the tab in Cockpit UI and restart
the instance - we can't go back to the default tab as it's in
an unresponsive loading state.
Fix Description: Do the update on ComponentDidUpdate instead of
ComponentDidMount.
https://pagure.io/389-ds-base/issue/51229
Reviewed by: mreynolds (Thanks!)
---
src/cockpit/389-console/src/server.jsx | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/cockpit/389-console/src/server.jsx b/src/cockpit/389-console/src/server.jsx
index 98cceb6..27193b7 100644
--- a/src/cockpit/389-console/src/server.jsx
+++ b/src/cockpit/389-console/src/server.jsx
@@ -35,7 +35,7 @@ export class Server extends React.Component {
this.selectNode = this.selectNode.bind(this);
}
- componentDidMount() {
+ componentDidUpdate() {
if (this.props.wasActiveList.includes(1)) {
if (this.state.firstLoad) {
this.loadConfig();
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
This is an automated email from the git hooks/post-receive script.
mreynolds pushed a commit to branch 389-ds-base-1.4.2
in repository 389-ds-base.
The following commit(s) were added to refs/heads/389-ds-base-1.4.2 by this push:
new 1b05d81 Issue 51165 - Set the operation start time for extended ops
1b05d81 is described below
commit 1b05d81a213dabed9601400797da4df51d5856ed
Author: Mark Reynolds <mreynolds(a)redhat.com>
AuthorDate: Mon Aug 17 09:20:07 2020 -0400
Issue 51165 - Set the operation start time for extended ops
Bug Description: Extended ops, likewhat is used in replication, were not
setting the operation start time. This caused invalid
values in the new access log keywords (wtime & optime)
Fix Description: Set the start start at the start of the extended op.
Fixes: https://pagure.io/389-ds-base/issue/51165
Reviewed by: mreynolds (one line commit rule)
---
ldap/servers/slapd/extendop.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ldap/servers/slapd/extendop.c b/ldap/servers/slapd/extendop.c
index f9f19d3..6aba026 100644
--- a/ldap/servers/slapd/extendop.c
+++ b/ldap/servers/slapd/extendop.c
@@ -221,6 +221,9 @@ do_extended(Slapi_PBlock *pb)
slapi_pblock_get(pb, SLAPI_OPERATION, &pb_op);
slapi_pblock_get(pb, SLAPI_CONNECTION, &pb_conn);
+ /* Set the time we actually started the operation */
+ slapi_operation_set_time_started(pb_op);
+
if (pb_conn == NULL || pb_op == NULL) {
send_ldap_result(pb, LDAP_OPERATIONS_ERROR, NULL, "param error", 0, NULL);
slapi_log_err(SLAPI_LOG_ERR, "do_extended",
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
This is an automated email from the git hooks/post-receive script.
mreynolds pushed a commit to branch 389-ds-base-1.4.3
in repository 389-ds-base.
The following commit(s) were added to refs/heads/389-ds-base-1.4.3 by this push:
new 25eaefe Issue 51165 - Set the operation start time for extended ops
25eaefe is described below
commit 25eaefe06cee20081c4bd89b2d3c762213a35652
Author: Mark Reynolds <mreynolds(a)redhat.com>
AuthorDate: Mon Aug 17 09:20:07 2020 -0400
Issue 51165 - Set the operation start time for extended ops
Bug Description: Extended ops, likewhat is used in replication, were not
setting the operation start time. This caused invalid
values in the new access log keywords (wtime & optime)
Fix Description: Set the start start at the start of the extended op.
Fixes: https://pagure.io/389-ds-base/issue/51165
Reviewed by: mreynolds (one line commit rule)
---
ldap/servers/slapd/extendop.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ldap/servers/slapd/extendop.c b/ldap/servers/slapd/extendop.c
index 4ebbeca..2c2f9c7 100644
--- a/ldap/servers/slapd/extendop.c
+++ b/ldap/servers/slapd/extendop.c
@@ -279,6 +279,9 @@ do_extended(Slapi_PBlock *pb)
slapi_pblock_get(pb, SLAPI_OPERATION, &pb_op);
slapi_pblock_get(pb, SLAPI_CONNECTION, &pb_conn);
+ /* Set the time we actually started the operation */
+ slapi_operation_set_time_started(pb_op);
+
if (pb_conn == NULL || pb_op == NULL) {
send_ldap_result(pb, LDAP_OPERATIONS_ERROR, NULL, "param error", 0, NULL);
slapi_log_err(SLAPI_LOG_ERR, "do_extended",
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
This is an automated email from the git hooks/post-receive script.
mreynolds pushed a commit to branch master
in repository 389-ds-base.
The following commit(s) were added to refs/heads/master by this push:
new dda3ab0 Issue 51165 - Set the operation start time for extended ops
dda3ab0 is described below
commit dda3ab0da56c42aa529bca35d7a05604f2076f75
Author: Mark Reynolds <mreynolds(a)redhat.com>
AuthorDate: Mon Aug 17 09:20:07 2020 -0400
Issue 51165 - Set the operation start time for extended ops
Bug Description: Extended ops, likewhat is used in replication, were not
setting the operation start time. This caused invalid
values in the new access log keywords (wtime & optime)
Fix Description: Set the start start at the start of the extended op.
Fixes: https://pagure.io/389-ds-base/issue/51165
Reviewed by: mreynolds (one line commit rule)
---
ldap/servers/slapd/extendop.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ldap/servers/slapd/extendop.c b/ldap/servers/slapd/extendop.c
index 4ebbeca..2c2f9c7 100644
--- a/ldap/servers/slapd/extendop.c
+++ b/ldap/servers/slapd/extendop.c
@@ -279,6 +279,9 @@ do_extended(Slapi_PBlock *pb)
slapi_pblock_get(pb, SLAPI_OPERATION, &pb_op);
slapi_pblock_get(pb, SLAPI_CONNECTION, &pb_conn);
+ /* Set the time we actually started the operation */
+ slapi_operation_set_time_started(pb_op);
+
if (pb_conn == NULL || pb_op == NULL) {
send_ldap_result(pb, LDAP_OPERATIONS_ERROR, NULL, "param error", 0, NULL);
slapi_log_err(SLAPI_LOG_ERR, "do_extended",
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
This is an automated email from the git hooks/post-receive script.
mreynolds pushed a commit to branch master
in repository 389-ds-base.
The following commit(s) were added to refs/heads/master by this push:
new 5afcbb0 Issue 50933 - Fix OID change between 10rfc2307 and 10rfc2307compat
5afcbb0 is described below
commit 5afcbb0d53e06aee85373df32c87bf830d41c251
Author: Mark Reynolds <mreynolds(a)redhat.com>
AuthorDate: Wed Aug 12 12:46:42 2020 -0400
Issue 50933 - Fix OID change between 10rfc2307 and 10rfc2307compat
Bug Description: 10rfc2307compat changed the OID for nisMap objectclass to
match the standard OID, but this breaks replication with
older versions of DS.
Fix Description: Continue to use the old(invalid?) oid for nisMap so that
replication does not break in a mixed version environment.
Fixes: https://pagure.io/389-ds-base/issue/50933
Reviewed by: firstyear & tbordaz(Thanks!!)
---
ldap/schema/10rfc2307compat.ldif | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ldap/schema/10rfc2307compat.ldif b/ldap/schema/10rfc2307compat.ldif
index 78c588d..8ba72e1 100644
--- a/ldap/schema/10rfc2307compat.ldif
+++ b/ldap/schema/10rfc2307compat.ldif
@@ -253,7 +253,7 @@ objectClasses: (
MAY ( nisNetgroupTriple $ memberNisNetgroup $ description )
)
objectClasses: (
- 1.3.6.1.1.1.2.9 NAME 'nisMap' SUP top STRUCTURAL
+ 1.3.6.1.1.1.2.13 NAME 'nisMap' SUP top STRUCTURAL
DESC 'A generic abstraction of a NIS map'
MUST nisMapName
MAY description
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.