similar to: Previously extended schema not working in 4.4.0

Displaying 20 results from an estimated 2000 matches similar to: "Previously extended schema not working in 4.4.0"

2016 Apr 14
2
Previously extended schema not working in 4.4.0
Thank you, Andrew - I hadn't done so. (In a good way, I haven't yet had problems with samba that have caused me to delve quite so deeply into the DB :) so I'm not as familiar with the range of tools as I could be, sorry!) This has flagged up quite a few errors, all along the lines of: # samba-tool dbcheck --cross-ncs Checking 4079 objects MYOBJ=value,OU=myou,DC=mydomain,DC=org,DC=uk:
2016 Apr 14
0
Previously extended schema not working in 4.4.0
On 14 April 2016 at 13:37, Jonathan Hunter <jmhunter1 at gmail.com> wrote: > # samba-tool dbcheck --cross-ncs > Checking 4079 objects > MYOBJ=value,OU=myou,DC=mydomain,DC=org,DC=uk: 0x00290001 > MYOBJ=value,OU=myou,DC=mydomain,DC=org,DC=uk: 0x0029000a > MYOBJ=value,OU=myou,DC=mydomain,DC=org,DC=uk: 0x00290004 > MYOBJ=value,OU=myou,DC=mydomain,DC=org,DC=uk: 0x0009030e >
2016 Apr 14
2
Previously extended schema not working in 4.4.0
On Thu, 2016-04-14 at 18:07 +0100, Jonathan Hunter wrote: > On 14 April 2016 at 13:37, Jonathan Hunter <jmhunter1 at gmail.com> > wrote: > > > # samba-tool dbcheck --cross-ncs > > Checking 4079 objects > > MYOBJ=value,OU=myou,DC=mydomain,DC=org,DC=uk: 0x00290001 > > MYOBJ=value,OU=myou,DC=mydomain,DC=org,DC=uk: 0x0029000a > >
2016 Apr 11
2
Previously extended schema not working in 4.4.0
Thanks Rowland. In here, I can see the objects I have created using my schema extensions, but I cannot see the schema classes or attributes themselves; I don't know if that is the problem. I'm not sure if by running ldbedit on sam.ldb, this does not include the contents of CN=Schema,CN=Configuration,DC=mydomain,DC=... or if it does include this part of the AD tree and these items are
2016 Apr 14
0
Previously extended schema not working in 4.4.0
On Mon, 2016-04-11 at 21:23 +0100, Jonathan Hunter wrote: > Hi, > > About a year ago (I think I was using v4.2.x at the time), I extended > the > schema of my Samba AD. This worked just fine and since then I have > been > able to create and edit objects from my custom schema via ADSIEdit. > This > worked fine under 4.3.x as well - the last such object I successfully
2016 Apr 11
0
Previously extended schema not working in 4.4.0
On 11/04/16 21:23, Jonathan Hunter wrote: > Hi, > > About a year ago (I think I was using v4.2.x at the time), I extended the > schema of my Samba AD. This worked just fine and since then I have been > able to create and edit objects from my custom schema via ADSIEdit. This > worked fine under 4.3.x as well - the last such object I successfully > created was just over two
2016 Apr 15
2
Previously extended schema not working in 4.4.0
On Fri, 2016-04-15 at 00:32 +0100, Jonathan Hunter wrote: > Thank you Andrew, really appreciated. > > I have now run 'samba-tool dbcheck --cross-ncs --fix' and it has > successfully fixed some errors; there were 110 previously, however > there are still 69 remaining after a second pass of dbcheck --fix. > > The remaining errors seem to be mainly of this form: >
2016 Apr 14
0
Previously extended schema not working in 4.4.0
Thank you Andrew, really appreciated. I have now run 'samba-tool dbcheck --cross-ncs --fix' and it has successfully fixed some errors; there were 110 previously, however there are still 69 remaining after a second pass of dbcheck --fix. The remaining errors seem to be mainly of this form: ERROR: duplicate attributeID values for myattrib in replPropertyMetaData on
2016 Apr 12
2
Previously extended schema not working in 4.4.0
On 12 April 2016 at 07:31, Rowland penny <rpenny at samba.org> wrote: > > The schema is in another NC, so use the 'cross-ncs' switch to see the > schema. Thanks Rowland - adding --cross-ncs worked and I can now see the schema extensions using ldbedit. I can confirm that my schema extensions are definitely present, including as mentioned in the record below, which I
2016 Apr 13
1
Previously extended schema not working in 4.4.0
Thanks Rowland. On 12 April 2016 at 22:39, Rowland penny <rpenny at samba.org> wrote: > I have now remembered something, not sure if it helps but see here: > > https://lists.samba.org/archive/samba/2014-September/185225.html > > I definitely think this is in the same area - the issue I'm having also seems to be relating to replication - but I'm still not really sure
2023 Nov 29
1
LDAP_MATCHING_RULE_IN_CHAIN no longer working after upgrade?
Hi Jonathan and Andrew, > Reminder of my original LDAP query: > (& > (objectCategory=Person) > (sAMAccountName=*) > (memberOf:1.2.840.113556.1.4.1941:=CN=mygroup,OU=myou,DC=mydomain,DC=org) > ) I came across the same/similar issue yesterday and found the origin that triggered the issue (at least in my case). I've added a response to your bugzilla entry
2023 Nov 22
1
LDAP_MATCHING_RULE_IN_CHAIN no longer working after upgrade?
On Wed, 2023-11-22 at 17:33 +0000, Jonathan Hunter wrote: > On Wed, 22 Nov 2023 at 01:03, Andrew Bartlett < > abartlet at samba.org > > wrote: > > Are you sure that the ACLs on all the items in the chain should > > allow reading? > > It's an excellent question, thank you - I'd like to just say "Yes" > but > I will certainly check, as
2016 Sep 09
5
drs showrepl - Failed to bind to UUID - Undetermined error
Hi Guys, I have now updated to 4.5.0 - thank you to all the team for your efforts on this :) I was excited to read in the release notes that there were many replication improvements, and I have run 'samba-tool dbcheck --cross-ncs --fix' on all my DCs; there were many, many replPropertyMetaData and other errors which have now been found and fixed - thanks! However, I think something
2023 Nov 24
1
LDAP_MATCHING_RULE_IN_CHAIN no longer working after upgrade?
Thank you Andrew and Rowland. (Rowland - I tried 'samba-tool dsacl get', thank you! but found the output hard to decipher so I used ldp.exe on Windows instead in the end) On Wed, 22 Nov 2023 at 20:22, Andrew Bartlett <abartlet at samba.org> wrote: > > On Wed, 2023-11-22 at 17:33 +0000, Jonathan Hunter wrote: > > Are permissions checked in a hiearchical fashion, i.e. if
2014 Sep 23
1
Replication Failure
I have 2 DCs running 4.1.12 that have stopped replicating and are producing these error messages: from dc1: Failed to commit objects: WERR_GENERAL_FAILURE/NT_STATUS_INVALID_NETWORK_RESPONSE [2014/09/23 10:43:35.530000, 0] ../source4/rpc_server/drsuapi/getncchanges.c:1646(dcesrv_drsuapi_DsGetNCChanges) ../source4/rpc_server/drsuapi/getncchanges.c:1646: DsGetNCChanges 2nd replication on
2013 Aug 02
2
Joining DC
I am having some trouble joining a new samba4 server as a DC. I am pretty sure this stems from trying to use OpenChange and subsequently removing it. The new samba4 machine is running 4.0.7 and the existing is running 4.0.1. I am a little hesitant to do an in-place upgrade of the last working DC, so I wanted a replica to fall back on in case things go bad. Any help would be appreciated. On the
2014 Nov 11
1
creating OU with samba4
Hello guys! How I can create an organizationalUnit (OU)? Now I created an user into an OU already existent, but I need to create a new OU. I tried with: root at s1 :~#nano file.ldif dn: ou=MyOU,DC=dominio,DC=pdc,DC=cu objectClass: top objectClass: organizationalUnit ou: MyOU root at s1 :~#ldbadd --url=/var/lib/samba/private/sam.ldb file.ldif but when I search MyOU on the Active
2012 Dec 30
2
[LLVMdev] Cannot interchange "literal" and "identified" structs
With primitive types, I can interchange literal usage and type aliases in IR: %mytype = type i32 define void @foo(%mytype* %ptr) { %t1 = load *%mytype** %ptr store i32 *%t1*, *i32** %ptr ret void } But for structs, I cannot: %mytype = type { i32, i32 } define void @foo(%mytype* %ptr) { %t1 = load *%mytype** %ptr store* { i32, i32 }* %t1, *{ i32, i32 }** %ptr ret void }
2012 Jun 13
2
[LLVMdev] Structs passed by value
Hello, I'm trying to change the default behavior for how structures are passed to functions to use pass-by-value. Currently LLVM's default behavior is to pass structures by reference. I'm not disputing the benefits of this but I really want to change the default behavior for experimentation purposes. To this end I've changed the code in DefaultABIInfo::classifyArgumentType() to
2023 Nov 05
2
LDAP_MATCHING_RULE_IN_CHAIN no longer working after upgrade?
I'm quite confused by this one, as I can't see how this would happen.. but after upgrading my DCs from 4.11.10 to 4.18.5, LDAP searches don't seem to work if they use the :1.2.840.113556.1.4.1941: modifier, aka LDAP_MATCHING_RULE_IN_CHAIN. (Yes, it was a fairly big version jump.. Yes, I should have upgraded much earlier.. Yes, I know 4.19.x is out now as well) Here's a search that