Nabble - Samba

Re: More info, please - was Re: Tridge's coffee contraption - photos

2009-12-01T04:40:58Z

> -----Original Message-----
> From: linux-bounces@... [mailto:linux-
> bounces@...] On Behalf Of Alastair D'Silva
> Sent: Tuesday, 1 December 2009 5:46 PM
> To: 'Paul Mackerras'
> Cc: 'Felix Karpfen'; linux@...; hugh@...
> Subject: Re: [clug] More info, please - was Re: Tridge's coffee
> contraption - photos
>
> Theres a good example on AVR's site:
>
> http://www.atmel.com/dyn/resources/prod_documents/doc2508.pdf

Hmm, going back to the application note above, they suggest that the
internal diodes are suitable for clamping an input up to 1000V, but require
external surge suppression for greater voltages. Assuming the PICs have
similar clamping (do they?), what would it take to add surge suppression to
their circuit? Would a MOV to earth do the trick? Is it a suitable
substitute for isolation?

Cheers,

--
Alastair D'Silva mob: 0423 762 819
Networking Consultant
New Millennium Networking web: http://www.newmillennium.net.au
skype: alastair_dsilva msn: alastair@...
blog: http://alastair.d-silva.org

--
linux mailing list
linux@...
https://lists.samba.org/mailman/listinfo/linux

From forum: Samba - linux

Re: domain printer issues

2009-12-01T04:36:51Z

On Mon, 2009-11-30 at 09:14 +1100, Brian May wrote:

> Daniel Sheridan wrote:
> > FWIW, I have the same problem here with Samba 3.4.2 and Windows XP
> > clients. In fact, one printer driver works via point'n'print, but
> > the others do not, so for now I've set all printers to use that one
> > driver (the PPDs are similar enough that it's not a problem).
>
> Ok, so maybe it was the upgrade from 3.2.5 to 3.4.2 (required for
> Windows 7) that broke things. The first few days seemed fine, so I
> thought it was OK, but maybe that is because nobody reported
> problems...

I'm currently blaming 3.4.x. Downgrading to 3.3.2 (the most recent 3.3
easily available as an Ubuntu package) makes the driver installation
work perfectly. Upgrading to 3.4.x breaks it again. Clean /var/lib/samba
and /var/cache/samba each time.

Dan.

--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

From forum: Samba - General

Re: More info, please - was Re: Tridge's coffee contraption - photos

2009-12-01T03:19:53Z

Alastair D'Silva writes:

> Theres a good example on AVR's site:
>
> http://www.atmel.com/dyn/resources/prod_documents/doc2508.pdf
>
> The example is for a mains coupled microcontroller (likely powered by a
> capacitive supply from the mains) - since we want isolation, I would add an
> optocoupler, and clamping diodes (the example uses the internal diodes of
> the microcontroller).

So, 1Mohm resistor from active to the photodiode anode, neutral to the
photodiode cathode, with a diode across the photodiode - is that the
idea?

I'm afraid that won't work very well at all. The current through the
photodiode will rise gradually from 0 to about 0.34 mA as we go
through the first quarter-cycle (5ms). If we assume a 4N25, it has a
typical current-transfer ratio of 0.7 at 10mA photodiode current (0.2
min), but that drops by a factor of about 5 once we get down to
0.5mA. So that means that we'll get a maximum of about 50uA of
collector current at the quarter-cycle point when the voltage is at a
maximum. Around the zero-crossing, we won't get enough collector
current in the phototransistor to detect the zero-crossing with any
reliability.

We could reduce the resistor a bit, but what we really need is to get
at least 1mA of current through the photodiode within about 100us of
the zero-crossing. That means a 10k resistor, which will end up
dissipating about 6W, which I don't consider acceptable.

> I'm not too sure where the microseconds figure is coming from, given that
> you are detecting a on a 50/60Hz signal. In order to have that resolution on
> your switching, you would need a PWM with at least 14 bits of resolution.
> The project is using an 8 bit PWM, which is an order of magnitude less than
> the resolution required for microseconds to be a problem.

Actually I can in principle control the position of the turn-on pulse
with 1us resolution. I should have said "tens of microseconds" rather
than "microseconds", though. I would like to do it in under 100us,
and certainly in under 300us, since that is the point at which there
is enough voltage to turn on the triac reliably.

Paul.
--
linux mailing list
linux@...
https://lists.samba.org/mailman/listinfo/linux

From forum: Samba - linux

Re: _ex_ fields in SMB_STRUCT_STAT

2009-12-01T03:05:44Z

On Tue, Dec 01, 2009 at 11:58:40AM +0100, Olivier Sessink wrote:
> I use SMB_STRUCT_STAT in the scannedonly vfs module, and I noticed all
> fields now have _ex_ in their name. What is the reason for this change,
> can I still use them like I previously did?

Yes, you can use the _ex fields as you did with the old
ones. The reason for the _ex is that on many platforms
things like "st_uid" or "st_dev" are macros pointing at
deeper structures, "struct stat" is not a direct struct with
direct st_uid & friends.

Volker

signature.asc (204 bytes) Download Attachment

From forum: Samba - samba-technical

Re: RFCs, Debian and Samba build dependencies

2009-12-01T03:05:35Z

On Tue, 2009-12-01 at 07:10 +0100, Christian Perrier wrote:

> Quoting Andrew Bartlett (abartlet@...):
> > Jelmer,
> >
> > I had to revert your commit to remove RFC files from Samba4 releases, as
> > it broke the build of our release tarballs - Heimdal uses python to
> > extract tables from the rfc files, and then uses them to build header
> > files.
> >
> > Can we work to see if we can find a solution that is acceptable to
> > Debian and does not break Samba to badly?
>
> Please find below the text of the original bug report we got about
> this (we got a similar bug report for samba 3, as it carries some
> samba4 sources).
>
> It proposes 3 solutions:
> 1) ask the author of the RFC to relicense it under a free license
> 2) repackage upstream sources without the offending documents
> 3) move the package to non free.
>
> 1) seems out of question as it would certainly require hairy
> discussions with RFC authors while.....I'm not sure we (samba pkg
> maintainers) are freeness-junkies enough to sustain it (IIRC I voted
> against the resolutions that were attempting to make non modificable
> documentation non free because I think this is more or less shooting
> self in feet).
>
> 2) was possible but we preferred working directly with upstream (as
> one of us is part of upstream) to remove the supposedly unmandatory
> documents
>
> 3) would be interesting..:-)

It seems the most viable solution at this time, given the self-defeating
policies in place... (Which is a pity, given the efforts we went to in
getting the Microsoft schema and display specifiers acceptably
licensed).

How has the Heimdal package deal with this?

(we get this 'problem' from Heimdal, because Heimdal's author quite
reasonably wants to use canonical sources for generated tables).

Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Cisco Inc.

signature.asc (196 bytes) Download Attachment

From forum: Samba - samba-technical

_ex_ fields in SMB_STRUCT_STAT

2009-12-01T02:54:52Z

Hi all,

I use SMB_STRUCT_STAT in the scannedonly vfs module, and I noticed all
fields now have _ex_ in their name. What is the reason for this change,
can I still use them like I previously did?

thanks,

Olivier

From forum: Samba - samba-technical

[Release Planning 3.4] Samba 3.4.4

2009-12-01T02:45:49Z

Hey folks,

Samba 3.4.4 is scheduled for Thursday, December 17.
That means, v3-4-stable will be frozen on December 10.
Please make sure, that important bug fixes will be picked in time.

Thanks!

Cheers,
Karolin

--
Samba http://www.samba.org
SerNet http://www.sernet.de
sambaXP http://www.sambaxp.org

attachment0 (205 bytes) Download Attachment

From forum: Samba - samba-technical

DO NOT REPLY [Bug 6946] New: Enable timestamp comparison with multiple file owners

2009-12-01T02:07:56Z

https://bugzilla.samba.org/show_bug.cgi?id=6946

Summary: Enable timestamp comparison with multiple file owners
Product: rsync
Version: 3.1.0
Platform: Other
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P3
Component: core
AssignedTo: wayned@...
ReportedBy: james@...
QAContact: rsync-qa@...

Currently if multiple users using group write permissions update the same
folder then they can't always update file timestamps. This is because the file
may be owned by a separate user. Furthermore, changing the timestamp may be
undesirable if files are being updated from various sources, since timestamps
moving backwards can confuse some software.

Disabling timestamp updates does not impair rsync's functionality but it can
severely reduce performance. It is forced to fully read each file, on both
sides of the transfer, in order to obtain a checksum.

I propose caching these checksums, against a file's timestamp, in order to
avoid this performance problem. This method does not require an update of the
file's timestamp. It would require a database of some sort linking files and
timestamps to the calculated checksum. Whenever a file's timestamp changed, the
checksum would need recalculating.

To operate efficiently this would need to operate at both sides of the
connection. Basically instead of reading a file to determine its timestamp the
cache would first be checked. If the cache did not contain a timestamp then it
would be calculated and stored in the cache for future reference.

I'd suggest specifying the cache location for local and remote connections via
a parameter initially.

I intend to have a go at adding this functionality myself, although I'd be very
interested to hear any comments. Also if anyone has done anything similar, or
if I am missing some simpler solution to this problem.

--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

From forum: Samba - rsync

Re: RFCs, Debian and Samba build dependencies

2009-12-01T02:05:23Z

On Tue, 2009-12-01 at 08:36 +0100, Karolin Seeger wrote:
> Hi Christian,
>
> On Tue, Dec 01, 2009 at 07:10:19AM +0100, Christian Perrier wrote:
> > Please find below the text of the original bug report we got about
> > this (we got a similar bug report for samba 3, as it carries some
> > samba4 sources).
>
> the RFCs are removed by the create-tarball script for s3. So this
> shouldn't be a problem in s3 tarballs any longer.

Fortunately we are now agreed to remove source4 entirely from Samba 3.5
releases, so it should not be a problem that it won't build without
them :-)

Andrew Bartlett

--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Cisco Inc.

signature.asc (196 bytes) Download Attachment

From forum: Samba - samba-technical

Re: Tridge's coffee contraption - photos

2009-12-01T01:51:43Z

> -----Original Message-----
> From: linux-bounces@... [mailto:linux-
> bounces@...] On Behalf Of David Cottrill
> Sent: Tuesday, 1 December 2009 6:33 PM
> To: Alastair D'Silva
> Cc: linux@...; Felix Karpfen; Paul Mackerras;
> hugh@...
> Subject: Re: [clug] Tridge's coffee contraption - photos
>
> Now that we are truly off topic I think I see Pauls point.
> However... by calculating the inherent delay in the RC circuit formed
> by the series resistor and the input capactance we can adjust the PID
> output timer on the triac to account for this known error and it will
> likely be small enough that it will not be a problem.
>
> If I've made any dud assumptions then let me know.
>

You are right, there will be some lag. However, this lag is also in place in
the transformer situation, all other things being equal. From the source's
point of view, the impedance of the load will be similar (the variance
coming from there not being a big inductor in series with the voltage
source) - the input capacitance of the microcontroller and the (effective)
series resistance from the source will be identical.

(Disclaimer: I haven't touched maths to any significant degree since uni, so
please double check my work :) )

You are also right, in that delays can be accounted for in software. In
fact, since there is a feedback loop in place, this is already done for you
:) The end effect of any delay that I can see would be to clamp the maximum
duty cycle to something less than 100%. Assuming a 1ms delay per half cycle
(which would be huge), you would only get 90% time on, lost from the part of
the wave near 0V. Since power is proportional to the square of the voltage
(in a purely resistive load, which we'll say the hot air gun is for
simplicity sake), we get power loss = sin(0.1 * pi)^2 = 0.095, or 10%.

It would be interesting to hook up the original circuit to a CRO to see what
the effective duty cycle is at 100% power.

--
linux mailing list
linux@...
https://lists.samba.org/mailman/listinfo/linux

From forum: Samba - linux

Re: Need some help with LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169)

2009-12-01T01:18:24Z

Hi Bill,
There are no issues with the LDAP_SERVER_SD_FLAGS_OID when sent with an LDAP modify - it behaves as documented. The issue here is that it does not seem to have any effect when sent with an LDAP add. Therefore I cannot send you a dump of the object before modification, because it hasn't been created yet :).
Again, just to be sure we understand the issue:
When I modify the descriptor of an existing object providing this control, the server behaves as documented, everything is in order.
When I create a new object and provide the control, the control does not have any effect even though it is mentioned in the documentation that it operates on add as well. The new object's descriptor is created as though the control is not sent at all, and no error is returned. I do provide a security descriptor with the request, so its not the case where it is ignored...
If you like, I can send you some script of the way I am creating the object, and a network capture?

About the second question - I did look in ADTS for explanation, but I guess I missed it :). Thank a lot, I believe that answers the question.

Regards,
Nadya
----- Original Message -----
> From: Bill Wesse <billwe@...>
> To: Nadezhda Ivanova <nadezhda.ivanova@...>
> Cc: cifs-protocol@... <cifs-protocol@...>
> Sent: Monday, November 30, 2009 9:51:11 PM GMT+0200 Europe;Athens
> Subject: RE: [cifs-protocol] Need some help with LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169)

> > Hello Nadya - here is the response information for your questions. The
> first question will undoubtedly need to be handled under a new service
> request. For the second one, please let me know if that answers
> everything (if so, I will consider SRX091119600169 resolved).
>
> =======================================================================
> =======
> Question:
>
> When I execute the test against a Win2008, domain functional level
> 2008, it actually fails. All of the fields of the provided security
> descriptor are applied, not only the ones specified by the control.
> Maybe there is some additional configuration and condition for the
> control to be taken into account?
>
> Response:
>
> I have examined our implementation of this, and find no relevant
> changes. I did not find anything involved with configuration that
> should affect the way security descriptor flags are treated. The LDAP
> server code handling for LDAP_SERVER_SD_FLAGS_OID is essentially
> unchanged from Windows 2003 through 2008R2.
>
> Could you please send me an 'dsacls CN=,...' dump of an updated object
> (before and after the update), as well as a network capture? I will
> create a new case upon receipt of that data.
>
> =======================================================================
> =======
> Question:
>
> I do not get LDAP_UNAVAILABLE_CRIT_EXTENSION, as described in
> http://msdn.microsoft.com/en-us/library/aa367025(VS.85).aspx Using
> Controls
>
> Each extended control has a Criticality flag, represented by the
> ldctl_iscritical field of the LDAPControl structure. If this flag
> is set to
> TRUE, then the server will return a LDAP_UNAVAILABLE_CRIT_EXTENSION
> error
> code if the server does not support the request control when
> attempting an
> API call that includes the control. Using extended controls on a
> LDAP
> version 2 connection will also fail with this return code.
>
> Response:
>
> Behavior of an update operation when this control is specified is
> detailed in [MS-ADTS], section 7.1.3.2.
>
> If, during an update, no SD is provided and the control is provided,
> then the control is used to specify which (non-existent) parts of the
> (non-existent) SD are to be used in the update operation. Since that
> specifies no actual change in the update operation (that is, no new
> data for an SD is provided), the control is trivially being honored,
> and as such no error is returned, regardless of criticality.
> Essentially, the update operation (at least with respect to SDs) is a
> no-op.
>
> Explicitly, during an add operation, if no security descriptor is
> provided by the client, then specifying what parts of the security
> descriptor are relevant has no observable behavior, and is not an
> error.
>
> LDAP_CONTROL_REFERRALS (OID 1.2.840.113556.1.4.616) is never passed to
> the server, and the server neither parses nor understands it. It
> affects only the client side implementation of an LDAP client library.
> Specifically, it controls whether a client library should chase
> referrals returned by a DC or not. As this is client behavior only
> and not part of the server protocol, it does not fall under the scope
> of MS-ADTS.
>
>
> Regards,
> Bill Wesse
> MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> 8055 Microsoft Way
> Charlotte, NC 28273
> TEL: +1(980) 776-8200
> CELL: +1(704) 661-5438
> FAX: +1(704) 665-9606
>
> -----Original Message-----
> From: Bill Wesse
> Sent: Friday, November 20, 2009 3:25 PM
> To: 'Nadezhda Ivanova'
> Cc: cifs-protocol@...
> Subject: RE: [cifs-protocol] Need some help with
> LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169)
>
> Glad to help. I will look into the security descriptor handling. Have
> you seen anything different at lower functional levels (like only the
> specified sd parts being applied)?
>
> Regards,
> Bill Wesse
> MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> 8055 Microsoft Way
> Charlotte, NC 28273
> TEL: +1(980) 776-8200
> CELL: +1(704) 661-5438
> FAX: +1(704) 665-9606
>
> -----Original Message-----
> From: Nadezhda Ivanova [mailto:nadezhda.ivanova@...]
> Sent: Friday, November 20, 2009 1:21 PM
> To: Bill Wesse
> Cc: cifs-protocol@...
> Subject: Re: [cifs-protocol] Need some help with
> LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169)
>
> Hi Bill,
> Thank you for your answer! The problem is, when I execute the test
> against a Win2008, domain functional level 2008, it actually fails.
> All of the fields of the provided security descriptor are applied, not
> only the ones specified by the control. Maybe there is some additional
> configuration and condition for the control to be taken into account?
>
> Best Regards,
> Nadya
> ----- Original Message -----
> > From: Bill Wesse <billwe@...>
> > To: Nadezhda Ivanova <nadezhda.ivanova@...>
> > Cc: cifs-protocol@... <cifs-protocol@...>
> > Sent: Friday, November 20, 2009 7:22:08 PM GMT+0200 Europe;Athens
> > Subject: RE: [cifs-protocol] Need some help with
> LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169)
>
> > > Just following up to clarify where we are on this, since I missed
> a
> > beat yesterday, and didn't consider the 'add with security' case
> > fully.
> >
> > I think the first question is the only open item.
> >
> >
> =======================================================================
>
> > =======
> > Q: I do not get LDAP_UNAVAILABLE_CRIT_EXTENSION, as described in
> > http://msdn.microsoft.com/en-us/library/aa367025(VS.85).aspx
> > Using Controls
> > Each extended control has a Criticality flag, represented by
> the
> > ldctl_iscritical field of the LDAPControl structure. If this flag
>
> > is set to
> > TRUE, then the server will return a
> LDAP_UNAVAILABLE_CRIT_EXTENSION
> > error
> > code if the server does not support the request control when
> > attempting an
> > API call that includes the control. Using extended controls on a
> > LDAP
> > version 2 connection will also fail with this return code.
> >
> > A: I am awaiting confirmation on the following:
> >
> > LDAP_CONTROL_REFERRALS is required with LDAP_SERVER_SD_FLAGS_OID;
>
> > if not present,
> > LDAP_UNAVAILABLE_CRIT_EXTENSION is returned.
> >
> >
> =======================================================================
>
> > =======
> > Q: Is this control relevant for an LDAP add request?
> > A: Yes (per your test).
> >
> >
> =======================================================================
>
> > =======
> > Q: What should be the behavior for an LDAP add?
> > A: Application of the provided security descriptor to the new
> object.
> > Your test matches perfectly:
> >
> > I create an OU, providing a descriptor that has OwnerSid, GroupSid,
> > Sacl and Dacl, and the OWNER_SECURITY_INFORMATION flag raised in the
>
> > control. I read back the descriptor of the OU. I expect that the
> ACEs
> > provided in the Sacl and Dacl will not be part of the OUs descriptor,
>
> > and the GroupSid will be the default. However, all 4 fields contain
> > the data provided with the add request. The same test worked great
> for
> > the modify request. I hope this info helps.
> >
> >
> > Regards,
> > Bill Wesse
> > MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> > 8055 Microsoft Way
> > Charlotte, NC 28273
> > TEL: +1(980) 776-8200
> > CELL: +1(704) 661-5438
> > FAX: +1(704) 665-9606
> >
> >
> > -----Original Message-----
> > From: Bill Wesse
> > Sent: Friday, November 20, 2009 10:07 AM
> > To: 'Nadezhda Ivanova'
> > Cc: cifs-protocol@...
> > Subject: RE: [cifs-protocol] Need some help with
> > LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169)
> >
> > The info indeed helps - and you are completely correct concerning
> the
> > LDAP_SERVER_SD_FLAGS_OID control. I took the references I supplied
> too
> > literally - and didn't read far enough - of course that would be
> > necessary to set security on a new object, if the default is not
> what
> > is needed.
> >
> > I am still waiting on information about the conditions that would
> > return LDAP_UNAVAILABLE_CRIT_EXTENSION.
> >
> > Regards,
> > Bill Wesse
> > MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> > 8055 Microsoft Way
> > Charlotte, NC 28273
> > TEL: +1(980) 776-8200
> > CELL: +1(704) 661-5438
> > FAX: +1(704) 665-9606
> >
> > -----Original Message-----
> > From: Nadezhda Ivanova [mailto:nadezhda.ivanova@...]
> > Sent: Thursday, November 19, 2009 4:42 PM
> > To: Bill Wesse
> > Cc: cifs-protocol@...
> > Subject: Re: [cifs-protocol] Need some help with
> > LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169)
> >
> > P.S. In the links you sent me,
> > http://msdn.microsoft.com/en-us/library/cc223323(PROT.13).aspx
> > add is mentioned as well:
> > "It is also used with LDAP Add and Modify requests to control the
> > portion of a Windows security descriptor to modify. The DC modifies
> > only the specified portion of the security descriptor."
> >
> > Perhaps my test is wrong? I create an OU, providing a descriptor
> that
> > has OwnerSid, GroupSid, Sacl and Dacl, and the
> > OWNER_SECURITY_INFORMATION flag raised in the control. I read back
> the
> > descriptor of the OU. I expect that the ACEs provided in the Sacl
> and
> > Dacl will not be part of the OUs descriptor, and the GroupSid will
> be
> > the default. However, all 4 fields contain the data provided with
> the
> > add request. The same test worked great for the modify request. I
> hope
> > this info helps.
> >
> > Regards,
> > Nadya
> > ----- Original Message -----
> > > From: cifs-protocol-bounces@...
> > <cifs-protocol-bounces@...>
> > > To: billwe@... <billwe@...>, Nadezhda Ivanova
> > <nadezhda.ivanova@...>
> > > Cc: cifs-protocol@... <cifs-protocol@...>
> > > Sent: Thursday, November 19, 2009 11:30:59 PM GMT+0200
> Europe;Athens
> > > Subject: Re: [cifs-protocol] Need some help with
> > LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169)
> >
> > > > Hi Bill,
> > > It's definitely not just used for searches. Some management tools
> > such
> > > as Active Directory Users and Computers send this control along
> with
> > a
> > > modify request - we have a bug about this in bugzilla:
> > > https://bugzilla.samba.org/show_bug.cgi?id=6401
> > > I have proven with tests that in modify requests the control is
> > taken
> > > into account, and only the specified parts of the descriptor are
> > > modified. I have already implemented it for the modify request.
> > > However, I cannot implement it for the add request until I know if
>
> > > there is actually anything to be done for add, and if there is,
> how
> > it
> > > should work. My tests have shown no effect for add requests, but
> > since
> > > it is mentioned in the MS-ADTS, I thought maybe I am missing
> > > something. So, this only blocks my progress if there is something
> to
> >
> > > be done for the add request, otherwise, it does not. It is not
> very
> > > urgent, though, it can wait a bit if you have other priorities.
> > >
> > > Regards,
> > > Nadya
> > > ----- Original Message -----
> > > > From: Bill Wesse <billwe@...>
> > > > To: Nadezhda Ivanova <nadezhda.ivanova@...>
> > > > Cc: cifs-protocol@... <cifs-protocol@...>
> > > > Sent: Thursday, November 19, 2009 10:23:06 PM GMT+0200
> > Europe;Athens
> > > > Subject: RE: Need some help with LDAP_SERVER_SD_FLAGS_OID
> control
> > > (SRX091119600169)
> > >
> > > > > Nadya - I don't think the LDAP_SERVER_SD_FLAGS_OID control
> > should
> > > have
> > > > any effect during an add operation, since the flags for the
> > control
> > > > indicate which security descriptor parts to retrieve during a
> > search,
> > >
> > > > which should explain why LDAP_UNAVAILABLE_CRIT_EXTENSION is not
> > > being
> > > > returned (assuming the add succeeded).
> > > >
> > > > I have filed a TDI to obtain authoritative information
> concerning
> > > this,
> > > > and will update you with results as they develop.
> > > >
> > > > Could you advise me concerning how much this impacts progress on
>
> > > your
> > > > implementation?
> > > >
> > > > References:
> > > >
> > > > [MS-ADTS] 3.1.1.3.4.1.11 LDAP_SERVER_SD_FLAGS_OID
> > > > http://msdn.microsoft.com/en-us/library/cc223323(PROT.13).aspx
> > > >
> > > > The LDAP_SERVER_SD_FLAGS_OID control is used with an LDAP Search
> > > > request to control the portion of a Windows Security Descriptor
> to
> > > > retrieve.
> > > >
> > > > LDAP_SERVER_SD_FLAGS_OID Control Code
> > > > http://msdn.microsoft.com/en-us/library/aa366987(VS.85).aspx
> > > >
> > > > The security information flags indicate which security
> descriptor
> > > > parts to retrieve during a search.
> > > >
> > > > Regards,
> > > > Bill Wesse
> > > > MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL
> TEAM
> > > > 8055 Microsoft Way
> > > > Charlotte, NC 28273
> > > > TEL: +1(980) 776-8200
> > > > CELL: +1(704) 661-5438
> > > > FAX: +1(704) 665-9606
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Bill Wesse
> > > > Sent: Thursday, November 19, 2009 2:07 PM
> > > > To: 'Nadezhda Ivanova'
> > > > Cc: cifs-protocol@...
> > > > Subject: RE: Need some help with LDAP_SERVER_SD_FLAGS_OID
> control
> > > > (SRX091119600169)
> > > >
> > > > Hi Nadya - I will be your contact for this one. Here is the case
> > > > number:
> > > >
> > > > SRX091119600169: [MS-ADTS] 7.1.3.2 LDAP_SERVER_SD_FLAGS_OID
> > > >
> > > > I will begin my investigation today!
> > > >
> > > > Regards,
> > > > Bill Wesse
> > > > MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL
> TEAM
> > > > 8055 Microsoft Way
> > > > Charlotte, NC 28273
> > > > TEL: +1(980) 776-8200
> > > > CELL: +1(704) 661-5438
> > > > FAX: +1(704) 665-9606
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Nadezhda Ivanova [mailto:nadezhda.ivanova@...]
> > > > Sent: Thursday, November 19, 2009 12:34 PM
> > > > To: Interoperability Documentation Help
> > > > Cc: cifs-protocol@...
> > > > Subject: Need some help with LDAP_SERVER_SD_FLAGS_OID control
> > > >
> > > > Hello,
> > > > I have been working on the implementation of
> > > LDAP_SERVER_SD_FLAGS_OID
> > > > in Samba, and I have a question. Is this control relevant for an
>
> > > LDAP
> > > > add request? I have been testing against Win2008. Adding this
> > > control
> > > > to the request does not seem to have any effect. When I set it
> to
> > > > Critical, I do not get LDAP_UNAVAILABLE_CRIT_EXTENSION, as
> > > described
> > > > in
> > http://msdn.microsoft.com/en-us/library/aa367025%28VS.85%29.aspx
> > > > At the same tine, in MS-ADTS, section 7.1.3.2 SD Flags Control,
> it
> > > > says:
> > > > "When performing an LDAP operation (add, modify or search), the
> > > client
> > > > may supply an SD flags
> > > > control LDAP_SERVER_SD_FLAGS_OID with the operation."
> > > >
> > > > So, if the control is valid for an LDAP add, what should be the
> > > > behavior?
> > > >
> > > > Best Regards,
> > > > Nadezhda Ivanova
> > > _______________________________________________
> > > cifs-protocol mailing list
> > > cifs-protocol@...
> > > https://lists.samba.org/mailman/listinfo/cifs-protocol

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

From forum: Samba - cifs-protocol

JCIFS, Kerberos

2009-12-01T00:52:59Z

Hi.

I would not like anyone to spend a long time on this, but could someone
briefly outline what are the differences in authentication mechanisms
between a Kerberos and non-Kerberos situation, from a jCIFS point of view ?
(Or provide some pointers to that effect, other than a pure Kerberos
introduction).
I have a superficial knowledge of Kerberos in general, and a somewhat
better understanding of the NTLM authentication mechanism, but what I do
not entirely understand is why there have to be 2 separate versions of
JCIFS authentication to handle the Kerberos case.

Thanks in advance
André

From forum: Samba - jcifs

Password Change from Windows machines ("You do not have permission to change your password")

2009-12-01T00:26:29Z

Hello,
I just wasted several hours trying to figure out why I could not
change Samba passwords from Windows XP computers. I'm posting here so
that there is some form of documentation about this on the web.

My setup is basically this:

- Samba 3.3.2 (running under Ubuntu 9.04)
- OpenLDAP user database
- Full O.S. support for OpenLDAP auth, using nsswitch and PAM.
(My client LDAP config was installed using *auth-client-config *as
per https://help.ubuntu.com/9.04/serverguide/C/openldap-server.html,
plus some tweaking in /etc/smbldap-tools/. )

I can ssh into the box as a system user that exists only in LDAP
(and not in /etc/passwd). I can also change my LDAP password at the
bash prompt by typing "passwd" (via PAM), or smbldap-passwd, or
smbpasswd. That all works as per the documentation.

The problem: I could not change my password from Windows boxen.
They kept giving me "You do not have permission to change your password."

I found the solution by cranking up the log level to 10. I
eventually found this golden snippet in all the noise:

[2009/11/30 23:23:37, 4] auth/pampass.c:smb_pam_chauthtok(670)
smb_pam_chauthtok: PAM: Password Change for User: dereks
[2009/11/30 23:23:37, 10] auth/pampass.c:smb_pam_passchange_conv(284)
smb_pam_passchange_conv: starting converstation for 1 messages
[2009/11/30 23:23:37, 10] auth/pampass.c:smb_pam_passchange_conv(312)
smb_pam_passchange_conv: Processing message 0
[2009/11/30 23:23:37, 10] auth/pampass.c:smb_pam_passchange_conv(346)
smb_pam_passchange_conv: PAM_PROMPT_ECHO_OFF: PAM said: New password:
[2009/11/30 23:23:37, 10] auth/pampass.c:smb_pam_passchange_conv(352)
smb_pam_passchange_conv: PAM_PROMPT_ECHO_OFF: trying to match |*enter
new * password:*| to |New password:|
[2009/11/30 23:23:37, 10] auth/pampass.c:smb_pam_passchange_conv(352)
smb_pam_passchange_conv: PAM_PROMPT_ECHO_OFF: trying to match |*retype
new * password:*| to |New password:|
[2009/11/30 23:23:37, 10] auth/pampass.c:smb_pam_passchange_conv(352)
smb_pam_passchange_conv: PAM_PROMPT_ECHO_OFF: trying to match
|*password updated successfully*| to |New password:|
[2009/11/30 23:23:37, 10] auth/pampass.c:smb_pam_passchange_conv(352)
smb_pam_passchange_conv: PAM_PROMPT_ECHO_OFF: trying to match || to
|New password:|
[2009/11/30 23:23:37, 3] auth/pampass.c:smb_pam_passchange_conv(370)
smb_pam_passchange_conv: Could not find reply for PAM prompt: New
password:
[2009/11/30 23:23:37, 0] auth/pampass.c:smb_pam_chauthtok(699)
PAM: User not known to PAM
[2009/11/30 23:23:37, 2] auth/pampass.c:smb_pam_error_handler(77)
smb_pam_error_handler: PAM: Password Change Failed : User not known to
the underlying authentication module
[2009/11/30 23:23:37, 0] auth/pampass.c:smb_pam_passchange(861)
smb_pam_passchange: PAM: Password Change Failed for user dereks!
[2009/11/30 23:23:37, 4] auth/pampass.c:smb_pam_end(450)
smb_pam_end: PAM: PAM_END OK.
[2009/11/30 23:23:37, 3] smbd/sec_ctx.c:pop_sec_ctx(432)
pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 2
[2009/11/30 23:23:37, 3] smbd/sec_ctx.c:pop_sec_ctx(432)
pop_sec_ctx (4202, 513) - sec_ctx_stack_ndx = 1
[2009/11/30 23:23:37, 5]
rpc_server/srv_samr_nt.c:_samr_ChangePasswordUser2(1907)
_samr_ChangePasswordUser2: 1907
samr_ChangePasswordUser2: struct samr_ChangePasswordUser2
out: struct samr_ChangePasswordUser2
result : NT_STATUS_ACCESS_DENIED

Here you can see that the "password chat" was attempting to
communicate with PAM in a fashion similar to 'expect'. My "passwd chat"
setting in /etc/samba/smb.conf was not correct, so the password change
failed. The resulting error code "NT_STATUS_ACCESS_DENIED" caused
Windows to print that useless "You do not have permission to change your
password" dialog box, and sent me on a wild goose chase.

The comments in the smb.conf that come with Ubuntu say this:

# For Unix password sync to work on a Debian GNU/Linux system, the following
# parameters must be set (thanks to Ian Kahan
<<kahan@...> for
# sending the correct chat script for the passwd program in Debian Sarge).
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n
*Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .

# This boolean controls whether PAM will be used for password changes
# when requested by an SMB client instead of the program listed in
# 'passwd program'. The default is 'no'.
pam password change = yes

My reading of these comments is that either "passwd program" with
matching "passwd chat" will be used, or else "pam password change = yes"
will be used. In my troubleshooting, I commented out either the first
one (to use PAM), or else the latter one (to use /usr/bin/passwd with
the chat setting). That interpretation was also consistent with all the
Samba docs and forum postings I found online.

But, as shown in the logs above, the correct answer was "pam
password change = yes" with a corrected "passwd chat" setting. Here is
a setting that works for me on Ubuntu 9.04:

passwd program = /usr/bin/passwd %u
passwd chat = *New\spassword:* %n\n *New\spassword:* %n\n
*password\supdated\ssuccessfully* .
pam password change = yes

I deduced that customized chat script by running "/usr/bin/passwd
username" at the bash prompt to see what happens.

Alternatively, I now know that the default setting for "passwd chat"
setting will work with PAM, if I comment out the broken one that comes
with the Ubuntu (and Debian?) smb.conf file and also comment out the
"passwd program = ..." line.

In short, the combination of these issues made troubleshooting time
consuming and difficult:

- Misleading error message ("You do not have permission to change your
password.")
- Misleading docs that imply EITHER "pam password change = yes" OR
"passwd program" with "passwd chat"
- An outdated, incorrect setting for "passwd chat" in the Debian and
Ubuntu smb.conf file that does not work with /usr/bin/passwd
- Missing Samba docs to explain "passwd chat" might be used, even in the
case of "pam password change = yes"
- Missing Samba docs to explain the default setting for "passwd chat"
will work with PAM, in the case of "pam password change"

Hopefully this will help somebody else avoid the same mistake.

Thank You,
Derek Simkowiak

--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

From forum: Samba - General

Re: Unknown panic actions

2009-11-30T23:54:21Z

On Thu, Nov 26, 2009 at 01:54:42PM +0100, Ralph Kutschera wrote:

> Volker Lendecke schrieb:
>> On Tue, Nov 24, 2009 at 04:59:19PM +0100, Ralph Kutschera wrote:
>>> Well, after installing logwatch I found the following. Maybe this
>>> can help?
>>
>> What version of Unix and what version of Samba are you
>> running?
>
> # cat /proc/version
> Linux version 2.6.18-6-686 (Debian 2.6.18.dfsg.1-26etch1)
> (dannf@...) (gcc version 4.1.2 20061115 (prerelease) (Debian
> 4.1.1-21)) #1 SMP Thu Nov 5 16:28:13 UTC 2009
>
> # smbd --version
> Version 3.0.24

Any chance you try with a later version?

Volker

--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

signature.asc (204 bytes) Download Attachment

From forum: Samba - General

Re: [SCM] Samba Shared Repository - branch master updated

2009-11-30T23:48:44Z

On Mon, Nov 30, 2009 at 06:25:20PM -0600, Günther Deschner wrote:

> The branch, master has been updated
> via ea20678... s3-build: taise tdb version when building against system libtdb library.
> from 6dd6000... s3:add split_tokens, a cmdline tool to test next_token_talloc()
>
> http://gitweb.samba.org/?p=samba.git;a=shortlog;h=master
>
>
> - Log -----------------------------------------------------------------
> commit ea20678c55fee9f4586630cdb5fe7f35457d309a
> Author: Günther Deschner <gd@...>
> Date: Tue Dec 1 01:22:44 2009 +0100
>
> s3-build: taise tdb version when building against system libtdb library.
>
> Try to fix the build on "buildsamba02". At least fixes the build on fedora12
> with libtdb-devel-1.1.5-2.fc12.x86_64 installed.
>
> Volker, please check.

Did the patch I sent to you yesterday night not work for
you?

Volker

signature.asc (204 bytes) Download Attachment

From forum: Samba - samba-technical

Re: RFCs, Debian and Samba build dependencies

2009-11-30T23:36:24Z

Hi Christian,

On Tue, Dec 01, 2009 at 07:10:19AM +0100, Christian Perrier wrote:
> Please find below the text of the original bug report we got about
> this (we got a similar bug report for samba 3, as it carries some
> samba4 sources).

the RFCs are removed by the create-tarball script for s3. So this
shouldn't be a problem in s3 tarballs any longer.

Cheers,
Karolin

--
Samba http://www.samba.org
SerNet http://www.sernet.de
sambaXP http://www.sambaxp.org

attachment0 (205 bytes) Download Attachment

From forum: Samba - samba-technical

Re: Tridge's coffee contraption - photos

2009-11-30T23:33:20Z

Now that we are truly off topic I think I see Pauls point.
However... by calculating the inherent delay in the RC circuit formed
by the series resistor and the input capactance we can adjust the PID
output timer on the triac to account for this known error and it will
likely be small enough that it will not be a problem.

If I've made any dud assumptions then let me know.

David

On Tuesday, December 1, 2009, Alastair D'Silva
<alastair@...> wrote:

>> -----Original Message-----
>> From: linux-bounces@... [mailto:linux-
>> bounces@...] On Behalf Of Paul Mackerras
>> Sent: Tuesday, 1 December 2009 5:05 PM
>> To: Alastair D'Silva
>> Cc: 'Felix Karpfen'; linux@...; hugh@...
>> Subject: Re: [clug] More info, please - was Re: Tridge's coffee
>> contraption - photos
>>
>> Alastair D'Silva writes:
>>
>> > You can achieve the zero cross detection with an
>> > optocoupler and a resistor divider network.
>>
>> I would be interested to see a circuit that can reliably detect the
>> zero-crossings (to within a few microseconds), doesn't need any
>> high-power resistors, and only uses a few components.
>
> Theres a good example on AVR's site:
>
> http://www.atmel.com/dyn/resources/prod_documents/doc2508.pdf
>
> The example is for a mains coupled microcontroller (likely powered by a
> capacitive supply from the mains) - since we want isolation, I would add an
> optocoupler, and clamping diodes (the example uses the internal diodes of
> the microcontroller).
>
> At 1mOhm, the maximum current you would have through the resistor is 0.3mA,
> dissipating around 0.1W, so high power resistors are not needed. You do
> however need to ensure the resistors are suitably rated for that voltage
> (plus some breathing room) though, and the easiest way to do that is to
> uprate the power rating. Even so, the end result is cheaper, lighter and
> less bulky than using a transformer.
>
> While there is some lag to reach the trigger voltage of the micro's input,
> it will be similar to the lag that a detector connected to a transformer
> would show (probably less actually, since a transformer adds a phase shift
> dependant on the impedance of the load). The optocoupler will add a fixed
> amount of lag, which can be taken from the data sheet and accounted for in
> software.
>
> I'm not too sure where the microseconds figure is coming from, given that
> you are detecting a on a 50/60Hz signal. In order to have that resolution on
> your switching, you would need a PWM with at least 14 bits of resolution.
> The project is using an 8 bit PWM, which is an order of magnitude less than
> the resolution required for microseconds to be a problem.
>
> --
> Alastair D'Silva mob: 0423 762 819
> Networking Consultant fax: 0413 181 661
> New Millennium Networking web: http://www.newmillennium.net.au
> skype: alastair_dsilva msn: alastair@...
> blog: http://alastair.d-silva.org
>
>
> --
> linux mailing list
> linux@...
> https://lists.samba.org/mailman/listinfo/linux
>

--
linux mailing list
linux@...
https://lists.samba.org/mailman/listinfo/linux

From forum: Samba - linux

Netapi for testjoin

2009-11-30T23:28:14Z

Hello everyone,

I am trying to write a small utility that can join, unjoin and testjoin
to a DC.

For the join / unjoin I used the netapi NetJoinDomain / NetunjoinDomain
and it seems to work well.

The question is which API should I use in order to implement the
testjoin predicate.

The "testjoin " should return TRUE iff the host is already joined to the
DC. (same functionality as the "net testjoin").

Thanks in advance,

Yinon

From forum: Samba - samba-technical

Borken vuid_cache in connection_struct?

2009-11-30T22:57:16Z

Hi, *:
I think the vuid_cache is broken when dynamic share permission is
introduced. Please correct me if I am wrong. :-)
1). security = share.
user A on share A, user B on share B, on the the same tcp connect.
user A performs some user activity on share A(eg, open a file, write
to it and keep it open), then user B performs some user activity on
share B. Therefore, current user changed from user A to user B. Share
A's permission changes here to deny write access for user A. user A
tries to write to the opened file. have a look at what change_to_user()
does, current user is not user A and will not find vuid_cache
entry(because share = security, vuid = -1 is not even cached), perform
access check from start, deny user A from write access.(bad, the second
write is expected to succeed).
2). security != share.
user 1-33 performs user activity sequentialy on share A.
user 1 performs something like this(open a file, write to it and
keep it open), then user 2-33 performs some user activity. current user
changes from 1 to 33, and vuid_cache is full when user 32 performs user
activity. Then user 33 performs user activity, vuid_cache for user 1
will be replace with user 33. user 1 tries to write to the file again,
have a look at what change_to_user() does. current_user is not user 1,
look up in the vuid_cache failed, do a access check from start, deny
user A from write access. (Bad, the second write is expected to succeed.)

Recommendations:
We use two linked lists to watch on share's permission. the entry
looks like vuid_cache. One list is used to record information about
share(read_only, admin_users, server_info) when the first call to
change_to_user(), ie, when user performs first user acitivty, record
share status here. Another list is used to store most-updated share
info. When smbd receives MSG_SMB_REEVALUATE_SHARE, it modifies this list
to reflect changes.
When handling smb commands which must be sensitive to share
permission change(like open, unlink, etc), we update the
conn->{read_only, admin_user, server_info} from the second list. In
change_to_user(), we use the first list to update info in
connection_struct, if we cannot find in the cache, we know this is our
first user activity, do access check from start and update the two list.
Even vuid = -1 is cached here.
Am I right about this? comment please. :-)

--
Bo Yang, Software Engineer, Suse Labs
GPG-key-ID 538C4C1A
Samba Team boyang@... http://www.samba.org/
SUSE Linux boyang@... http://www.novell.com/

From forum: Samba - samba-technical

Re: More info, please - was Re: Tridge's coffee contraption - photos

2009-11-30T22:46:18Z

> -----Original Message-----
> From: linux-bounces@... [mailto:linux-
> bounces@...] On Behalf Of Paul Mackerras
> Sent: Tuesday, 1 December 2009 5:05 PM
> To: Alastair D'Silva
> Cc: 'Felix Karpfen'; linux@...; hugh@...
> Subject: Re: [clug] More info, please - was Re: Tridge's coffee
> contraption - photos
>
> Alastair D'Silva writes:
>
> > You can achieve the zero cross detection with an
> > optocoupler and a resistor divider network.
>
> I would be interested to see a circuit that can reliably detect the
> zero-crossings (to within a few microseconds), doesn't need any
> high-power resistors, and only uses a few components.

Theres a good example on AVR's site:

http://www.atmel.com/dyn/resources/prod_documents/doc2508.pdf

The example is for a mains coupled microcontroller (likely powered by a
capacitive supply from the mains) - since we want isolation, I would add an
optocoupler, and clamping diodes (the example uses the internal diodes of
the microcontroller).

At 1mOhm, the maximum current you would have through the resistor is 0.3mA,
dissipating around 0.1W, so high power resistors are not needed. You do
however need to ensure the resistors are suitably rated for that voltage
(plus some breathing room) though, and the easiest way to do that is to
uprate the power rating. Even so, the end result is cheaper, lighter and
less bulky than using a transformer.

While there is some lag to reach the trigger voltage of the micro's input,
it will be similar to the lag that a detector connected to a transformer
would show (probably less actually, since a transformer adds a phase shift
dependant on the impedance of the load). The optocoupler will add a fixed
amount of lag, which can be taken from the data sheet and accounted for in
software.

I'm not too sure where the microseconds figure is coming from, given that
you are detecting a on a 50/60Hz signal. In order to have that resolution on
your switching, you would need a PWM with at least 14 bits of resolution.
The project is using an 8 bit PWM, which is an order of magnitude less than
the resolution required for microseconds to be a problem.

--
Alastair D'Silva mob: 0423 762 819
Networking Consultant fax: 0413 181 661
New Millennium Networking web: http://www.newmillennium.net.au
skype: alastair_dsilva msn: alastair@...
blog: http://alastair.d-silva.org

--
linux mailing list
linux@...
https://lists.samba.org/mailman/listinfo/linux

From forum: Samba - linux

Re: RFCs, Debian and Samba build dependencies

2009-11-30T22:10:19Z

Quoting Andrew Bartlett (abartlet@...):
> Jelmer,
>
> I had to revert your commit to remove RFC files from Samba4 releases, as
> it broke the build of our release tarballs - Heimdal uses python to
> extract tables from the rfc files, and then uses them to build header
> files.
>
> Can we work to see if we can find a solution that is acceptable to
> Debian and does not break Samba to badly?

Please find below the text of the original bug report we got about
this (we got a similar bug report for samba 3, as it carries some
samba4 sources).

It proposes 3 solutions:
1) ask the author of the RFC to relicense it under a free license
2) repackage upstream sources without the offending documents
3) move the package to non free.

1) seems out of question as it would certainly require hairy
discussions with RFC authors while.....I'm not sure we (samba pkg
maintainers) are freeness-junkies enough to sustain it (IIRC I voted
against the resolutions that were attempting to make non modificable
documentation non free because I think this is more or less shooting
self in feet).

2) was possible but we preferred working directly with upstream (as
one of us is part of upstream) to remove the supposedly unmandatory
documents

3) would be interesting..:-)

This, of course, to give you the maybe needed background for all this...

Severity: serious
Package: samba
Version: 2:3.4.0-1
User: debian-release@...
Usertags: nonfree-doc rfc

Hi!

This source package contains the following files from the
IETF under non-free license terms:

+ samba-3.4.0/source4/ldap_server/devdocs/rfc4513.txt
+ samba-3.4.0/source4/ldap_server/devdocs/rfc4531.txt
+ samba-3.4.0/source4/ldap_server/devdocs/rfc4520.txt
+ samba-3.4.0/source4/ldap_server/devdocs/rfc4521.txt
+ samba-3.4.0/source4/ldap_server/devdocs/rfc4516.txt
+ samba-3.4.0/source4/ldap_server/devdocs/rfc4523.txt
+ samba-3.4.0/source4/ldap_server/devdocs/rfc2696.txt
+ samba-3.4.0/source4/ldap_server/devdocs/draft-armijo-ldap-syntax-00.txt
+ samba-3.4.0/source4/ldap_server/devdocs/rfc2849.txt
+ samba-3.4.0/source4/ldap_server/devdocs/rfc4512.txt
+ samba-3.4.0/source4/ldap_server/devdocs/rfc4532.txt
+ samba-3.4.0/source4/ldap_server/devdocs/rfc4515.txt
+ samba-3.4.0/source4/ldap_server/devdocs/rfc4529.txt
+ samba-3.4.0/source4/ldap_server/devdocs/rfc2891.txt
+ samba-3.4.0/source4/ldap_server/devdocs/rfc4517.txt
+ samba-3.4.0/source4/ldap_server/devdocs/rfc2307.txt
+ samba-3.4.0/source4/ldap_server/devdocs/rfc4527.txt
+ samba-3.4.0/source4/ldap_server/devdocs/rfc4510.txt
+ samba-3.4.0/source4/ldap_server/devdocs/rfc4518.txt
+ samba-3.4.0/source4/ldap_server/devdocs/rfc4524.txt
+ samba-3.4.0/source4/ldap_server/devdocs/rfc4533.txt
+ samba-3.4.0/source4/ldap_server/devdocs/rfc3296.txt
+ samba-3.4.0/source4/ldap_server/devdocs/rfc4511.txt
+ samba-3.4.0/source4/ldap_server/devdocs/rfc4514.txt
+ samba-3.4.0/source4/ldap_server/devdocs/rfc4522.txt
+ samba-3.4.0/source4/ldap_server/devdocs/rfc4519.txt
+ samba-3.4.0/source4/ldap_server/devdocs/rfc4526.txt
+ samba-3.4.0/source4/ldap_server/devdocs/rfc4525.txt
+ samba-3.4.0/source4/ldap_server/devdocs/rfc4528.txt
+ samba-3.4.0/source4/ldap_server/devdocs/rfc4530.txt
+ samba-3.4.0/source4/heimdal/lib/wind/rfc4013.txt
+ samba-3.4.0/source4/heimdal/lib/wind/rfc4518.txt
+ samba-3.4.0/source4/heimdal/lib/wind/rfc3492.txt
+ samba-3.4.0/source4/heimdal/lib/wind/rfc3490.txt
+ samba-3.4.0/source4/heimdal/lib/wind/rfc3454.txt
+ samba-3.4.0/source4/heimdal/lib/wind/rfc3491.txt

The license on RFC/I-Ds is not DFSG-free, see:
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=199810
* http://release.debian.org/removing-non-free-documentation
* http://wiki.debian.org/NonFreeIETFDocuments

The lenny/squeeze release policy says binary and source packages must each be free:
* http://release.debian.org/lenny/rc_policy.txt
* http://release.debian.org/squeeze/rc_policy.txt

The severity is serious, because this violates the Debian policy:
* http://www.debian.org/doc/debian-policy/ch-archive.html#s-dfsg

There are (at least) three ways to fix this problem. In order of
preference:

1. Ask the author of the RFC to re-license the RFC under a free
license. A template for this e-mail request can be found at
http://wiki.debian.org/NonFreeIETFDocuments

2. Remove the non-free material from the source, e.g., by re-packaging
the upstream archive and adding 'dfsg' to the Debian package
version name.

3. Move the package to non-free.

General discussions are kindly requested to take place on debian-legal
or debian-devel in the thread with Subject: "Non-free IETF RFC/I-Ds in
source packages".

Thanks,
Simon

_______________________________________________
Pkg-samba-maint mailing list
Pkg-samba-maint@...
http://lists.alioth.debian.org/mailman/listinfo/pkg-samba-maint

** CRM114 Whitelisted by: owner@... **

From forum: Samba - samba-technical

Re: More info, please - was Re: Tridge's coffee contraption - photos

2009-11-30T22:04:42Z

Alastair D'Silva writes:

> You can achieve the zero cross detection with an
> optocoupler and a resistor divider network.

I would be interested to see a circuit that can reliably detect the
zero-crossings (to within a few microseconds), doesn't need any
high-power resistors, and only uses a few components.

Paul.
--
linux mailing list
linux@...
https://lists.samba.org/mailman/listinfo/linux

From forum: Samba - linux

RFCs, Debian and Samba build dependencies

2009-11-30T21:18:21Z

Jelmer,

I had to revert your commit to remove RFC files from Samba4 releases, as
it broke the build of our release tarballs - Heimdal uses python to
extract tables from the rfc files, and then uses them to build header
files.

Can we work to see if we can find a solution that is acceptable to
Debian and does not break Samba to badly?

Thanks,

Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Cisco Inc.

signature.asc (196 bytes) Download Attachment

From forum: Samba - samba-technical

[ANNOUNCE] Samba 4.0.0alpha9

2009-11-30T21:05:49Z

We are proud to a announce another alpha release of Samba 4.

What's new in Samba 4 alpha9
============================

Samba 4 is the ambitious next version of the Samba suite that is being
developed in parallel to the stable 3.0 series. The main emphasis in
this branch is support for the Active Directory logon protocols used
by Windows 2000 and above.

Samba4 alpha9 follows on from the alpha release series we have been
publishing since September 2007

WARNINGS
========

Samba4 alpha9 is not a final Samba release. That is more a reference
to Samba4's lack of the features we expect you will need than a
statement of code quality, but clearly it hasn't seen a broad
deployment yet. If you were to upgrade Samba3 (or indeed Windows) to
Samba4, you would find many things work, but that other key features
you may have relied on simply are not there yet.

For example, while Samba 3.0 is an excellent member of a Active
Directory domain, Samba4 is happier as a domain controller, and it is
in this role where it has seen deployment into production.

Samba4 is subjected to an awesome battery of tests on an
automated basis, we have found Samba4 to be very stable in it's
behaviour. We have to recommend against upgrading production servers
from Samba 3 to Samba 4 at this stage, because there may be the features on
which you may rely that are not present, or the mapping of
your configuration and user database may not be complete.

If you are upgrading, or looking to develop, test or deploy Samba4, you should
backup all configuration and data.

NEW FEATURES
============

Samba4 supports the server-side of the Active Directory logon environment
used by Windows 2000 and later, so we can do full domain join
and domain logon operations with these clients.

Our Domain Controller (DC) implementation includes our own built-in
LDAP server and Kerberos Key Distribution Center (KDC) as well as the
Samba3-like logon services provided over CIFS. We correctly generate
the infamous Kerberos PAC, and include it with the Kerberos tickets we
issue.

The new VFS features in Samba 4 adapts the filesystem on the server to
match the Windows client semantics, allowing Samba 4 to better match
windows behaviour and application expectations. This includes file
annotation information (in streams) and NT ACLs in particular. The
VFS is backed with an extensive automated test suite.

A new scripting interface has been added to Samba 4, allowing
Python programs to interface to Samba's internals.

The Samba 4 architecture is based around an LDAP-like database that
can use a range of modular backends. One of the backends supports
standards compliant LDAP servers (including OpenLDAP), and we are
working on modules to map between AD-like behaviours and this backend.
We are aiming for Samba 4 to be powerful frontend to large
directories.

CHANGES SINCE alpha8
=====================

In the time since Samba4 alpha8 was released in June 2009, Samba has
continued to evolve, but you may particularly notice these areas
(in no particular order):

Samba4 now includes the full set of user interface strings (display Specifiers)
required to have the Microsoft Management Console operate

LDB (the core Samba4 database library) has again been reworked for
better performance

Replication between Samba4 and Active Directory domains using the
native replication protocol (DRS) has been demonstrated.

Access Control Lists (in nTSecurityDescriptor) are now set correctly
on objects in the directory, based on the same rules as Windows 2008.
(Searches and still use a simplistic administrator/not administrator
criteria)

These are just some of the user-visible highlights of the work done in
the past few months. More details of the work done 'under the hood'
can be found in our GIT history.

CHANGES
=======

Those familiar with Samba 3 can find a list of user-visible changes
since that release series in the NEWS file.

KNOWN ISSUES
============

- Domain member support is in it's infancy, and is not comparable to
the support found in Samba3.

- There is no printing support in the current release.

- There is no NetBIOS browsing support in the current release

- The Samba4 port of the CTDB clustering support is not yet complete

- Clock Synchronisation is critical. Many 'wrong password' errors are
actually due to Kerberos objecting to a clock skew between client
and server. (The NTP work in the previous alphas are partly to assist
with this problem).

- The DRS replication code often fails, and is very new

- Users upgrading existing databases to Samba4 should carefully
consult upgrading-samba4.txt. We have made a number of changes in
this release that should make it easier to upgrade in future.
Btw: there exists also a script under the "setup" directory of the
source distribution called "upgrade_from_s3" which should allow a step-up
from Samba3 to Samba4. It's not included yet in the binary distributions
since it's completely experimental!

- ACL are not set by default on shares created by the provision.
Work is underway on this subject and it should be fixed in Alpha10.

RUNNING Samba4
==============

A short guide to setting up Samba 4 can be found in the howto.txt file
in root of the tarball.

DEVELOPMENT and FEEDBACK
========================

Bugs can be filed at https://bugzilla.samba.org/ but please be aware
that many features are simply not expected to work at this stage.

The Samba Wiki at http://wiki.samba.org should detail some of these
development plans.

Development and general discussion about Samba 4 happens mainly on
the #samba-technical IRC channel (on irc.freenode.net) and
the samba-technical mailing list (see http://lists.samba.org/ for
details).

================
Download Details
================

The release tarball is available from the following location:
* http://download.samba.org/samba/ftp/samba4/samba-4.0.0alpha9.tar.gz

This release has been signed using GPG with Andrew's GPG key (28B436BB).

* http://download.samba.org/samba/ftp/samba4/samba-4.0.0alpha9.tar.asc

To verify that the signature is correct, make sure that the tarball has
been unzipped and run:

$ gpg --verify samba-4.0.0alpha9.tar.asc

Happy testing!

The Samba team

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.

signature.asc (196 bytes) Download Attachment

From forum: Samba - samba-announce

[ANNOUNCE] Samba 4.0.0alpha9

2009-11-30T21:05:49Z

signature.asc (196 bytes) Download Attachment

From forum: Samba - samba-technical

Re: surprise behavior #1: ENOENT for existing directories

2009-11-30T21:05:13Z

thank you guys very much for responding to my issues. i have now
remounted the share with noserverino. hopefully the problems will go
away and in a few days i can come back and tell you so.

cheers!
aaron.

-- aaron brick
-- aaron@...
-- http://www.lithic.org

2009/11/30 Jeff Layton <jlayton@...>:

> On Mon, 30 Nov 2009 22:14:22 +0530
> Suresh Jayaraman <sjayaraman@...> wrote:
>
>> On 11/30/2009 06:53 PM, Jeff Layton wrote:
>> > On Mon, 30 Nov 2009 16:45:59 +0530
>> > Suresh Jayaraman <sjayaraman@...> wrote:
>> >
>> >> On 11/30/2009 07:46 AM, aaron brick wrote:
>> >>> i am having two intermittent problems with CIFS and am sending
>> >>> separate emails to the list for each. this paragraph is identical. my
>> >>> desktop runs debian and kernel 2.6.32rc7; i am mounting a filesystem
>> >>> from my synology NAS, running DSM 2.2-0942 and using ext3 & RAID5
>> >>> internally. the link is gigabit through cat5e and a netgear switch.
>> >>> the only CIFS dmesg entry i see is a couple of: "CIFS VFS: server
>> >>> 10.1.1.2 of type Samba 3.2.8 returned unexpected error on SMB posix
>> >>> open, disabling posix open support. Check if server update available."
>> >>> (FWIW, synology hasn't released a firmware with a more recent samba.)
>> >>>
>> >>>
>> >>> here, creating files within a directory sometimes fails with ENOENT as
>> >>> if the parent did not exist. this generally prevents me from using the
>> >>> shared filesystem for compilation. an example follows:
>> >>>
>> >>>
>> >>> 11:08 / > mount | grep nas
>> >>> //nas/data on /data type cifs (rw,mand)
>> >>> 11:08 / > cd data
>> >>> 11:08 /data > mkdir a
>> >>> 11:08 /data > mkdir a/b
>> >>> mkdir: cannot create directory `a/b': No such file or directory
>> >>> 11:08 /data > strace mkdir a/b |& grep mkdir
>> >>> execve("/bin/mkdir", ["mkdir", "a/b"], [/* 22 vars */]) = 0
>> >>> mkdir("a/b", 0777) = -1 ENOENT (No such file or directory)
>> >>> write(2, "mkdir: ", 7mkdir: ) = 7
>> >>>
>> >>
>> >> I have not been able to reproduce this 2.6.31-rc1 against Samba 3.2.7. But a
>> >> quick look at the code suggests there could be a problem if we do this
>> >> sequence:
>> >>
>> >> POSIX open against Samba server < 3.3.1 (tcon->broken_posix_open will be set)
>> >> followed by a mkdir (will call CIFSPOSIXCreate). As we don't seem to check
>> >> whether the broken_posix_open is set, this might have led to this issue I think.
>> >>
>> >> Does the following patch (a quick, untested) fix the issue?
>> >>
>> >>
>> >>
>> >> fs/cifs/inode.c | 3 ++-
>> >> 1 files changed, 2 insertions(+), 1 deletions(-)
>> >>
>> >> diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
>> >> index cababd8..f1e9ab6 100644
>> >> --- a/fs/cifs/inode.c
>> >> +++ b/fs/cifs/inode.c
>> >> @@ -1038,7 +1038,8 @@ int cifs_mkdir(struct inode *inode, struct dentry *direntry, int mode)
>> >> return rc;
>> >> }
>> >>
>> >> - if ((pTcon->ses->capabilities & CAP_UNIX) &&
>> >> + if (!tcon->broken_posix_open && tcon->unix_ext &&
>> > ^^^^ should be "pTcon"
>> >
>>
>> Oops, sorry about the not even compile tested patch. Here is the
>> compile tested patch. Could you please test this one?
>>
>>
>> fs/cifs/inode.c | 3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
>> index cababd8..31be938 100644
>> --- a/fs/cifs/inode.c
>> +++ b/fs/cifs/inode.c
>> @@ -1038,7 +1038,8 @@ int cifs_mkdir(struct inode *inode, struct dentry *direntry, int mode)
>> return rc;
>> }
>>
>> - if ((pTcon->ses->capabilities & CAP_UNIX) &&
>> + if (!pTcon->broken_posix_open && pTcon->unix_ext &&
>> + (pTcon->ses->capabilities & CAP_UNIX) &&
>> (CIFS_UNIX_POSIX_PATH_OPS_CAP &
>> le64_to_cpu(pTcon->fsUnixInfo.Capability))) {
>> u32 oplock = 0;
>
> Now that I think about it though...
>
> The whole broken_posix_open thing was not a problem for actual creates,
> just when opening existing files. I'm pretty sure we still want to use
> posix creates for mkdir even if broken_posix_open is set.
>
> I'm more interested to know whether both of these problems go away if
> he mounts with "noserverino".
>
> --
> Jeff Layton <jlayton@...>
> _______________________________________________
> linux-cifs-client mailing list
> linux-cifs-client@...
> https://lists.samba.org/mailman/listinfo/linux-cifs-client
>

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

From forum: Samba - linux-cifs-client

Re: [IPA] Disabling Heimdal service

2009-11-30T20:52:45Z

Andrew,

You're right, I did a mistake during git reset. Attached should be
the correct one. Sorry about that. Thanks.

--
Endi S. Dewata

----- "Andrew Bartlett" <abartlet@...> wrote:

> On Mon, 2009-11-30 at 21:26 -0500, Endi Sukma Dewata wrote:
> > Hi Stefan,
> >
> > Attached are the patches that I've submitted recently. Please
> > use these files instead of the previous ones. I have modified
> > the last patch to use the static const kdc_tcp_stream_ops as
> > you suggested. I also do not include the patch #2 about copying
> > the examples into the installation directory for now.
>
> I think you sent the wrong patches - I can't see any evidence of that
> in
> the patches.
>
> Andrew Bartlett
>
> --
> Andrew Bartlett
> http://samba.org/~abartlet/
> Authentication Developer, Samba Team http://samba.org
> Samba Developer, Cisco Inc.

0005-s4-kdc-Merged-kdc_tcp_accept-and-kpasswdd_tcp_ac.patch (3K) Download Attachment

From forum: Samba - samba-technical

Re: SMB2 mixed lock & unlock requests in a single SMB_LOCK request

2009-11-30T20:28:16Z

Hi Steven,

Thank you for your email.

Someone from my team will be working with you and will be contacting you tomorrow.

Thanks and regards,

Sebastian Canevari
Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM
7100 N Hwy 161, Irving, TX - 75039

"Las Colinas - LC2"

Tel: +1 469 775 7849

sebastc@...

From: Steven Danneman [mailto:steven.danneman@...]
Sent: Monday, November 30, 2009 5:58 PM
To: Interoperability Documentation Help; cifs-protocol@...; pfif@...
Subject: SMB2 mixed lock & unlock requests in a single SMB_LOCK request

Hello,

I’ve come across another SMB2 locking issue that I can’t find explicit documentation for in MS-SMB2 (v18.0).

My first question, is whether a single SMB_LOCK request can contain both unlock and lock requests as the LockingAndX command type in SMBv1 could? The MS-SMB2 document hints that the answer to this question is “no” but it doesn’t seem to explicitly state it anywhere.

Section 2.2.26 states: “The SMB2 LOCK Request packet is sent by the client to either lock or unlock portions of a file.”

This statement is ambiguous as to whether the “or” is inclusive or exclusive.

In my testing, sending both lock and unlock requests in a single SMB2 locking request returns a STATUS_INVALID_PARAMETER. However, if the requests are ordered such that a unlock structure come first, the unlock request seems to succeed.

The attached pcap, against W2K8R2 shows:

1) Packet 27-28: A single lock request succeeding on range 0-10.

2) Packet 29-30: A lock request with unlock(0-10) and lock(10-10) failing with INVALID_PARAMETER.

3) Packet 31-32: A lock request with lock(0-10) and lock(10-10) succeeding, showing that the previous request, though it returned an error, succeeded in unlocking.

It seems to me the server behavior should be to return STATUS_INVALID_PARAMETER without completing any of the lock/unlock requests when they are mixed. Both the fact that this isn’t allowed, and the W2K8R2 behavior deviation should be documented.

Thanks,

Steven Danneman | Software Development Engineer
Isilon Systems P +1-206-315-7500 F +1-206-315-7501
www.isilon.com

How breakthroughs begin. ™

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

From forum: Samba - cifs-protocol

Re: [IPA] Disabling Heimdal service

2009-11-30T19:34:51Z

On Mon, 2009-11-30 at 21:26 -0500, Endi Sukma Dewata wrote:
> Hi Stefan,
>
> Attached are the patches that I've submitted recently. Please
> use these files instead of the previous ones. I have modified
> the last patch to use the static const kdc_tcp_stream_ops as
> you suggested. I also do not include the patch #2 about copying
> the examples into the installation directory for now.

I think you sent the wrong patches - I can't see any evidence of that in
the patches.

Andrew Bartlett

--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Cisco Inc.

signature.asc (196 bytes) Download Attachment

From forum: Samba - samba-technical

Re: [IPA] Disabling Heimdal service

2009-11-30T18:26:25Z

Hi Stefan,

Attached are the patches that I've submitted recently. Please
use these files instead of the previous ones. I have modified
the last patch to use the static const kdc_tcp_stream_ops as
you suggested. I also do not include the patch #2 about copying
the examples into the installation directory for now.

These patches are available in this git branch:
http://github.com/endisd/samba/commits/development/

Thanks!

--
Endi S. Dewata

----- "Stefan (metze) Metzmacher" <metze@...> wrote:

> You can just leave kdc_tcp_stream_ops as it is (static const)
> and use it for both, the name doesn't really matter.

[0003-s4-Create-default-modules-directory.patch]

From fa64d394fd438682c50c957f65596d72bb0d3759 Mon Sep 17 00:00:00 2001 From: Endi S. Dewata <edewata@...> Date: Fri, 20 Nov 2009 14:57:11 -0600 Subject: [PATCH] s4 - Create default modules directory. --- source4/Makefile | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/source4/Makefile b/source4/Makefile index 03b4e73..3aea791 100644 --- a/source4/Makefile +++ b/source4/Makefile @@ -221,6 +221,7 @@ installdirs:: $(DESTDIR)$(torturedir) \ $(DESTDIR)$(libdir) \ $(DESTDIR)$(modulesdir) \ + $(DESTDIR)$(modulesdir)/ldb \ $(DESTDIR)$(mandir) \ $(DESTDIR)$(localstatedir) \ $(DESTDIR)$(localstatedir)/lib \ -- 1.6.0.6

0001-s4-kdc-Disable-KDC-port-when-it-s-set-to-0.patch (5K) Download Attachment
0004-s4-kdc-Merged-kdc_add_kdc_socket-and-kdc_add_kpa.patch (5K) Download Attachment
0005-s4-kdc-Merged-kdc_tcp_accept-and-kpasswdd_tcp_ac.patch (4K) Download Attachment

From forum: Samba - samba-technical

Re: SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes

2009-11-30T18:06:19Z

Hi Bill,

I have done some more investigation on this issue, particularly around
doing a Trans2SetPathInfo() with the documented
FileEndOfFileInformation (0x104) level. It returns what I would
expect to be an acceptable error for an unknown info level. I have
attached a trace that shows this being done against a win7 server, but
I have a question about what the server is returning. The packets of
interest are 39/40:

1. Packet 40 appears to have the WordCount and ByteCount truncated,
making the packet smaller than normal minimum size of 35? Is this
intended behavior that other servers should implement?

Additionally a DOS Error is returned instead of a standard NT_STATUS
error. MS-CIFS does say that a DOS error or an NT_STATUS error may be
returned, but I don't see any indication in the documentation of when
a DOS error should be returned instead of an NT_STATUS error. Is it
possible to make this explicit in the docs or is this a case where
it's purposefully left ambiguous?

Thanks!

-Tim

On Nov 25, 2009, at 11:13 AM, Bill Wesse wrote:

>
> Question:
>
> Which existing handle would the pass-through be using? The handle
> opened in packet #28 is a separate tcp connection and a separte
> session from the Trans2SetPathInfo in packet #33. I'm not aware of
> any situation where the server is expected to share file handles
> across multiple sessions. Is this an exception?
>
> Response:
>
> I was paying more attention to the PID (0x26CD) - and didn't drill
> down closer to the sessions (both of which use the same security
> principal). Thanks for pointing that out; I will take it into
> account during my ongoing study (this implies a straight share mode
> bypass).
>
> Question:
>
> If a client can send a particular info level and windows implements
> it, then we have a compatibility problem if we choose not to support
> it. What I would really like to know is if other SMB implementations
> need to circumvent share-mode checks for this pass through level (and
> maybe others?).
>
> Response:
>
> That is certainly one of my goals - as I noted in my recent response
> to Jeremy, I intend to set up test code to exercise the information
> levels against the SMB calls.
>
> As I also mentioned, I will submit a TDI against this - before
> starting on any test code.
>
> Also, the best reference for the full roster of info levels is at:
>
> MSDN WDF_FILE_INFORMATION_CLASS
> http://msdn.microsoft.com/en-us/library/dd568296.aspx
>
> this being a subset:
> [MS-FSCC] 2.4 File Information Classes
> http://msdn.microsoft.com/en-us/library/cc232064.aspx
>
> Regards,
> Bill Wesse
> MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> 8055 Microsoft Way
> Charlotte, NC 28273
> TEL: +1(980) 776-8200
> CELL: +1(704) 661-5438
> FAX: +1(704) 665-9606
>
>
> -----Original Message-----
> From: Tim Prouty [mailto:tim.prouty@...]
> Sent: Wednesday, November 25, 2009 1:21 PM
> To: Bill Wesse
> Cc: cifs-protocol@...; pfif@...
> Subject: Re: SMB1 Trans2SetPathInfo() FileEndOfFileInformation is
> not enforcing share modes
>
> Hi Bill,
>
> Thank you for the quick answer! I have a few comments/questions
> below.
>
> On Nov 25, 2009, at 9:14 AM, Bill Wesse wrote:
>
>> Hello Tim. I think the difference in the response between the
>> standard versus pass-through level lies in how the file handle is
>> obtained during the call (given that TRANS2_SET_PATH_INFORMATION
>> passes the path, and not the handle). The logical conclusion from
>> the trace is that pass-through gets the existing handle, and the non
>> pass-through value simply fails, because a new handle cannot be
>> opened due to the lack of sharing.
>
>
> Which existing handle would the pass-through be using? The handle
> opened in packet #28 is a separate tcp connection and a separte
> session from the Trans2SetPathInfo in packet #33. I'm not aware of
> any situation where the server is expected to share file handles
> across multiple sessions. Is this an exception?
>
>
>> I will continue my investigation into the details on the differences
>> between the base & pass-through handling, with respect to the file
>> path / handle source. Pass-through is basically implementation
>> dependent, as noted in [MS-FSCC] (reference below), so there is a
>> possibility this may not be further elaborated on in the documents.
>
>
> If a client can send a particular info level and windows implements
> it, then we have a compatibility problem if we choose not to support
> it. What I would really like to know is if other SMB implementations
> need to circumvent share-mode checks for this pass through level (and
> maybe others?).
>
>
>> Of course, TRANS2_SET_FILE_INFORMATION should succeed (without a
>> pass-through value), since that requires the file handle (per [MS-
>> CIFS] 2.2.6.9 TRANS2_SET_FILE_INFORMATION (0x0008) at http://msdn.microsoft.com/en-us/library/ee442064.aspx)
>> .
>
>
> I agree. A Trans2SetFileInfo on the fid opened in packet #28 from the
> same session would have succeeded.
>
> -Tim

_______________________________________________
cifs-protocol mailing list
cifs-protocol@...
https://lists.samba.org/mailman/listinfo/cifs-protocol

From forum: Samba - cifs-protocol

Re: autogen.sh failing over samba share

2009-11-30T17:44:12Z

On Sun, Nov 29, 2009 at 11:45 AM, Volker Lendecke
<Volker.Lendecke@...> wrote:
> On Sun, Nov 29, 2009 at 03:22:26AM +0200, George Sapountzis wrote:
>> - configure is not created with +x permission
>
> Could that be the "create mask" setting?
>

Yes, using 0744 (default value) for "create mask" sets the x bit for
configure bit. However, it also sets the x bit for all(?) new/modified
files. This creates other problems. For example the source code is in
a mercurial repo, so whenever I do an update/checkout, files are
checked out with the x bit set and mercurial spuriously thinks that
the files are modified.

So, I guess the question is how do I configure samba so that
permission bits from the client are set the same as if the operation
was performed at the server ?

>> - configure creates tmp dirs with self-pointing links that cannot be
>> removed on the samba share:
>>
>> rm: cannot remove directory `conf5057.dir': Directory not empty
>
> Don't know about that one. I think we'd need logs from the
> delete attempt of the symlink.
>

I attach the log file from the samba server with log level set to 10
for the following operations:

$ \rm conf6345.dir/conf6345.file
rm: cannot remove `conf6345.dir/conf6345.file': Not a directory
$ \rm -rf conf6345.dir/
rm: cannot remove directory `conf6345.dir': Directory not empty

thanks,
George

--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

From forum: Samba - General

Re: More info, please - was Re: Tridge's coffee contraption - photos

2009-11-30T17:24:43Z

Hi Hugh,

Some suggestions to make the whole thing cheaper & better:

1. use a USB PIC, or software USB on an Atmel -
http://www.xs4all.nl/~dicks/avr/usbtiny/ . This replaces the MAX232 with a
couple of resistors. Since you now have a USB device, the transformer is not
needed for power. You can achieve the zero cross detection with an
optocoupler and a resistor divider network.

2. Add an analog input jack for the thermocouple, eliminating the multimeter
from the equation. Once could always add an LCD/LED display for temperature
readouts at a fraction of the cost of the multimeter.

3. Add another 240V output for direct control of the motor.

Some parts will be salvageable directly from the control of the breadmaker -
it likely already has a triac or relay for driving the motor, and possibly a
thermocouple as well. There may also be an LED display you can use for
temperature readouts.

--
Alastair D'Silva mob: 0423 762 819
Networking Consultant fax: 0413 181 661
New Millennium Networking web: http://www.newmillennium.net.au
skype: alastair_dsilva msn: alastair@...
blog: http://alastair.d-silva.org

> -----Original Message-----
> From: linux-bounces@... [mailto:linux-
> bounces@...] On Behalf Of Hugh Blemings
> Sent: Tuesday, 1 December 2009 11:54 AM
> To: tridge@...
> Cc: paulus@...; Felix Karpfen; linux@...
> Subject: Re: [clug] More info, please - was Re: Tridge's coffee
> contraption - photos
>
> Hiya,
>
> > For those who may be interested, I've done a bit of a write up on the
> > power controlled coffee roaster at coffeesnobs. See:
> >
> > http://coffeesnobs.com.au/YaBB.pl?num=1259627838
> >
> > It also includes a link to a much better circuit diagram than what I
> > showed at CLUG. Thanks to Hugh for the work on drawing up the
> circuit!
>
> Should add am going to take a crack at a PCB layout for the board in
> the next
> week or so and then we'll prolly organise to get a small run of boards
> done.
>
> Cheers,
> Hugh
> --
> linux mailing list
> linux@...
> https://lists.samba.org/mailman/listinfo/linux

--
linux mailing list
linux@...
https://lists.samba.org/mailman/listinfo/linux

From forum: Samba - linux

jcifs-krb5-1.3.12 released

2009-11-30T17:15:11Z

The JCIFS Kerberos port has been updated and is available for download
now from the JCIFS website.

Thanks to Mr. Shun for this contribution.

From forum: Samba - jcifs

Re: More info, please - was Re: Tridge's coffee contraption - photos

2009-11-30T16:54:27Z

Hiya,

> For those who may be interested, I've done a bit of a write up on the
> power controlled coffee roaster at coffeesnobs. See:
>
> http://coffeesnobs.com.au/YaBB.pl?num=1259627838
>
> It also includes a link to a much better circuit diagram than what I
> showed at CLUG. Thanks to Hugh for the work on drawing up the circuit!

Should add am going to take a crack at a PCB layout for the board in the next
week or so and then we'll prolly organise to get a small run of boards done.

Cheers,
Hugh
--
linux mailing list
linux@...
https://lists.samba.org/mailman/listinfo/linux

From forum: Samba - linux