** Low Priority ** Hi Volker, This is regarding your fix on recycled PIDs. I am an NCP developer from Novell and we use libsmbsharemodes library from Samba for Cross Protocols Locks between NCP, Samba and others. I have few queries regarding your fix. In your fix, you have added a new field called 'unique_id' in the server_id structure and we need to pass this in our call to samba share mode APIs e.g. create_share_mode_entry(). Also, you have introduced server registration/de-registration which is associated with 'unqiue_id'. If we use these new APIs then in which library from Samba do we need to link to? Or without calling serverid_register() can we directly pass any 'unique_id' while calling to create_share_mode_entry() and in that case whether this and other share mode APIs will work properly? Looking forward to your answer, Thanks, -Manoj
Hello! On Fri, Jan 20, 2012 at 04:38:21AM -0700, Manoj Dahal wrote:> > This is regarding your fix on recycled PIDs. I am an NCP > developer from Novell and we use libsmbsharemodes library > from Samba for Cross Protocols Locks between NCP, Samba > and others. I have few queries regarding your fix. > > In your fix, you have added a new field called 'unique_id' > in the server_id structure > and we need to pass this in our call to samba share mode > APIs e.g. create_share_mode_entry(). > > Also, you have introduced server > registration/de-registration which is associated with > 'unqiue_id'. If we use these new APIs > then in which library from Samba do we need to link to? > Or without calling serverid_register() can we directly > pass any 'unique_id' > while calling to create_share_mode_entry() and in that > case whether this and other share mode APIs will work > properly?If you pass a random unique_id, the share mode entry will be wiped once smbd reads it. You have to invent a unique_id, fill a struct server_id with it and call serverid_register() before using it. serverid_deregister() will remove that registration again. Unfortunately we don't provide an API to that functionality via libsmbsharemodes. It's not rocket science, and I would be happy to relicense my contribution to serverid.c under LGPL for inclusion into libsmbsharemodes. The problem there is that serverid.c is based on dbwrap for clustering, which libsmbsharemodes is not. So you will have to rewrite significant portions of serverid.c to directly open the tdb file. With best regards, Volker Lendecke -- SerNet GmbH, Bahnhofsallee 1b, 37081 G?ttingen phone: +49-551-370000-0, fax: +49-551-370000-9 AG G?ttingen, HRB 2816, GF: Dr. Johannes Loxen http://www.sernet.de, mailto:kontakt at sernet.de
** Low Priority ** Hi Volker, An alternate thought came into mind. Is it possible for you or someone from Samba to write a simpler serverid.c code without cluster support? Which can possibly be bundled in a new library or in libsmbsharemodes.so under LGPL. So that it will have lesser licensing issues. Thanks, -Manoj>>> Volker Lendecke <Volker.Lendecke at SerNet.DE> 1/24/2012 7:06 PM >>>On Tue, Jan 24, 2012 at 06:31:59AM -0700, Manoj Dahal wrote:> Thanks a lot again. Is it possible for you to let us know > the other authors/contributors > of serverid.c ? So that we can obtain their approval as well.You can find them with "git log serverid.c". With best regards, Volker Lendecke -- SerNet GmbH, Bahnhofsallee 1b, 37081 G?ttingen phone: +49-551-370000-0, fax: +49-551-370000-9 AG G?ttingen, HRB 2816, GF: Dr. Johannes Loxen http://www.sernet.de, mailto:kontakt at sernet.de .
Adding my thoughts to this. Basically the smbsharedmodes manner of working, as of now, will not work for any other service/protocol provider to have shared locking semantics with SAMBA (unless they are GPLv3 themselves). As without registering the unique ID, any other service that wants to register locks in the SAMBA database for cross protocol locking to function, will not be feasible. I would think the intention for having the shared locking database and the library (smbsharedmodes) would be to enable this functionality, across SAMBA and other file services that need file locking of this nature. Hence the ability to register the unique ID would also fall under this bucket of things to provide. With this in mind, would it be possibly to (re)consider how the unique ID registration can be modified, so that other services can leverage the inherent locking that smbsharedmodes is providing to play nice in a SAMBA + other protocol serving needs environment? Regards, Shyam>>> Manoj Dahal 1/25/2012 05:12 PM >>>Hi Volker, An alternate thought came into mind. Is it possible for you or someone from Samba to write a simpler serverid.c code without cluster support? Which can possibly be bundled in a new library or in libsmbsharemodes.so under LGPL. So that it will have lesser licensing issues. Thanks, -Manoj>>> Volker Lendecke <Volker.Lendecke at SerNet.DE> 1/24/2012 7:06 PM >>>On Tue, Jan 24, 2012 at 06:31:59AM -0700, Manoj Dahal wrote:> Thanks a lot again. Is it possible for you to let us know > the other authors/contributors > of serverid.c ? So that we can obtain their approval as well.You can find them with "git log serverid.c". With best regards, Volker Lendecke -- SerNet GmbH, Bahnhofsallee 1b, 37081 G?ttingen phone: +49-551-370000-0, fax: +49-551-370000-9 AG G?ttingen, HRB 2816, GF: Dr. Johannes Loxen http://www.sernet.de, mailto:kontakt at sernet.de .
Hi! Sure it can be modified to do that. What part of the last mail I sent needs clarification? The non-clustered version is relatively minor work, serverid.c is pretty trivial. Adding the clustered version is definitely more work. If you need any specific guidance to write a clean-room lgpl serverid.c, feel free to ask the questions here. I will be more than happy to review the patch once you have it. With best regards, Volker Lendecke On Wed, Jan 25, 2012 at 04:57:11AM -0700, Shyamsundar R wrote:> Adding my thoughts to this. > > Basically the smbsharedmodes manner of working, as of now, will not work for any other service/protocol provider to have shared locking semantics with SAMBA (unless they are GPLv3 themselves). As without registering the unique ID, any other service that wants to register locks in the SAMBA database for cross protocol locking to function, will not be feasible. > > I would think the intention for having the shared locking database and the library (smbsharedmodes) would be to enable this functionality, across SAMBA and other file services that need file locking of this nature. Hence the ability to register the unique ID would also fall under this bucket of things to provide. > > With this in mind, would it be possibly to (re)consider how the unique ID registration can be modified, so that other services can leverage the inherent locking that smbsharedmodes is providing to play nice in a SAMBA + other protocol serving needs environment? > > Regards, > Shyam > > >>> Manoj Dahal 1/25/2012 05:12 PM >>> > Hi Volker, > > An alternate thought came into mind. > Is it possible for you or someone from Samba to write a simpler serverid.c code without cluster support? > Which can possibly be bundled in a new library or in libsmbsharemodes.so under LGPL. > So that it will have lesser licensing issues. > > Thanks, > > -Manoj > > >>> Volker Lendecke <Volker.Lendecke at SerNet.DE> 1/24/2012 7:06 PM >>> > On Tue, Jan 24, 2012 at 06:31:59AM -0700, Manoj Dahal wrote: > > Thanks a lot again. Is it possible for you to let us know > > the other authors/contributors > > of serverid.c ? So that we can obtain their approval as well. > > You can find them with "git log serverid.c". > > With best regards, > > Volker Lendecke > > -- > SerNet GmbH, Bahnhofsallee 1b, 37081 G?ttingen > phone: +49-551-370000-0, fax: +49-551-370000-9 > AG G?ttingen, HRB 2816, GF: Dr. Johannes Loxen > http://www.sernet.de, mailto:kontakt at sernet.de > . >-- SerNet GmbH, Bahnhofsallee 1b, 37081 G?ttingen phone: +49-551-370000-0, fax: +49-551-370000-9 AG G?ttingen, HRB 2816, GF: Dr. Johannes Loxen http://www.sernet.de, mailto:kontakt at sernet.de
** Low Priority ** Hi Volker, For the time being trivial one will be good enough, provided the patch will be accepted in the upstream and it works well with existing code. Moving forward we can think of having cluster support as well. Appreciate your continuos support on the issue. Thanks, -Manoj>>> Volker Lendecke <Volker.Lendecke at SerNet.DE> 1/25/2012 7:08 PM >>>Hi! Sure it can be modified to do that. What part of the last mail I sent needs clarification? The non-clustered version is relatively minor work, serverid.c is pretty trivial. Adding the clustered version is definitely more work. If you need any specific guidance to write a clean-room lgpl serverid.c, feel free to ask the questions here. I will be more than happy to review the patch once you have it. With best regards, Volker Lendecke On Wed, Jan 25, 2012 at 04:57:11AM -0700, Shyamsundar R wrote:> Adding my thoughts to this. > > Basically the smbsharedmodes manner of working, as of now, will not work for any other service/protocol provider to have shared locking semantics with SAMBA (unless they are GPLv3 themselves). As without registering the unique ID, any other service that wants to register locks in the SAMBA database for cross protocol locking to function, will not be feasible. > > I would think the intention for having the shared locking database and the library (smbsharedmodes) would be to enable this functionality, across SAMBA and other file services that need file locking of this nature. Hence the ability to register the unique ID would also fall under this bucket of things to provide. > > With this in mind, would it be possibly to (re)consider how the unique ID registration can be modified, so that other services can leverage the inherent locking that smbsharedmodes is providing to play nice in a SAMBA + other protocol serving needs environment? > > Regards, > Shyam > > >>> Manoj Dahal 1/25/2012 05:12 PM >>> > Hi Volker, > > An alternate thought came into mind. > Is it possible for you or someone from Samba to write a simpler serverid.c code without cluster support? > Which can possibly be bundled in a new library or in libsmbsharemodes.so under LGPL. > So that it will have lesser licensing issues. > > Thanks, > > -Manoj > > >>> Volker Lendecke <Volker.Lendecke at SerNet.DE> 1/24/2012 7:06 PM >>> > On Tue, Jan 24, 2012 at 06:31:59AM -0700, Manoj Dahal wrote: > > Thanks a lot again. Is it possible for you to let us know > > the other authors/contributors > > of serverid.c ? So that we can obtain their approval as well. > > You can find them with "git log serverid.c". > > With best regards, > > Volker Lendecke > > -- > SerNet GmbH, Bahnhofsallee 1b, 37081 G?ttingen > phone: +49-551-370000-0, fax: +49-551-370000-9 > AG G?ttingen, HRB 2816, GF: Dr. Johannes Loxen > http://www.sernet.de, mailto:kontakt at sernet.de > . >-- SerNet GmbH, Bahnhofsallee 1b, 37081 G?ttingen phone: +49-551-370000-0, fax: +49-551-370000-9 AG G?ttingen, HRB 2816, GF: Dr. Johannes Loxen http://www.sernet.de, mailto:kontakt at sernet.de
Hi Manoj,> This is regarding your fix on recycled PIDs. I am an NCP developer from Novell and we use libsmbsharemodes library > from Samba for Cross Protocols Locks between NCP, Samba and others. I have few queries regarding your fix. > > In your fix, you have added a new field called 'unique_id' in the server_id structure > and we need to pass this in our call to samba share mode APIs e.g. create_share_mode_entry(). > > Also, you have introduced server registration/de-registration which is associated with 'unqiue_id'. If we use these new APIs > then in which library from Samba do we need to link to? Or without calling serverid_register() can we directly pass any 'unique_id' > while calling to create_share_mode_entry() and in that case whether this and other share mode APIs will work properly? > > > Looking forward to your answer,Maybe we could invent a special value e.g. UINT64_MAX as "don't verify this unique id". metze -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/samba/attachments/20120125/c116d58f/attachment.pgp>
** Low Priority ** Volker, In that case, which library/binary (and rpm) is responsible for wiping out the share mode entries if the PID is not registered in server.tdb? And in what scenario will this happen? I was trying to reproduce this with Samba running and I still see my share mode entries intake. Thanks, -Manoj>>> Volker Lendecke <Volker.Lendecke at SerNet.DE> 2/8/2012 2:38 PM >>>On Wed, Feb 08, 2012 at 01:28:33AM -0700, Manoj Dahal wrote:> In which samba library/binary file and rpm does the source > file source3/lib/serverid.c reflect to? > I was guessing it could be smbd and samba-3.6.1*.rpm.Sorry, I don't get your question. lib/serverid.c is linked into quite a few binaries as you can see from Makefile.in. It will certainly end up in the RPM files. Volker -- SerNet GmbH, Bahnhofsallee 1b, 37081 G?ttingen phone: +49-551-370000-0, fax: +49-551-370000-9 AG G?ttingen, HRB 2816, GF: Dr. Johannes Loxen http://www.sernet.de, mailto:kontakt at sernet.de
On Wed, Feb 08, 2012 at 02:17:33AM -0700, Manoj Dahal wrote:> In that case, which library/binary (and rpm) is responsible for wiping out the > share mode entries if the PID is not registered in server.tdb? And in what scenario > will this happen? I was trying to reproduce this with Samba running and I still see > my share mode entries intake.It should be smbd when someone tries to open the file for which a share mode entry exists without a corresponding serverid.tdb entry. Volker -- SerNet GmbH, Bahnhofsallee 1b, 37081 G?ttingen phone: +49-551-370000-0, fax: +49-551-370000-9 AG G?ttingen, HRB 2816, GF: Dr. Johannes Loxen http://www.sernet.de, mailto:kontakt at sernet.de