| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
this is needed for the _msdcs zone
|
|
This file is no longer needed as the DisplaySpecifiers are now generated from
files provided by Microsoft.
|
|
|
|
Changed the provisioning to use the new script to parse the Microsoft-provided
DisplaySpecifiers LDIF file.
|
|
Created this script based on the existing ms_schema.py script.
- Removed some unnecessary transformations that are only necessary for schema
processing.
- Added capability to parse and properly output base64-encoded values.
- Removed unnecessary attributes based on what attributes were present (and also
what were explicitly removed) from display_specifiers.ldif.
|
|
The original license headers provided by Microsoft cannot be parsed as valid
LDIF.
Changed the license headers to be valid LDIF comments, and added a new header
section detailing the exact changes that were made to the original document.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
|
|
Like the schema, these are provided under the licence at the head of
the file, which is not the GPL, but allows us to distribute them with
Samba.
Andrew Bartlett
|
|
This is a perl script that does TSIG-GSS DNS updates against a AD
DC. The bind 9.5 nsupdate still doesn't seem to work with TSIG-GSS,
and we need a way to do DNS updates when we vampire a domain, so I
revived this ancient perl script and added a wrapper script that can
update DNS entries using our machine account credentials
|
|
on a vampire join we were not putting the right attributes and
objectclass on the secrets.ldb record
|
|
|
|
|
|
|
|
|
|
|
|
This might help finding why bug 6518 happens
|
|
|
|
|
|
|
|
|
|
We can't emulate them through the LDB changetype flags since they haven't the
same constants! The previous behaviour led to huge problems.
|
|
|
|
The parameters "lmNewHash" and/or "ntNewHash" could be NULL and when we perform
write operations on them (look below in the code) we could get SIGSEGVs!
|
|
|
|
Enhances the outputs in autogen.sh for both s3 and s4.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
|
|
The kernel may return a short read, so we must use read_data() to make sure we
read off the full buffer. If somethign bad happens we also need to kill the
inotify watch because the filedescriptor will return out of sync structures if
we read only part of the data.
|
|
|
|
|
|
|
|
|
|
This confused me for a second, this should not happen a second time :-)
|
|
All:
Please find attached a patch to fix the timestring and http_timestring
tests on hosts that have a negative UTC offset (west of the Prime Meridian).
Sincerely,
Andrew Kroeger
>From 8a8ca35edccf64aa98f2f3ae1469c4c27db8215e Mon Sep 17 00:00:00 2001
From: Andrew Kroeger <andrew@id10ts.net>
Date: Fri, 4 Sep 2009 01:31:50 -0500
Subject: [PATCH] util:tests: Correct time tests for negative UTC offsets.
The timestring and http_timestring tests were failing on hosts with negative
offsets from UTC. Due to the timezone offset, the returned values were back in
the year 1969 (before the epoch) and did not match the test patterns.
The correction computes the offset from UTC, and if it is negative that offset
is added onto the value given to the timestring() and http_timestring() calls so
that the returned values fall on 01-Jan-1970 and match the test pattern.
|
|
All:
Please find attached 2 patches to correct date/time parsing and output
in the Subunit processing. The first patch corrects the logic to
account for months being 0-based. The second corrects the time
formatting, as it is dealing with local, not "Z"ulu (UTC) time.
Sincerely,
Andrew Kroeger
>From 3cf81eea1309084a973359c7f6a2375d5d20a3f0 Mon Sep 17 00:00:00 2001
From: Andrew Kroeger <andrew@id10ts.net>
Date: Fri, 4 Sep 2009 01:24:00 -0500
Subject: [PATCH] selftest: Account for 0-based months in date parsing and printing.
|
|
|
|
metze
|
|
metze
|
|
A few weeks ago, I added some code to cifs.upcall to take the pid sent
by the kernel and use that to get the value of the $KRB5CCNAME
environment var for the process. That works fine on the initial mount,
but could be problematic on reconnect.
There's no guarantee on a reconnect that the process that initiates the
upcall will have $KRB5CCNAME pointed at the correct credcache. Because
of this, the current scheme isn't going to be reliable enough and we
need to use something different.
This patch replaces that scheme with one very similar to the one used by
rpc.gssd in nfs-utils. It searches the credcache dir (currently
hardcoded to /tmp) for a valid credcache for the given uid. If it finds
one then it uses that as the credentials cache. If it finds more than
one, it uses the one with the latest TGT expiration.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
|
|
The version of the unitest python module in Ubuntu Jaunty doesn't seem
to support this many level of subdirectories. Moving the tests up one
level solves the problem.
|
|
When a top level method in a module returns an error, it is supposed
to call ldb_module_done(). We ran across a case where this wasn't
done, and then found that in fact that are hundreds of similar cases
in our modules. It took Andrew and I a full day to work out that this
was the cause of a subtle segv in another part of the code.
To try to prevent this happening again, this patch changes
ldb_next_request() to catch the error by checking if a module
returning an error has called ldb_module_done(). If it hasn't then the
call is made on behalf of the module.
|
|
|
|
|
|
|
|
When we fail a ldbadd or ldbedit we should cancel the transaction to
prevent ldb giving a warning about having a open transaction in the
ldb destructor
|
|
|
|
When we get a double free abort from talloc it is often hard to work
out where the first free came from. This patch takes advantage of the
fact that _talloc_free() now takes a location the free was called from
to allow the double free abort code to print the location of the first
free that conflicts.
|
|
Kai, please check.
Guenther
|
|
Guenther
|
|
oplocks.
This one is subtle. There is a race condition where a signal can be
queued for oplock break, and then the file can be closed by the client
before the signal can be processed. Currently if this occurs we panic
(we can't match an incoming signal fd with a fsp pointer). Simply log
the error (at debug level 10 right now, might be too much) and then
return without processing the break request. It looks like there is
another race condition with this fix, but here's why it won't happen.
If the signal was pending (caused by a kernel oplock break from a
local file open), and the client closed the file and then re-opened
another file which happened to use the same file descriptor as the
file just closed, then theoretically the oplock break requests could
be processed on the wrong fd. Here's why this should be very rare..
Processing a pending signal always take precedence over an incoming
network request, so as long as the client close request is non-chained
then the break signal should always be harmlessly processed *before*
the open can be called. If the open is chained onto the close, and
the fd on the new open is the same as the old closed fd, then it's
possible this race will occur. However, all that will happen is that
we'll lose the oplock on this file. A shame, but not a fatal event.
Jeremy.
|
|
SA_INFO_QUEUE_COUNT *MUST* be a power of 2, in order for the ring buffer
wrap to work correctly at the 32 bit boundary. Thanks to Petr
Vandrovec <petr@vandrovec.name> for this.
|
|
So far it returns the ctr6 responce without proper linked attributes
support and metadata. A couple of improvements are the filter in the search
uses '(uSNChanged>=N)', added extended dn search support, non-replicated attributes
are excluded from the result.
|
