log.nmbd never rotates issue
shivappa sangapur
ssangapur3 at gmail.com
Fri Mar 21 01:30:10 MDT 2014
The nmbd log rotation issue solved on my fedora (samba4.1.4) only when we
don't provide log file name in smb.conf file with the provided patch.
Isn't it.?
If I provide any log file name. Then log.smbd and log.nmbd will not
rotate..
--
Shiv
On Mar 20, 2014 11:30 PM, <samba-technical-request at lists.samba.org> wrote:
> Send samba-technical mailing list submissions to
> samba-technical at lists.samba.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.samba.org/mailman/listinfo/samba-technical
> or, via email, send a message with subject or body 'help' to
> samba-technical-request at lists.samba.org
>
> You can reach the person managing the list at
> samba-technical-owner at lists.samba.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of samba-technical digest..."
>
> Today's Topics:
>
> 1. Re: Samba project aspirant for GSOC 2014 (Christopher R. Hertel)
> 2. Samba GSoC Proposal 2014 : Amit Kumar (AMiT)
> 3. Re: [PATCH] Bug 10239 - log.nmbd never rotates (Thomas Bork)
> 4. Re: [PATCH] Storing the ACL control flags with vfs gpfs.
> (Christof Schmitt)
> 5. Re: Samba GSoC Proposal 2014 : Amit Kumar (Andrew Bartlett)
> 6. Re: master4-dcerpc-ok (Andrew Bartlett)
> 7. Re: [PATCH] Make loadparm more common (Andrew Bartlett)
> 8. Re: [PATCH] Patch to implement AD password lockout in Samba's
> AD DC (Andrew Bartlett)
> 9. Re: master4-dcerpc-ok (Andrew Bartlett)
> 10. Re: ntdb for Samba 4.2? (Andrew Bartlett)
> 11. Re: [PATCH] Assert that the objectClass is always present
> (Andrew Bartlett)
> 12. Re: [PATCH] samba-tool dbcheck: handle name conflict objects
> (Andrew Bartlett)
> 13. Re: Samba GSoC Proposal 2014 : Amit Kumar (AMiT)
> 14. Re: [PATCH] Fix bug #9878 - force user does not work as
> expected. (Ricky Nance)
> 15. Re: [PATCH] Fix bug #9878 - force user does not work as
> expected. (Ricky Nance)
> 16. Re: ntdb for Samba 4.2? (Rusty Russell)
> 17. Re: ntdb for Samba 4.2? (Volker Lendecke)
> 18. Re: ntdb for Samba 4.2? (Michael Adam)
> 19. Windows 8 pro joining Samba domains, and which ones it just
> fails to join (those with dots in their names) (paolo turra)
> 20. Re: [PATCH] Bug 10239 - log.nmbd never rotates (Bjoern Baumbach)
> 21. Re: ntdb for Samba 4.2? (Volker Lendecke)
> 22. Unable to complete post-deployment configuration wizard of
> Windows Server Essentials role (Felix Botner)
> 23. Re: ntdb for Samba 4.2? (Michael Adam)
> 24. Re: ntdb for Samba 4.2? (Volker Lendecke)
> 25. [PATCH] ctdb/pmda: Fix metric identifiers (David Disseldorp)
> 26. Re: ntdb for Samba 4.2? (Jeremy Allison)
>
>
> ---------- Forwarded message ----------
> From: "Christopher R. Hertel" <crh at ubiqx.mn.org>
> To: samba-technical at lists.samba.org
> Cc:
> Date: Wed, 19 Mar 2014 13:38:29 -0500
> Subject: Re: Samba project aspirant for GSOC 2014
> I may be the one confused here, but just to be clear...
>
> When the Samba Team talk about the "Samba VFS" we mean the VFS layer within
> Samba itself. This is not the in-kernel VFS, but a mechanism by which
> Samba
> can be integrated more closely with an underlying file system.
>
> The CIFSFS is an in-kernel file system that uses the in-kernel VFS to
> integrate itself with Linux. The CIFSFS is maintained by members of the
> Samba Team, kernel developers, etc.
>
> If Al pulled the support for change notify from the CIFSFS kernel module
> five years ago, then I would suspect that such support has been rewritten
> by
> now. I don't know for sure. If not, then it would be a nice feature to
> have.
>
> Chris -)-----
>
> On 03/19/2014 12:22 PM, Saket Sinha wrote:
> > Hi Richard,
> >
> > Please find my response inline-
> >
> >>> 1. To modify the Samba VFS to support change notify if the underlying
> >>> file system supports it? In this case, it is my understanding that the
> >>> VFS already contains such support.
> >
> > The VFS supports this feature but according to the patchsets that I
> > went through in which Al-Viro ripped support for the same in CIFS,
> > there are changes needed in the VFS to bring it back to CIFS. This is
> > my understanding after going through Al-Viro's patch. Correct me, if I
> > am wrong.
> >
> > You can follow the discussion from the Samba mailing list at the below
> > link for the same-
> >
> https://lists.samba.org/archive/linux-cifs-client/2009-January/thread.html#3938
> > under the thread "[linux-cifs-client] [PATCH] cifs: remove dnotify
> > thread code "
> >
> >>> To modify the CIFSFS to pass through change-notify events to
> >>> inotify requests that applications might be using?
> >
> > If I can understand your question correctly, I can only answer that
> > inotify support has to provided in the lower filesystems too not just
> > the VFS(which it currently has) to enable this feature.
> >
> >
> > Regards,
> > Saket Sinha
> >
>
>
>
> ---------- Forwarded message ----------
> From: AMiT <dtu.amit at gmail.com>
> To: Andrew Bartlett <abartlet at samba.org>
> Cc: samba-technical at lists.samba.org
> Date: Thu, 20 Mar 2014 00:52:13 +0530
> Subject: Samba GSoC Proposal 2014 : Amit Kumar
> On Wed, Mar 19, 2014 at 12:32 AM, Andrew Bartlett <abartlet at samba.org
> >wrote:
>
> > On Mon, 2014-03-17 at 10:54 +0530, AMiT wrote:
> > > ---------- Forwarded message ----------
> > > From: AMiT <dtu.amit at gmail.com>
> > > Date: Sun, Mar 16, 2014 at 5:43 PM
> > > Subject: GSoC 2014 :Implement login / logout related counter update
> > > To: abartlet at samba.org
> > >
> > >
> > > Hello, Andrew
> > >
> > > I am a 2nd Year Mathematics & Computing Engineering Student from Delhi
> > > Technological University (Formerly Delhi College of Engineering),
> INDIA.
> > >
> > > *Proficiency in C: Intermediate*
> > >
> > > Python: I don't have the Knowledge of Python (I would study If
> Required).
> >
> > Python would be critical, see as an example how the password lockout
> > code is tested with python in the patch series I published recently:
> >
> >
> >
> https://git.samba.org/abartlet/samba.git/?p=abartlet/samba.git/.git;a=commitdiff;h=8f8c56338225984782288f8db3bfabdbcddcef4d
> >
> > This is the "This project of course includes the development of unit
> > tests." element of the task.
> >
> > > *Current Status: Researching on the Idea, Reading Documentation,
> > Exploring
> > > Samba & LDAP.*
> > >
> > > I am pretty much enthusiastic to work for this Samba Project as it
> seems
> > > Interesting to me.
> > > "Implement login / logout related counter update"
> > > *(Though I have not finished up with my Research)*
> > >
> > > The Moment I saw Programming Language Required is C, this doubled up my
> > > adrenaline rush, to be a part of Samba as a Open Source Developer.
> > > I have gone through the wiki page of Samba GSoC & I could make out
> that,
> > > the most preferred language of Samba is 'C'.
> > > So, that's enough for me (technically) to contribute.
> >
> > I look forward to seeing your application, but I would also suggest that
> > if you don't yet program in python, that you would need to particularly
> > clearly describe how you expect to handle the unit testing side of this,
> > and may wish to apply to another project that does not have this
> > requirement.
> >
> > Please also include examples of your work in C, a description of the
> > LDAP attributes that would be involved and links the the relevant
> > elements in the WSPP documentation.
> >
> > Thanks,
> >
> > Andrew Bartlett
> >
> > --
> > Andrew Bartlett http://samba.org/~abartlet/
> > Authentication Developer, Samba Team http://samba.org
> > Samba Developer, Catalyst IT
> > http://catalyst.net.nz/services/samba
> >
> >
> >
>
> Hello Andrew,
>
> I have Uploaded the Proposal for Samba SoC 2014:
>
>
> http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/aktechamit/5629499534213120
>
> Kindly, provide your feedback for further improvement of the proposal.
>
> How I will handle unit testing side:
>
> As far as Programming in Python is concerned for developing the unit tests,
> I am planning to do that in Perl. If, in case that is not feasible then I
> am Going to learn the required part for testing in Python (that's an easy
> task), well before the Project will start.
>
> I have been working for quite some time in C, basically on my College
> Server, which involves closed source projects, that is the reason I have
> not been able to include my previous works in C in my Proposal. I am in
> talks with one of my professors, for getting the permission for providing
> me with the source code of my past project.
>
> & I have been Examining the LDAP Attributes that would be involved for
> the Workgroup Server Protocol Program.
>
> Thanks,
>
> With Regards,
>
> --
>
>
>
> *Amit Kumar2nd Year, Mathematics & Computing EngineeringDelhi Technological
> University (Formerly DCE)Contact No. +91 9811522423*
>
>
>
> ---------- Forwarded message ----------
> From: Thomas Bork <tombork at web.de>
> To: Bjoern Baumbach <bb at sernet.de>, samba-technical <
> samba-technical at lists.samba.org>
> Cc:
> Date: Wed, 19 Mar 2014 22:35:43 +0100
> Subject: Re: [PATCH] Bug 10239 - log.nmbd never rotates
> Am 19.03.2014 16:32, schrieb Bjoern Baumbach:
>
> I've just figured out that we may need to the reset/reopen logs once
>> again, in the case that we specify a different config file in the
>> smb.conf via "config file" option.
>>
>> I've attached a new patch.
>> It applies on master, 4-0-test and 4-1-test.
>>
>
> Works fine. Thank you!
>
> --
> der tom
>
>
>
> ---------- Forwarded message ----------
> From: Christof Schmitt <cs at samba.org>
> To: Alexander Werth <werth at linux.vnet.ibm.com>
> Cc: samba-technical at lists.samba.org
> Date: Wed, 19 Mar 2014 15:10:34 -0700
> Subject: Re: [PATCH] Storing the ACL control flags with vfs gpfs.
> On Mon, Mar 17, 2014 at 03:02:10PM +0100, Alexander Werth wrote:
> > I forgot the signed-off-by and added some text to the commit message.
> >
> > Please comment/push.
>
> I think the overall approach is good, and avoiding the GPFS 3.5 defines
> does not make the code too ugly. Some comments:
>
> 0001-vfs-Support-NFS-control-flags-in-nfs4_acls.c.patch
>
> --- a/source3/modules/nfs4_acls.c
> +++ b/source3/modules/nfs4_acls.c
> @@ -49,6 +49,7 @@ typedef struct _SMB_ACE4_INT_T
> typedef struct _SMB_ACL4_INT_T
> {
> uint32 magic;
> + uint16 controlflags;
> uint32 naces;
> SMB_ACE4_INT_T *first;
> SMB_ACE4_INT_T *last;
>
> Should we use uint16_t throughout these patches to move the code towards
> the C99 types? It is different from the existing code in the file, but
> changing it has to start at some point.
>
> 0002-vfs-Store-ACL-control-flags-in-gpfs-vfs-module.patch
>
> --- a/source3/modules/vfs_gpfs.c
> +++ b/source3/modules/vfs_gpfs.c
> ...
> @@ -207,6 +225,34 @@ static int vfs_gpfs_get_real_filename(struct
> vfs_handle_struct *handle,
> return 0;
> }
>
> +static void sd2gpfs_control(uint16_t control, struct gpfs_acl *gacl)
> +{
> + unsigned int gpfs_aclflags = 0;
> + gpfs_aclflags = control << 8;
> + gpfs_aclflags &= 0x3c3c00; /* ACL4_FLAG_DACL_PROTECTED |
> + ACL4_FLAG_SACL_PROTECTED |
> + ACL4_FLAG_DACL_AUTO_INHERITED |
> + ACL4_FLAG_SACL_AUTO_INHERITED |
> + ACL4_FLAG_DACL_DEFAULTED |
> + ACL4_FLAG_SACL_DEFAULTED |
> + ACL4_FLAG_DACL_PRESENT |
> + ACL4_FLAG_SACL_PRESENT; */
> + if (!(control & 0x00000400)) /* SEC_DESC_DACL_PRESENT */
> + gpfs_aclflags |= 0x00800000; /* ACL4_FLAG_NULL_DACL; */
> + if (!(control & 0x00001000)) /* SEC_DESC_SACL_PRESENT */
> + gpfs_aclflags |= 0x01000000; /* ACL4_FLAG_NULL_SACL; */
>
> The if statements should use braces. Also the SEC_DESC_... defines are
> from Samba, not GPFS, so they can be used without problems.
>
> + gacl->acl_level = 1; /* GPFS_ACL_LEVEL_V4FLAGS*/
> + /* gacl->v4Level1.acl_flags requires gpfs 3.5 */
> + *(unsigned int *)&gacl->ace_v4 = gpfs_aclflags;
> +}
> +
> +static uint16_t gpfs2sd_control(unsigned int gpfs_aclflags)
> +{
> + uint16_t control = gpfs_aclflags >> 8;
> + control |= SEC_DESC_SELF_RELATIVE;
> + return control;
> +}
>
> It is probably unlikely that someone would be modifying the flags in the
> filesystem without going through Samba, but should gpfs2sd_control use
> the same mask as sd2gpfs_control for consistency? Maybe create a
> static uint16_t gpfs_aclflags_mask = 0x3c3c00; and use it in both
> functions?
>
> Also the ACL4_FLAG_NULL_DACL and ACL4_FLAG_NULL_SACL mappings are
> missing from gpfs2sd_control. Are they not needed here?
>
> Regards,
>
> Christof
>
>
>
> ---------- Forwarded message ----------
> From: Andrew Bartlett <abartlet at samba.org>
> To: AMiT <dtu.amit at gmail.com>
> Cc: samba-technical at lists.samba.org
> Date: Thu, 20 Mar 2014 11:30:39 +1300
> Subject: Re: Samba GSoC Proposal 2014 : Amit Kumar
> On Thu, 2014-03-20 at 00:52 +0530, AMiT wrote:
> >
> >
> >
> > On Wed, Mar 19, 2014 at 12:32 AM, Andrew Bartlett <abartlet at samba.org>
> > wrote:
> > On Mon, 2014-03-17 at 10:54 +0530, AMiT wrote:
> > > ---------- Forwarded message ----------
> > > From: AMiT <dtu.amit at gmail.com>
> > > Date: Sun, Mar 16, 2014 at 5:43 PM
> > > Subject: GSoC 2014 :Implement login / logout related counter
> > update
> > > To: abartlet at samba.org
> > >
> > >
> > > Hello, Andrew
> > >
> > > I am a 2nd Year Mathematics & Computing Engineering Student
> > from Delhi
> > > Technological University (Formerly Delhi College of
> > Engineering), INDIA.
> > >
> >
> > > *Proficiency in C: Intermediate*
> > >
> > > Python: I don't have the Knowledge of Python (I would study
> > If Required).
> >
> >
> > Python would be critical, see as an example how the password
> > lockout
> > code is tested with python in the patch series I published
> > recently:
> >
> >
> https://git.samba.org/abartlet/samba.git/?p=abartlet/samba.git/.git;a=commitdiff;h=8f8c56338225984782288f8db3bfabdbcddcef4d
> >
> > This is the "This project of course includes the development
> > of unit
> > tests." element of the task.
> >
> > > *Current Status: Researching on the Idea, Reading
> > Documentation, Exploring
> > > Samba & LDAP.*
> > >
> > > I am pretty much enthusiastic to work for this Samba Project
> > as it seems
> > > Interesting to me.
> > > "Implement login / logout related counter update"
> >
> > > *(Though I have not finished up with my Research)*
> > >
> > > The Moment I saw Programming Language Required is C, this
> > doubled up my
> > > adrenaline rush, to be a part of Samba as a Open Source
> > Developer.
> > > I have gone through the wiki page of Samba GSoC & I could
> > make out that,
> > > the most preferred language of Samba is 'C'.
> > > So, that's enough for me (technically) to contribute.
> >
> >
> > I look forward to seeing your application, but I would also
> > suggest that
> > if you don't yet program in python, that you would need to
> > particularly
> > clearly describe how you expect to handle the unit testing
> > side of this,
> > and may wish to apply to another project that does not have
> > this
> > requirement.
> >
> > Please also include examples of your work in C, a description
> > of the
> > LDAP attributes that would be involved and links the the
> > relevant
> > elements in the WSPP documentation.
> >
> > Thanks,
> >
> > Andrew Bartlett
> >
> > --
> > Andrew Bartlett
> > http://samba.org/~abartlet/
> > Authentication Developer, Samba Team http://samba.org
> > Samba Developer, Catalyst IT
> > http://catalyst.net.nz/services/samba
> >
> >
> >
> >
> >
> >
> > Hello Andrew,
> >
> > I have Uploaded the Proposal for Samba SoC 2014:
> >
> >
> http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/aktechamit/5629499534213120
> >
> > Kindly, provide your feedback for further improvement of the proposal.
> >
> > How I will handle unit testing side:
> >
> > As far as Programming in Python is concerned for developing the unit
> > tests, I am planning to do that in Perl. If, in case that is not
> > feasible then I am Going to learn the required part for testing in
> > Python (that's an easy task), well before the Project will start.
>
> We are not looking for new tests to be written to be written in Perl.
> Most of the similar tests for this area are in python, and I suggest
> that new tests should be in python as well.
>
> > I have been working for quite some time in C, basically on my College
> > Server, which involves closed source projects, that is the reason I
> > have not been able to include my previous works in C in my Proposal. I
> > am in talks with one of my professors, for getting the permission for
> > providing me with the source code of my past project.
> >
> > & I have been Examining the LDAP Attributes that would be involved for
> > the Workgroup Server Protocol Program.
>
> Good.
>
> Andrew Bartlett
>
> --
> Andrew Bartlett
> http://samba.org/~abartlet/
> Authentication Developer, Samba Team http://samba.org
> Samba Developer, Catalyst IT
> http://catalyst.net.nz/services/samba
>
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Andrew Bartlett <abartlet at samba.org>
> To: "Stefan (metze) Metzmacher" <metze at samba.org>
> Cc: Andreas Schneider <asn at samba.org>, Guenther Deschner <gd at samba.org>,
> Samba Technical <samba-technical at lists.samba.org>
> Date: Thu, 20 Mar 2014 12:34:03 +1300
> Subject: Re: master4-dcerpc-ok
> On Tue, 2014-03-18 at 16:38 +0100, Stefan (metze) Metzmacher wrote:
> > Am 12.03.2014 17:12, schrieb Stefan (metze) Metzmacher:
> > > Hi,
> > >
> > > here's new stuff in my
> > >
> https://git.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master4-dcerpc-ok
> > > branch.
> > >
> > > Please review and push:-)
> >
> > There're some updates in this branch, which also fix the regressions
> > Andrew found.
>
> I can confirm these regressions appear to be fixed. I've rebased my AD
> password lockout code on this and re-run my smbtorture test successfully
> against Windows 2008R2.
>
> Andrew Bartlett
>
> --
> Andrew Bartlett
> http://samba.org/~abartlet/
> Authentication Developer, Samba Team http://samba.org
> Samba Developer, Catalyst IT
> http://catalyst.net.nz/services/samba
>
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Andrew Bartlett <abartlet at samba.org>
> To: Nadezhda Ivanova <nivanova at samba.org>, Kamen Mazdrashki <
> kamenim at samba.org>
> Cc: asn at samba.org, samba-technical at lists.samba.org
> Date: Thu, 20 Mar 2014 13:12:44 +1300
> Subject: Re: [PATCH] Make loadparm more common
> On Thu, 2014-03-13 at 16:08 +1300, Andrew Bartlett wrote:
> > Garming,
> >
> > I'm really impressed by the patches you just showed me at
> >
> http://git.catalyst.net.nz/gitweb?p=samba.git;a=shortlog;h=refs/heads/loadparm-talloc-polish-second
>
> > Aside from these small comments, easily sorted out, can I get comments,
> > thoughts and perhaps a second team reviewer for this?
>
> These issues have been fixed up, and I've uploaded it to gerrit. The
> series starts at https://gerrit.samba.org/#/c/97/ and finishes at
> https://gerrit.samba.org/203
>
> Most of the earlier set of patches have been reviewed, but these still
> need a second reviewer:
> https://gerrit.samba.org/#/c/156/
> https://gerrit.samba.org/#/c/157/
> https://gerrit.samba.org/#/c/119/
> https://gerrit.samba.org/#/c/158/
> https://gerrit.samba.org/#/c/159/
> https://gerrit.samba.org/#/c/160/
>
> Also, the new changes start at https://gerrit.samba.org/166
>
> Can I get a second reviewer on this?
>
> Thanks,
>
> --
> Andrew Bartlett
> http://samba.org/~abartlet/
> Authentication Developer, Samba Team http://samba.org
> Samba Developer, Catalyst IT
> http://catalyst.net.nz/services/samba
>
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Andrew Bartlett <abartlet at samba.org>
> To: "Stefan (metze) Metzmacher" <metze at samba.org>
> Cc: asn at samba.org, samba-technical at samba.org, jra at samba.org, David
> Disseldorp <ddiss at suse.de>
> Date: Thu, 20 Mar 2014 13:35:41 +1300
> Subject: Re: [PATCH] Patch to implement AD password lockout in Samba's AD
> DC
> On Mon, 2014-03-17 at 17:19 +1300, Andrew Bartlett wrote:
>
> > I've now tested with Windows and Samba and have a patch series at:
> >
> >
> http://git.samba.org/?p=abartlet/samba.git/.git;a=shortlog;h=refs/heads/metze-master4-abartlet2
>
> Updated patches have been pushed!
>
> Hopefully we are getting closer.
>
> Andrew Bartlett
>
> --
> Andrew Bartlett
> http://samba.org/~abartlet/
> Authentication Developer, Samba Team http://samba.org
> Samba Developer, Catalyst IT
> http://catalyst.net.nz/services/samba
>
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Andrew Bartlett <abartlet at samba.org>
> To: "Stefan (metze) Metzmacher" <metze at samba.org>
> Cc: Andreas Schneider <asn at samba.org>, Guenther Deschner <gd at samba.org>,
> Samba Technical <samba-technical at lists.samba.org>
> Date: Thu, 20 Mar 2014 13:41:44 +1300
> Subject: Re: master4-dcerpc-ok
> On Wed, 2014-03-19 at 09:45 +0100, Stefan (metze) Metzmacher wrote:
>
> > What about having a #define DCERPC_BINDING_CONNECTION_PREFIX
> "connection".
> > The idea behind this prefix is that, I'd like to have some kind of
> > dcerpc_binding_reset(binding, flags) function, which would get a
> > flag to reset all connection related options, it would scan the option
> > list and remove all options starting with "connection:".
>
> This would be a start at least.
>
> > In addition I may add a function that replaces dcerpc_binding_dup(),
> > instead it would take arguments, which specific which options should
> > be copied. As I made dcerpc_pipe->binding const lately, I'd also make
> > this private
> > and hide dcerpc_pipe completely behind the dcerpc_binding_handle
> > abstraction.
> > and just have a function (maybe dcerpc_binding_handle_get_binding())
> > that also takes the flags arguement and just ask for a copy of the
> binding
> > including the specified options.
> >
> > What about having a wrapper function e.g.
> >
> > NTSTATUS dcerpc_binding_set_smbXcli_pointers(struct dcerpc_binding *b,
> > struct smbXcli_conn *conn,
> > struct smbXcli_session
> *session,
> > struct smbXcli_tcon *tcon);
>
> This would be a distinct improvement.
>
> > > The way I read the code, it keeps re-setting the same key-value pair,
> > > where "connection" is the key. I know you better than to assume that
> is
> > > true, but we need the code to be clearer than that.
> > >
> > > Beyond that, I'm not a big fan of these generic functions (and the ones
> > > already introduced) that change type-safe specific function pointers
> > > that the compiler will check for run-time string based lookups. I
> > > didn't object earlier, but I still don't like it. The things being
> > > passed around here are well known in advance, and having extra
> functions
> > > to set them (even if that means exposing specific types in the generic
> > > interface) is still better in my eyes than what we loose in type safety
> > > and compiler checking.
> >
> > We could also introduce wrapper functions like
> >
> > const char *dcerpc_binding_get_endpoint(const struct dcerpc_binding *b)
> > {
> > return dcerpc_binding_get_string_option(b, "endpoint");
> > }
>
> This would also be an improvement.
>
> > But the generic dcerpc_binding_[g|s]et_string_option() functions are
> needed
> > in order to make dcerpc_binding private.
>
> Why can't these helper functions access the private dcerpc_binding?
>
> Andrew Bartlett
>
> --
> Andrew Bartlett
> http://samba.org/~abartlet/
> Authentication Developer, Samba Team http://samba.org
> Samba Developer, Catalyst IT
> http://catalyst.net.nz/services/samba
>
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Andrew Bartlett <abartlet at samba.org>
> To: Rusty Russell <rusty at samba.org>
> Cc: samba-technical at samba.org
> Date: Thu, 20 Mar 2014 13:44:37 +1300
> Subject: Re: ntdb for Samba 4.2?
> On Wed, 2014-03-19 at 14:48 +1030, Rusty Russell wrote:
> > Andrew Bartlett <abartlet at samba.org> writes:
> > > Rusty (and the rest of the team),
> > >
> > > What do you consider the status of ntdb to be for the upcoming Samba
> 4.2
> > > and beyond?
> > >
> > > Is this an effort you are still working on, as I've not seen any
> > > activity from you in the past year other than adding the manpages.
> > >
> > > What are your plans here?
> > >
> > > Thanks,
> >
> > Well, originally I wrote a TDB replacement, with a compatibility ABI
> > which would allow a seamless transition.
> >
> > But then it was decided that we didn't want two TDB codebases, so I took
> > all that out and SAMBA would use its own, existing db_wrap API to do the
> > transition.
> >
> > Except the db_wrap API didn't cover many databases, didn't cover all
> > cases and had ctdb-specific parts to it. So now my task was to rewrite
> > SAMBA, including many old parts untouched for years, to make it use
> > db_wrap so it could later use ntdb. Some of that has been done, but
> > much remains.
> >
> > Meanwhile, there's no demand to drive it. TDB has problems, but scaling
> > over 3GB isn't the main one. The locking speed has been greatly
> > improved by the addition of inline mutexes; and so you won't notice
> > freelist contention as much. And using dbwrap means the new API doesn't
> > even make the code cleaner.
> >
> > ntdb may still have a useful role in green-fields projects which can
> > take advantage of the new API (eg. talloc-compatiblity). But it's
> > increasingly obvious that SAMBA doesn't need it today.
>
> Thanks for the update.
>
> My view is that it was unfortunate that the dbwrap path was taken,
> rather than transitioning to the tdb2 API on tdb, and then tdb2, but
> that boat has sailed. I agree that dbwrap has shown itself to be a dead
> end in terms of a practical way to transition the whole project between
> databases - it covers many, but far from all the databases.
>
> Andrew Bartlett
>
> --
> Andrew Bartlett
> http://samba.org/~abartlet/
> Authentication Developer, Samba Team http://samba.org
> Samba Developer, Catalyst IT
> http://catalyst.net.nz/services/samba
>
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Andrew Bartlett <abartlet at samba.org>
> To: Arvid Requate <requate at univention.de>
> Cc: metze at samba.org, samba-technical at samba.org
> Date: Thu, 20 Mar 2014 15:56:01 +1300
> Subject: Re: [PATCH] Assert that the objectClass is always present
> On Wed, 2014-03-12 at 12:52 +0100, Arvid Requate wrote:
> > On Wed, 2014-03-12 at 07:56:35 +1300 Andrew Bartlett wrote:
> > > On Tue, 2014-03-11 at 17:37 +0100, Arvid Requate wrote:
> > > [...]
> > > > Ok, how will drepl behave after the new assertion has been
> triggered? Will
> > > > this block replication full stop or will it cause the object to be
> > > > neglected or will it try tro re-replicate the object in the next
> > > > replication run?
> > > >
> > > > * If the patch brings replication to a grinding halt that would be a
> show
> > > > stopper.
> > >
> > > Yes, it would do exactly that. I agree it stops the show, and in the
> > > case of corruption, I think that is the only safe action.
> > >
> > > From here what I would suggest is a new forced replication, either
> > > overwriting local changes totally or applying the replication merge
> > > logic, but asking the remote server for all objects by suggesting our
> > > USN is actually 0.
> > >
> > > > [...]
> > >
> > > I would suggest that this, run manually by the administrator, is the
> > > only safe option. It wouldn't lead to an infinite cycle because it
> > > would need to be administrator-run.
> > >
> > > Naturally, this needs to be combined with actually finding and fixing
> > > whatever can cause this in the first place - it should not be a natural
> > > part of operating a Samba domain.
> >
> > Ok, I understand your points. Would it be possible to signal this
> situation in
> > some way, e.g. making "samba-tool drs showrepl" issue a specific
> warning/error
> > message?
> >
> > For us it would be important that we can automate the detection of this
> error
> > condition, maybe run some information gathering script and finally
> trigger the
> > re-replication. We might do this e.g. by some cron job or nagios check.
> This
> > is what we as distributors need to be able to.
> >
> > This might also speed up the gathering of evidence around this issue, if
> we
> > could extract relevant information on the spot, possibly even from other
> > replicating DCs, rather than manually digging through the logs and
> comparing
> > logs on two or more DCs.
>
> So, where I've got to is to make the DRS code give some pretty specific
> error messages, and to write things very clearly in the logs. This much
> is in master.
>
> We still need an example of this failing that we can poke and probe, so
> I hope you can continue to try and reproduce on some servers we can
> later grab the databases from.
>
> I'm not confident that error message won't currently make it to
> showrepl, but I can look into that further if you like. Currently know
> that the error will be lost at:
>
> replicated_objects.c:
> ret = ldb_extended(ldb, DSDB_EXTENDED_REPLICATED_OBJECTS_OID,
> objects,
> &ext_res);
> if (ret != LDB_SUCCESS) {
> /* restore previous schema */
> if (used_global_schema) {
> dsdb_set_global_schema(ldb);
> } else if (cur_schema) {
> dsdb_reference_schema(ldb, cur_schema, false);
> }
>
> DEBUG(0,("Failed to apply records: %s: %s\n",
> ldb_errstring(ldb), ldb_strerror(ret)));
> ldb_transaction_cancel(ldb);
> TALLOC_FREE(tmp_ctx);
> return WERR_FOOBAR;
> }
> talloc_free(ext_res);
>
> We could map the LDB errors onto WERR_DS_, we don't currently have a
> mapping table for that, but it looks like all LDB errors have a matching
> WERR_DS error.
>
> I do look forward to any more clues that would help us close this down
> forever, rather than just lock up a replication partner.
>
> Thanks,
>
> Andrew Bartlett
>
> --
> Andrew Bartlett
> http://samba.org/~abartlet/
> Authentication Developer, Samba Team http://samba.org
> Samba Developer, Catalyst IT
> http://catalyst.net.nz/services/samba
>
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Andrew Bartlett <abartlet at samba.org>
> To: Felix Botner <botner at univention.de>
> Cc: samba-technical at samba.org
> Date: Thu, 20 Mar 2014 16:01:24 +1300
> Subject: Re: [PATCH] samba-tool dbcheck: handle name conflict objects
> On Wed, 2014-03-19 at 18:01 +0100, Felix Botner wrote:
> > Am Mittwoch, 5. März 2014, 10:16:37 schrieb Andrew Bartlett:
> > > What we need now is to improve the tool, because conflict resolution is
> > > a manual process, not one that we can do anything more than guide.
> > >
> > > The tool should present both objects to the user, and ask them which
> one
> > > should survive. You will have to find the other record by figuring out
> > > what the name would have been. We can have --yes simply prune the
> > > conflict record (which will be the newer record), but the admin should
> > > be presented with the choice, and be able to keep the conflict record
> > > instead.
> >
> > Yes, i see that, how should i ask the user
> >
> > (a)
> >
> > Found conflict object and corresponding non-conflict object!
> > Delete conflict object "conflict dn"? [Y,n] -> n
> > Delete the non-conflict object "non-conflict dn"? [Y,n] -> y
> > Rename the conflict object to "non-conflict dn"? [Y,n] -> y
> >
> > if --fix is set, the default would be to delete all conflict objects
> >
> > (b)
> >
> > Found conflict object and corresponding non-conflict object!
> > Which object should be deleted?
> > [1] the conflict object (dn)
> > [2] the non-conflict object (dn)
> > [3] none
> > [1, 2, 3] -> 2
> > Should the conflict object be renamed to 'non-conflict dn'? [Y,n] -> y
> >
> > (b) is maybe a bit more user friendly, because we present them all the
> options
> > (delete conflict or delete non-conflict) in one step not just "delete
> > conflict" as in (a)
>
> I think b) is much better. I think the second step should be combined
> with the choice - leaving the conflict object but removing the original
> DN makes little sense to me.
>
> I'm happy for --fix --yes to delete the conflict DN in the
> --check-for-conflicts mode.
>
> > >
> > > It also shouldn't be presented as an ERROR - it isn't an error, but can
> > > be cleaned up. Perhaps call it 'WARNING:' instead?
> >
> > OK
> >
> > >
> > > Also, we shouldn't specify the DBCHECK control - the deletion needs to
> > > be a normal delete, and go though the normal processes.
> > >
> >
> > Yes
> >
> > > Finally, as I mentioned before we also should have a test for this,
> > > running on and fixing real conflicts generated by
> > > source4/torture/drs/python/replica_sync.py, and on a test database
> > > (perhaps the same one you plan to submit for the missing objectclass).
>
> This is the critical part - this will only happen rarely I hope, and we
> need tests to ensure it all works.
>
> Andrew Bartlett
>
> --
> Andrew Bartlett
> http://samba.org/~abartlet/
> Authentication Developer, Samba Team http://samba.org
> Samba Developer, Catalyst IT
> http://catalyst.net.nz/services/samba
>
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: AMiT <dtu.amit at gmail.com>
> To: Andrew Bartlett <abartlet at samba.org>, samba-technical at lists.samba.org
> Cc:
> Date: Thu, 20 Mar 2014 09:02:08 +0530
> Subject: Re: Samba GSoC Proposal 2014 : Amit Kumar
> On Thu, Mar 20, 2014 at 4:00 AM, Andrew Bartlett <abartlet at samba.org>
> wrote:
>
> > On Thu, 2014-03-20 at 00:52 +0530, AMiT wrote:
> > >
> > >
> > >
> > > On Wed, Mar 19, 2014 at 12:32 AM, Andrew Bartlett <abartlet at samba.org>
> > > wrote:
> > > On Mon, 2014-03-17 at 10:54 +0530, AMiT wrote:
> > > > ---------- Forwarded message ----------
> > > > From: AMiT <dtu.amit at gmail.com>
> > > > Date: Sun, Mar 16, 2014 at 5:43 PM
> > > > Subject: GSoC 2014 :Implement login / logout related counter
> > > update
> > > > To: abartlet at samba.org
> > > >
> > > >
> > > > Hello, Andrew
> > > >
> > > > I am a 2nd Year Mathematics & Computing Engineering Student
> > > from Delhi
> > > > Technological University (Formerly Delhi College of
> > > Engineering), INDIA.
> > > >
> > >
> > > > *Proficiency in C: Intermediate*
> > > >
> > > > Python: I don't have the Knowledge of Python (I would study
> > > If Required).
> > >
> > >
> > > Python would be critical, see as an example how the password
> > > lockout
> > > code is tested with python in the patch series I published
> > > recently:
> > >
> > >
> >
> https://git.samba.org/abartlet/samba.git/?p=abartlet/samba.git/.git;a=commitdiff;h=8f8c56338225984782288f8db3bfabdbcddcef4d
> > >
> > > This is the "This project of course includes the development
> > > of unit
> > > tests." element of the task.
> > >
> > > > *Current Status: Researching on the Idea, Reading
> > > Documentation, Exploring
> > > > Samba & LDAP.*
> > > >
> > > > I am pretty much enthusiastic to work for this Samba Project
> > > as it seems
> > > > Interesting to me.
> > > > "Implement login / logout related counter update"
> > >
> > > > *(Though I have not finished up with my Research)*
> > > >
> > > > The Moment I saw Programming Language Required is C, this
> > > doubled up my
> > > > adrenaline rush, to be a part of Samba as a Open Source
> > > Developer.
> > > > I have gone through the wiki page of Samba GSoC & I could
> > > make out that,
> > > > the most preferred language of Samba is 'C'.
> > > > So, that's enough for me (technically) to contribute.
> > >
> > >
> > > I look forward to seeing your application, but I would also
> > > suggest that
> > > if you don't yet program in python, that you would need to
> > > particularly
> > > clearly describe how you expect to handle the unit testing
> > > side of this,
> > > and may wish to apply to another project that does not have
> > > this
> > > requirement.
> > >
> > > Please also include examples of your work in C, a description
> > > of the
> > > LDAP attributes that would be involved and links the the
> > > relevant
> > > elements in the WSPP documentation.
> > >
> > > Thanks,
> > >
> > > Andrew Bartlett
> > >
> > > --
> > > Andrew Bartlett
> > > http://samba.org/~abartlet/
> > > Authentication Developer, Samba Team http://samba.org
> > > Samba Developer, Catalyst IT
> > > http://catalyst.net.nz/services/samba
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hello Andrew,
> > >
> > > I have Uploaded the Proposal for Samba SoC 2014:
> > >
> > >
> >
> http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/aktechamit/5629499534213120
> > >
> > > Kindly, provide your feedback for further improvement of the proposal.
> > >
> > > How I will handle unit testing side:
> > >
> > > As far as Programming in Python is concerned for developing the unit
> > > tests, I am planning to do that in Perl. If, in case that is not
> > > feasible then I am Going to learn the required part for testing in
> > > Python (that's an easy task), well before the Project will start.
> >
> > We are not looking for new tests to be written to be written in Perl.
> > Most of the similar tests for this area are in python, and I suggest
> > that new tests should be in python as well.
> >
> > > I have been working for quite some time in C, basically on my College
> > > Server, which involves closed source projects, that is the reason I
> > > have not been able to include my previous works in C in my Proposal. I
> > > am in talks with one of my professors, for getting the permission for
> > > providing me with the source code of my past project.
> > >
> > > & I have been Examining the LDAP Attributes that would be involved for
> > > the Workgroup Server Protocol Program.
> >
> > Good.
> >
> > Andrew Bartlett
> >
> > --
> > Andrew Bartlett
> > http://samba.org/~abartlet/
> > Authentication Developer, Samba Team http://samba.org
> > Samba Developer, Catalyst IT
> > http://catalyst.net.nz/services/samba
> >
> >
> >
> >
> >
> If the tests should be in Python, then I am looking forward to learn
> Python.
> I would be ready with it, well before the Project starts.
>
> Kindly Inform me, if there is anything wrong with the proposal.
>
> Thanks
> with Regards,
>
> --
>
>
>
> *Amit Kumar2nd Year, Mathematics & Computing EngineeringDelhi Technological
> University (Formerly DCE)Contact No. +91 9811522423*
>
>
>
> ---------- Forwarded message ----------
> From: Ricky Nance <ricky.nance at gmail.com>
> To: Andreas Schneider <asn at samba.org>
> Cc: Samba Technical <samba-technical at lists.samba.org>, Jeremy Allison <
> jra at samba.org>, "samba-technical at samba.org" <samba-technical at samba.org>
> Date: Wed, 19 Mar 2014 22:48:33 -0500
> Subject: Re: [PATCH] Fix bug #9878 - force user does not work as expected.
> Andreas, I am betting you have already found this, but I think I have seen
> similar issues when nsswitch isn't working as expected. I typically miss
> nsswitch setup when I spin up a new machine, and find various gremlins when
> its not setup :).
>
> Good luck,
> Ricky
>
>
> On Wed, Mar 19, 2014 at 12:25 PM, Jeremy Allison <jra at samba.org> wrote:
>
> > On Wed, Mar 19, 2014 at 09:39:51AM -0700, Jeremy Allison wrote:
> > >
> > > OK - here is an attached patch that will dump out what
> > > is going wrong. Can you resend me the log with this
> > > in place please ?
> > >
> > > The "force user" patch is good. The issue is that
> > > the group resolution for @ntadmin -> &+ntadmin -> Check netgroup
> > "ntadmin" followed by UNIX group ntadmin
> > > (lookup_name: Unix Group\ntadmin => domain=[Unix Group],
> name=[ntadmin])
> > > isn't matching the token generated for the LEVEL1+Administrator.
> > >
> > > My guess is mapping 'ntadmin' inside token_contains_name()
> > > is mapping to the UNIX S-1-22 group, whereas that for
> > > some reason isn't present in the token attached to
> > > LEVEL1+Administrator.
> > >
> > > The reason it works without the "force user" patch
> > > is that the token that's being checked inside
> > > token_contains_name() will be identical for the
> > > forced group lookup of "ntadmin" -> UNIX S-1-22 group
> > > (lookup_name: Unix Group\ntadmin => domain=[Unix Group],
> name=[ntadmin])
> > > as that same lookup is being done to create the
> > > 'force group token'. I think it's still wrong,
> > > but it's checking the same thing.
> > >
> > > But the extra debugs will tell us more.
> >
> > Just to follow up (in case anyone cares :-).
> >
> > Andreas's issue is a problem with his system
> > not correctly getting all the correct groups
> > attached to his token when the LEVEL1+Administrator
> > log in, not a problem with the force user
> > fix.
> >
> > So the patch is good as it stands.
> >
> > We'll follow up on his issue separately.
> >
> > Jeremy.
> >
>
>
>
> ---------- Forwarded message ----------
> From: Ricky Nance <ricky.nance at gmail.com>
> To: Andreas Schneider <asn at samba.org>
> Cc: Samba Technical <samba-technical at lists.samba.org>, Jeremy Allison <
> jra at samba.org>, "samba-technical at samba.org" <samba-technical at samba.org>
> Date: Wed, 19 Mar 2014 22:48:33 -0500
> Subject: Re: [PATCH] Fix bug #9878 - force user does not work as expected.
> Andreas, I am betting you have already found this, but I think I have seen
> similar issues when nsswitch isn't working as expected. I typically miss
> nsswitch setup when I spin up a new machine, and find various gremlins when
> its not setup :).
>
> Good luck,
> Ricky
>
>
> On Wed, Mar 19, 2014 at 12:25 PM, Jeremy Allison <jra at samba.org> wrote:
>
> > On Wed, Mar 19, 2014 at 09:39:51AM -0700, Jeremy Allison wrote:
> > >
> > > OK - here is an attached patch that will dump out what
> > > is going wrong. Can you resend me the log with this
> > > in place please ?
> > >
> > > The "force user" patch is good. The issue is that
> > > the group resolution for @ntadmin -> &+ntadmin -> Check netgroup
> > "ntadmin" followed by UNIX group ntadmin
> > > (lookup_name: Unix Group\ntadmin => domain=[Unix Group],
> name=[ntadmin])
> > > isn't matching the token generated for the LEVEL1+Administrator.
> > >
> > > My guess is mapping 'ntadmin' inside token_contains_name()
> > > is mapping to the UNIX S-1-22 group, whereas that for
> > > some reason isn't present in the token attached to
> > > LEVEL1+Administrator.
> > >
> > > The reason it works without the "force user" patch
> > > is that the token that's being checked inside
> > > token_contains_name() will be identical for the
> > > forced group lookup of "ntadmin" -> UNIX S-1-22 group
> > > (lookup_name: Unix Group\ntadmin => domain=[Unix Group],
> name=[ntadmin])
> > > as that same lookup is being done to create the
> > > 'force group token'. I think it's still wrong,
> > > but it's checking the same thing.
> > >
> > > But the extra debugs will tell us more.
> >
> > Just to follow up (in case anyone cares :-).
> >
> > Andreas's issue is a problem with his system
> > not correctly getting all the correct groups
> > attached to his token when the LEVEL1+Administrator
> > log in, not a problem with the force user
> > fix.
> >
> > So the patch is good as it stands.
> >
> > We'll follow up on his issue separately.
> >
> > Jeremy.
> >
>
>
>
> ---------- Forwarded message ----------
> From: Rusty Russell <rusty at samba.org>
> To: Volker.Lendecke at SerNet.DE
> Cc: samba-technical at samba.org, Andrew Bartlett <abartlet at samba.org>
> Date: Thu, 20 Mar 2014 15:33:01 +1030
> Subject: Re: ntdb for Samba 4.2?
> Volker Lendecke <Volker.Lendecke at SerNet.DE> writes:
> > On Wed, Mar 19, 2014 at 02:48:33PM +1030, Rusty Russell wrote:
> >> Meanwhile, there's no demand to drive it. TDB has problems, but scaling
> >> over 3GB isn't the main one. The locking speed has been greatly
> >> improved by the addition of inline mutexes; and so you won't notice
> >> freelist contention as much. And using dbwrap means the new API doesn't
> >> even make the code cleaner.
> >
> > Even with mutexes you do notice freelist contention. The
> > real kick for this in our tests is the patch from
> > yesterday: With TDB_VOLATILE we keep some dead records per
> > chain, and while the freelist is blocked we go fishing for
> > dead records in other chains. Essentially, this turns each
> > chain into a small freelist. This together with mutexes
> > really, really rocks. No futex syscalls around anymore even
> > for heavily loaded servers. :-)
>
> Yes, this is a really good idea. I'd love to see a benchmark
> included in tdb which demonstrated the improvement, too. I'm
> not sure tdbtorture will do it.
>
> But:
> 5f7b481349796cc0e90563ed01353809b403e429 tdb: Fix a tdb corruption
>
> I don't understand how this can corrupt? A test case should be fairly
> simple, but I think this change is unnecessary.
>
> The rest of the patches look really nice. By changing to first fit you
> may increase fragmentation, but since TDBs are already so fragmented I
> don't think it'll be measurable.
>
> Thanks!
> Rusty.
>
>
>
>
> ---------- Forwarded message ----------
> From: Volker Lendecke <Volker.Lendecke at SerNet.DE>
> To: Andrew Bartlett <abartlet at samba.org>
> Cc: samba-technical at samba.org
> Date: Thu, 20 Mar 2014 06:31:30 +0100
> Subject: Re: ntdb for Samba 4.2?
> On Thu, Mar 20, 2014 at 01:44:37PM +1300, Andrew Bartlett wrote:
> > Thanks for the update.
> >
> > My view is that it was unfortunate that the dbwrap path was taken,
> > rather than transitioning to the tdb2 API on tdb, and then tdb2, but
> > that boat has sailed. I agree that dbwrap has shown itself to be a dead
> > end in terms of a practical way to transition the whole project between
> > databases - it covers many, but far from all the databases.
>
> Why do you think this is a dead end?
>
> With best regards,
>
> 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
>
>
>
> ---------- Forwarded message ----------
> From: Michael Adam <obnox at samba.org>
> To: Andrew Bartlett <abartlet at samba.org>
> Cc: Rusty Russell <rusty at samba.org>, samba-technical at samba.org
> Date: Thu, 20 Mar 2014 07:48:21 +0100
> Subject: Re: ntdb for Samba 4.2?
> On 2014-03-20 at 13:44 +1300, Andrew Bartlett wrote:
> >
> > Thanks for the update.
> >
> > My view is that it was unfortunate that the dbwrap path was taken,
> > rather than transitioning to the tdb2 API on tdb, and then tdb2, but
> > that boat has sailed. I agree that dbwrap has shown itself to be a dead
> > end in terms of a practical way to transition the whole project between
> > databases - it covers many, but far from all the databases.
>
> Well, I don't quite get your point here:
>
> Firstly, dbwrap is the perfect vehicle we have to switch
> between database backends that vaguely resemble the tdb API.
>
> Of course this requires our code to be converted to dbwrap,
> but that project stalled once we decided not to take ntdb
> for 4.0 (and not vice versa).
>
> Secondly, an important point to note thought, is that this conversion
> would also have been required by your way of first converting
> tdb to the tdb2 api! But then you would not have had the
> chance to switch one DB at a time, but all in one stroke.
>
> And then, there were good reasons not to take ntdb for
> 4.0, namely the findings in the performance area that led
> to significant restructurings in the code very shortly before
> the release of 4.0.
>
> After the release of 4.0, the resons we originally had to
> start the tdb2/ntdb project somehow became less important,
> like the size limitation (less important due to data format
> changes and improved vacuuming in the cluster case).
> I think this is mainly, why the ntdb project has not been
> driven further, even though there are many good things
> in the new code/api.
>
> Cheers - Michael
>
>
>
>
> ---------- Forwarded message ----------
> From: paolo turra <turrap72 at gmail.com>
> To: samba-technical at lists.samba.org
> Cc:
> Date: Thu, 20 Mar 2014 09:43:28 +0100
> Subject: Windows 8 pro joining Samba domains, and which ones it just fails
> to join (those with dots in their names)
> I have a Centos 6.5 x86_64 kernel 2.6.32-431.5.1 domain server with samba
> 3.6.9-167 already active. Window 7/XP join to domain regurarly but windows
> 8 professional fails. Searching in google the problem is "." (dot) in the
> domain's name, indeed with the domain name "*domain*" (without* .local*)
> windows8 joint to domain. How can i resolve the problem? Have you an idea?
>
>
>
> Test
>
>
>
> 1. In Windows8 I modify registry:
>
>
>
> *"DNSNameResolutionRequired"=dword:00000000 *
>
> "*DomainCompatibilityMode"=dword:00000001 *
>
> 2. SecPol.msc
>
>
> *Select Local Policies>Security Options>Network Security: LAN Manager
> authorization Level Double click and change to "Send LM & NTLM - use NTLMv2
> session security if .....*
>
>
>
>
>
> Configuration:
>
>
>
> Smb.conf
>
>
>
> [global]
>
> netbios name = dominio
>
> workgroup = domain.local
>
> server string = TEST PDC SERVER
>
> passdb backend = tdbsam
>
> log level = 5
>
> log file = /var/log/samba/log.%m
>
> max log size = 1000
>
> #cups options = raw
>
> os level = 64
>
> preferred master = yes
>
> domain master = yes
>
> local master = yes
>
> security = user
>
> domain logons = yes
>
> logon script = netlogon.bat
>
> logon path =
>
> logon home =
>
> add user script = /usr/sbin/useradd -m %u
>
> delete user script = /usr/sbin/userdel -r %u
>
> add group script = /usr/sbin/groupadd %g
>
> delete group script = /usr/sbin/groupdel %g
>
> add user to group script = /usr/sbin/groupmod -A %u %g
>
> delete user from group script = /usr/sbin/groupmod -R %u %g
>
> add machine script = /usr/sbin/useradd -s /bin/false -d
> /var/lib/nobody %u
>
> #include = /etc/samba/include/%u.conf
>
> username map = /etc/samba/smbusers
>
> socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
> SO_KEEPALIVE_
>
> encrypt passwords = yes
>
> wins support = yes
> #client max protocol = SMB2
>
> Thanks
> Paolo
>
>
>
> ---------- Forwarded message ----------
> From: Bjoern Baumbach <bb at sernet.de>
> To: Marc Muehlfeld <samba at marc-muehlfeld.de>, samba-technical <
> samba-technical at lists.samba.org>
> Cc:
> Date: Thu, 20 Mar 2014 10:25:33 +0100
> Subject: Re: [PATCH] Bug 10239 - log.nmbd never rotates
> On 03/19/2014 05:54 PM, Marc Muehlfeld wrote:
> >> After sending the SIGHUP or using the patch that resets the debug
> >> settings after reading the config, the debug state struct is filled as
> >> expected.
> >
> > This sounds like a bug, I had reported about one year ago:
> > https://bugzilla.samba.org/show_bug.cgi?id=9673
> >
> > Is this the same problem and will your patch fixes this, too?
>
> Hi Marc,
>
> I assume that this is a different issue, but I didn't verify this.
> But you can try to reset the debug setting via
> kill -HUP <pid of the process that writes to log.%m>
>
> The patch fixes the nmbd (only).
>
> If you have success with this, than the reason could be similar to the
> one in bug 10239.
>
> Björn
>
> --
> 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
>
>
>
> ---------- Forwarded message ----------
> From: Volker Lendecke <Volker.Lendecke at SerNet.DE>
> To: Rusty Russell <rusty at samba.org>
> Cc: samba-technical at samba.org
> Date: Thu, 20 Mar 2014 11:35:20 +0100
> Subject: Re: ntdb for Samba 4.2?
> On Thu, Mar 20, 2014 at 03:33:01PM +1030, Rusty Russell wrote:
> > Volker Lendecke <Volker.Lendecke at SerNet.DE> writes:
> > > On Wed, Mar 19, 2014 at 02:48:33PM +1030, Rusty Russell wrote:
> > >> Meanwhile, there's no demand to drive it. TDB has problems, but
> scaling
> > >> over 3GB isn't the main one. The locking speed has been greatly
> > >> improved by the addition of inline mutexes; and so you won't notice
> > >> freelist contention as much. And using dbwrap means the new API
> doesn't
> > >> even make the code cleaner.
> > >
> > > Even with mutexes you do notice freelist contention. The
> > > real kick for this in our tests is the patch from
> > > yesterday: With TDB_VOLATILE we keep some dead records per
> > > chain, and while the freelist is blocked we go fishing for
> > > dead records in other chains. Essentially, this turns each
> > > chain into a small freelist. This together with mutexes
> > > really, really rocks. No futex syscalls around anymore even
> > > for heavily loaded servers. :-)
> >
> > Yes, this is a really good idea. I'd love to see a benchmark
> > included in tdb which demonstrated the improvement, too. I'm
> > not sure tdbtorture will do it.
> >
> > But:
> > 5f7b481349796cc0e90563ed01353809b403e429 tdb: Fix a tdb
> corruption
> >
> > I don't understand how this can corrupt? A test case should be fairly
> > simple, but I think this change is unnecessary.
>
> The test case is simple: Run tdbtorture after adding
> TDB_VOLATILE to the open flag. The problem is that with the
>
> rec_ptr = tdb_find_lock_hash(tdb, key, hash, F_WRLCK, &rec);
>
> in common.c:393 we read the full record including the .next
> pointer. tdb_purge_dead (line 412) can change rec.next in
> the database: If rec.next points at a dead record, then
> tdb_purge_dead will modify rec.next on disk without
> modifying the copy on tdb_delete_hash's stack. Without
> 5f7b481349796cc0e90563ed01353809b403e429 we forced our copy
> to disk, including the now invalid rec.next. The patch
> changes the write call such that only the magic value is
> changed, the rest is untouched.
>
> Hope that explains it.
>
> 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
>
>
>
> ---------- Forwarded message ----------
> From: Felix Botner <botner at univention.de>
> To: samba-technical at samba.org
> Cc:
> Date: Thu, 20 Mar 2014 11:54:57 +0100
> Subject: Unable to complete post-deployment configuration wizard of
> Windows Server Essentials role
> Hi,
>
> i have a Windows Server 2012R2 joined as a member (not dc) into a samba4
> domain with one samba 4.1.0-1 dc (domain level w2k8 r2). After adding the
> Windows Server Essentials role i am asked to configure the role but this
> failes with a very generic "Configuration encountered some issues".
>
> A wireshark trace revealed that the windows server looked for a "Managed
> Service Accounts" container (searchRequest:
> '<WKGUID=1EB93889E40C45DF9F0C64D23BBB6237,DC=PERF,DC=TEST>' baseObject)
> but found none. So i added the container and the WKGUID to the
> wellKnownObjects of the base object and restarted the configuration,
> but again "some issues" during the configuration.
>
> -> ldbadd -H /var/lib/samba/private/sam.ldb <<-%EOF
> dn: CN=Managed Service Accounts,DC=PERF,DC=TEST
> objectClass: container
> cn: Managed Service Accounts
> description: Default container for managed service accounts
> name: Managed Service Accounts
> %EOF
>
> -> ldbmodify -H /var/lib/samba/private/sam.ldb <<-%EOF
> dn: $samba4_ldap_base
> changetype: modify
> add: wellKnownObjects
> wellKnownObjects: B:32:1EB93889E40C45DF9F0C64D23BBB6237:CN=Managed Service
> Accounts,DC=PERF,DC=TEST
> %EOF
>
> Then i installed Essentials on a W2K12R2 DC (domain level w2k8 r2).
> First, the Managed Service Accounts container already exists here, so this
> is
> maybe something samba has to do in the provisioning. And during the
> successful
> Essentials configuration two Managed Service Accounts are created,
> ServerAdmin
> and MediaAdmin. These accounts are not created if the DC is a samba server
> although the Managed Service Accounts container exists.
>
> I don't know how the Essentials configuration creates these accounts,
> but on the windows server in the samba domain the powerShell cmdlets for
> managing Managed Service Accounts do not work. Maybe this is the reason the
> configuration fails.
>
> (
> http://blogs.technet.com/b/askds/archive/2009/09/10/managed-service-accounts-understanding-implementing-best-practices-and-troubleshooting.aspx
> )
> Get-ADServiceAccount, New-ADServiceAccount, Install-ADS...
> -> "Unable to find a default server with Active Directory Web Services
> running"
>
> I also tried to create these accounts on my samba dc but that doesn't help
> either.
>
> Does samba support this "Managed Service Accounts" feature?
> Does anybody successfully configured the Windows Server Essentials
> Experience
> role in a samba domain?
>
> attachments:
> Managed Service Accounts container and DC object from the W2K12R2 DC after
> the successful configuration of the Essentials role.
>
> --
>
> Felix Botner
>
> Open Source Software Engineer
>
> Univention GmbH
> be open
> Mary-Somerville-Str.1
> 28359 Bremen
> Tel. : +49 421 22232-0
> Fax : +49 421 22232-99
>
> <botner at univention.de>
> http://www.univention.de
>
> Geschäftsführer: Peter H. Ganten
> HRB 20755 Amtsgericht Bremen
> Steuer-Nr.: 71-597-02876
>
> ---------- Forwarded message ----------
> From: Michael Adam <obnox at samba.org>
> To: Volker Lendecke <Volker.Lendecke at SerNet.DE>, Rusty Russell <
> rusty at samba.org>
> Cc: samba-technical at samba.org
> Date: Thu, 20 Mar 2014 12:12:49 +0100
> Subject: Re: ntdb for Samba 4.2?
> On 2014-03-20 at 11:35 +0100, Volker Lendecke wrote:
> > On Thu, Mar 20, 2014 at 03:33:01PM +1030, Rusty Russell wrote:
> > >
> > > But:
> > > 5f7b481349796cc0e90563ed01353809b403e429 tdb: Fix a tdb
> corruption
> > >
> > > I don't understand how this can corrupt? A test case should be fairly
> > > simple, but I think this change is unnecessary.
> >
> > The test case is simple: Run tdbtorture after adding
> > TDB_VOLATILE to the open flag. The problem is that with the
> >
> > rec_ptr = tdb_find_lock_hash(tdb, key, hash, F_WRLCK, &rec);
> >
> > in common.c:393 we read the full record including the .next
> > pointer. tdb_purge_dead (line 412) can change rec.next in
> > the database: If rec.next points at a dead record, then
> > tdb_purge_dead will modify rec.next on disk without
> > modifying the copy on tdb_delete_hash's stack. Without
> > 5f7b481349796cc0e90563ed01353809b403e429 we forced our copy
> > to disk, including the now invalid rec.next. The patch
> > changes the write call such that only the magic value is
> > changed, the rest is untouched.
>
> Rusty,
>
> Please note that this corruption had only
> been added recently by my patch
> "cde8e290c9195cbc7a2388455df9e76a1f36135f"
> wich was intended to simplify the code.
> It moved the searching of the record to be deleted
> to a common place at the top, before the purge_dead
> is called. I missed the subtlety that was discovered
> by Volker.
>
> So Volker's patch was not necessary before my patch,
> now it is. (alternative would have been to revert my
> patch, but I think this way it is even better. :-)
>
> Sorry, for the fuss..
>
> Cheers - Michael
>
>
>
> ---------- Forwarded message ----------
> From: Volker Lendecke <Volker.Lendecke at SerNet.DE>
> To: Rusty Russell <rusty at samba.org>
> Cc: samba-technical at samba.org
> Date: Thu, 20 Mar 2014 12:29:00 +0100
> Subject: Re: ntdb for Samba 4.2?
> On Thu, Mar 20, 2014 at 03:33:01PM +1030, Rusty Russell wrote:
> > The rest of the patches look really nice. By changing to first fit you
> > may increase fragmentation, but since TDBs are already so fragmented I
> > don't think it'll be measurable.
>
> Hmm. 255edd1 at least intends to change the first fit to
> best fit. Did I miss anything?
>
> 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
>
>
>
> ---------- Forwarded message ----------
> From: David Disseldorp <ddiss at samba.org>
> To: samba-technical at lists.samba.org
> Cc: David Disseldorp <ddiss at samba.org>
> Date: Thu, 20 Mar 2014 14:23:01 +0100
> Subject: [PATCH] ctdb/pmda: Fix metric identifiers
> The commit "pmda: Use upstream assigned PCP domain id" updated the
> Performance Metrics Namespace (pmns) file, without changing the
> corresponding metric identifiers used by the agent.
>
> This change fixes the agent metric identifier values to match the pmns
> definitions.
>
> Signed-off-by: David Disseldorp <ddiss at samba.org>
> ---
> ctdb/utils/pmda/pmda_ctdb.c | 264
> +++++++++++++++++++++++---------------------
> 1 file changed, 141 insertions(+), 123 deletions(-)
>
> diff --git a/ctdb/utils/pmda/pmda_ctdb.c b/ctdb/utils/pmda/pmda_ctdb.c
> index e8033be..6e034ba 100644
> --- a/ctdb/utils/pmda/pmda_ctdb.c
> +++ b/ctdb/utils/pmda/pmda_ctdb.c
> @@ -50,112 +50,112 @@ static pmdaMetric metrictab[] = {
> { NULL, { PMDA_PMID(0,0), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_INSTANT,
> PMDA_PMUNITS(0,0,0,0,0,0) }, },
> /* frozen */
> - { NULL, { PMDA_PMID(1,2), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_INSTANT,
> + { NULL, { PMDA_PMID(0,1), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_INSTANT,
> PMDA_PMUNITS(0,0,0,0,0,0) }, },
> /* recovering */
> - { NULL, { PMDA_PMID(3,3), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_INSTANT,
> + { NULL, { PMDA_PMID(0,2), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_INSTANT,
> PMDA_PMUNITS(0,0,0,0,0,0) }, },
> /* client_packets_sent */
> - { NULL, { PMDA_PMID(4,4), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> + { NULL, { PMDA_PMID(0,3), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> PMDA_PMUNITS(0,0,1,0,0,PM_COUNT_ONE) }, },
> /* client_packets_recv */
> - { NULL, { PMDA_PMID(5,5), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> + { NULL, { PMDA_PMID(0,4), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> PMDA_PMUNITS(0,0,1,0,0,PM_COUNT_ONE) }, },
> /* node_packets_sent */
> - { NULL, { PMDA_PMID(6,6), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> + { NULL, { PMDA_PMID(0,5), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> PMDA_PMUNITS(0,0,1,0,0,PM_COUNT_ONE) }, },
> /* node_packets_recv */
> - { NULL, { PMDA_PMID(7,7), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> + { NULL, { PMDA_PMID(0,6), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> PMDA_PMUNITS(0,0,1,0,0,PM_COUNT_ONE) }, },
> /* keepalive_packets_sent */
> - { NULL, { PMDA_PMID(8,8), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> + { NULL, { PMDA_PMID(0,7), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> PMDA_PMUNITS(0,0,1,0,0,PM_COUNT_ONE) }, },
> /* keepalive_packets_recv */
> - { NULL, { PMDA_PMID(9,9), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> + { NULL, { PMDA_PMID(0,8), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> PMDA_PMUNITS(0,0,1,0,0,PM_COUNT_ONE) }, },
> /* req_call */
> - { NULL, { PMDA_PMID(10,10), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> + { NULL, { PMDA_PMID(1,0), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> PMDA_PMUNITS(0,0,1,0,0,PM_COUNT_ONE) }, },
> /* reply_call */
> - { NULL, { PMDA_PMID(10,11), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> + { NULL, { PMDA_PMID(1,1), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> PMDA_PMUNITS(0,0,1,0,0,PM_COUNT_ONE) }, },
> /* req_dmaster */
> - { NULL, { PMDA_PMID(10,12), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> + { NULL, { PMDA_PMID(1,2), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> PMDA_PMUNITS(0,0,1,0,0,PM_COUNT_ONE) }, },
> /* reply_dmaster */
> - { NULL, { PMDA_PMID(10,13), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> + { NULL, { PMDA_PMID(1,3), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> PMDA_PMUNITS(0,0,1,0,0,PM_COUNT_ONE) }, },
> /* reply_error */
> - { NULL, { PMDA_PMID(10,14), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> + { NULL, { PMDA_PMID(1,4), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> PMDA_PMUNITS(0,0,1,0,0,PM_COUNT_ONE) }, },
> /* req_message */
> - { NULL, { PMDA_PMID(10,15), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> + { NULL, { PMDA_PMID(1,5), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> PMDA_PMUNITS(0,0,1,0,0,PM_COUNT_ONE) }, },
> /* req_control */
> - { NULL, { PMDA_PMID(10,16), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> + { NULL, { PMDA_PMID(1,6), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> PMDA_PMUNITS(0,0,1,0,0,PM_COUNT_ONE) }, },
> /* reply_control */
> - { NULL, { PMDA_PMID(10,17), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> + { NULL, { PMDA_PMID(1,7), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> PMDA_PMUNITS(0,0,1,0,0,PM_COUNT_ONE) }, },
> /* req_call */
> - { NULL, { PMDA_PMID(11,18), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> + { NULL, { PMDA_PMID(2,0), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> PMDA_PMUNITS(0,0,1,0,0,PM_COUNT_ONE) }, },
> /* req_message */
> - { NULL, { PMDA_PMID(11,19), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> + { NULL, { PMDA_PMID(2,1), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> PMDA_PMUNITS(0,0,1,0,0,PM_COUNT_ONE) }, },
> /* req_control */
> - { NULL, { PMDA_PMID(11,20), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> + { NULL, { PMDA_PMID(2,2), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> PMDA_PMUNITS(0,0,1,0,0,PM_COUNT_ONE) }, },
> /* call */
> - { NULL, { PMDA_PMID(12,21), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> + { NULL, { PMDA_PMID(3,0), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> PMDA_PMUNITS(0,0,1,0,0,0) }, },
> /* control */
> - { NULL, { PMDA_PMID(12,22), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> + { NULL, { PMDA_PMID(3,1), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> PMDA_PMUNITS(0,0,1,0,0,0) }, },
> /* traverse */
> - { NULL, { PMDA_PMID(12,23), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> + { NULL, { PMDA_PMID(3,2), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> PMDA_PMUNITS(0,0,1,0,0,0) }, },
> /* total_calls */
> - { NULL, { PMDA_PMID(13,24), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> + { NULL, { PMDA_PMID(0,9), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> PMDA_PMUNITS(0,0,1,0,0,PM_COUNT_ONE) }, },
> /* pending_calls */
> - { NULL, { PMDA_PMID(14,25), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_INSTANT,
> + { NULL, { PMDA_PMID(0,10), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_INSTANT,
> PMDA_PMUNITS(0,0,0,0,0,0) }, },
> /* locks.num_calls */
> - { NULL, { PMDA_PMID(15,27), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> + { NULL, { PMDA_PMID(0,11), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> PMDA_PMUNITS(0,0,1,0,0,PM_COUNT_ONE) }, },
> - /* locks.pending_calls */
> - { NULL, { PMDA_PMID(16,27), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_INSTANT,
> + /* locks.num_pending */
> + { NULL, { PMDA_PMID(0,12), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_INSTANT,
> PMDA_PMUNITS(0,0,0,0,0,0) }, },
> /* childwrite_calls */
> - { NULL, { PMDA_PMID(17,28), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> + { NULL, { PMDA_PMID(0,13), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_COUNTER,
> PMDA_PMUNITS(0,0,1,0,0,PM_COUNT_ONE) }, },
> /* pending_childwrite_calls */
> - { NULL, { PMDA_PMID(18,29), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_INSTANT,
> + { NULL, { PMDA_PMID(0,14), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_INSTANT,
> PMDA_PMUNITS(0,0,0,0,0,0) }, },
> /* memory_used */
> - { NULL, { PMDA_PMID(19,30), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_INSTANT,
> + { NULL, { PMDA_PMID(0,15), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_INSTANT,
> PMDA_PMUNITS(1,0,0,PM_SPACE_BYTE,0,0) }, },
> /* max_hop_count */
> - { NULL, { PMDA_PMID(20,31), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_INSTANT,
> + { NULL, { PMDA_PMID(0,16), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_INSTANT,
> PMDA_PMUNITS(0,0,0,0,0,0) }, },
> - /* max_reclock_ctdbd */
> - { NULL, { PMDA_PMID(21,32), PM_TYPE_DOUBLE, PM_INDOM_NULL,
> PM_SEM_INSTANT,
> + /* reclock.ctdbd.max */
> + { NULL, { PMDA_PMID(0,17), PM_TYPE_DOUBLE, PM_INDOM_NULL,
> PM_SEM_INSTANT,
> PMDA_PMUNITS(0,1,0,0,PM_TIME_SEC,0) }, },
> - /* max_reclock_recd */
> - { NULL, { PMDA_PMID(22,33), PM_TYPE_DOUBLE, PM_INDOM_NULL,
> PM_SEM_INSTANT,
> + /* reclock.recd.max */
> + { NULL, { PMDA_PMID(0,18), PM_TYPE_DOUBLE, PM_INDOM_NULL,
> PM_SEM_INSTANT,
> PMDA_PMUNITS(0,1,0,0,PM_TIME_SEC,0) }, },
> - /* max_call_latency */
> - { NULL, { PMDA_PMID(23,34), PM_TYPE_DOUBLE, PM_INDOM_NULL,
> PM_SEM_INSTANT,
> + /* call_latency.max */
> + { NULL, { PMDA_PMID(0,19), PM_TYPE_DOUBLE, PM_INDOM_NULL,
> PM_SEM_INSTANT,
> PMDA_PMUNITS(0,1,0,0,PM_TIME_SEC,0) }, },
> /* locks.latency.max */
> - { NULL, { PMDA_PMID(24,35), PM_TYPE_DOUBLE, PM_INDOM_NULL,
> PM_SEM_INSTANT,
> + { NULL, { PMDA_PMID(0,20), PM_TYPE_DOUBLE, PM_INDOM_NULL,
> PM_SEM_INSTANT,
> PMDA_PMUNITS(0,1,0,0,PM_TIME_SEC,0) }, },
> /* childwrite_latency.max */
> - { NULL, { PMDA_PMID(25,36), PM_TYPE_DOUBLE, PM_INDOM_NULL,
> PM_SEM_INSTANT,
> + { NULL, { PMDA_PMID(0,21), PM_TYPE_DOUBLE, PM_INDOM_NULL,
> PM_SEM_INSTANT,
> PMDA_PMUNITS(0,1,0,0,PM_TIME_SEC,0) }, },
> /* num_recoveries */
> - { NULL, { PMDA_PMID(26,37), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_INSTANT,
> + { NULL, { PMDA_PMID(0,22), PM_TYPE_U32, PM_INDOM_NULL,
> PM_SEM_INSTANT,
> PMDA_PMUNITS(0,0,0,0,0,0) }, },
> };
>
> @@ -276,31 +276,111 @@ pmda_ctdb_daemon_disconnect(void)
> }
>
> static int
> -fill_node(unsigned int item, pmAtomValue *atom)
> +fill_base(unsigned int item, pmAtomValue *atom)
> {
> switch (item) {
> + case 0:
> + atom->ul = stats->num_clients;
> + break;
> + case 1:
> + atom->ul = stats->frozen;
> + break;
> + case 2:
> + atom->ul = stats->recovering;
> + break;
> + case 3:
> + atom->ul = stats->client_packets_sent;
> + break;
> + case 4:
> + atom->ul = stats->client_packets_recv;
> + break;
> + case 5:
> + atom->ul = stats->node_packets_sent;
> + break;
> + case 6:
> + atom->ul = stats->node_packets_recv;
> + break;
> + case 7:
> + atom->ul = stats->keepalive_packets_sent;
> + break;
> + case 8:
> + atom->ul = stats->keepalive_packets_recv;
> + break;
> + case 9:
> + atom->ul = stats->total_calls;
> + break;
> case 10:
> - atom->ul = stats->node.req_call;
> + atom->ul = stats->pending_calls;
> break;
> case 11:
> - atom->ul = stats->node.reply_call;
> + atom->ul = stats->locks.num_calls;
> break;
> case 12:
> - atom->ul = stats->node.req_dmaster;
> + atom->ul = stats->locks.num_pending;
> break;
> case 13:
> - atom->ul = stats->node.reply_dmaster;
> + atom->ul = stats->childwrite_calls;
> break;
> case 14:
> - atom->ul = stats->node.reply_error;
> + atom->ul = stats->pending_childwrite_calls;
> break;
> case 15:
> - atom->ul = stats->node.req_message;
> + atom->ul = stats->memory_used;
> break;
> case 16:
> - atom->ul = stats->node.req_control;
> + atom->ul = stats->max_hop_count;
> break;
> case 17:
> + atom->d = stats->reclock.ctdbd.max;
> + break;
> + case 18:
> + atom->d = stats->reclock.recd.max;
> + break;
> + case 19:
> + atom->d = stats->call_latency.max;
> + break;
> + case 20:
> + atom->d = stats->locks.latency.max;
> + break;
> + case 21:
> + atom->d = stats->childwrite_latency.max;
> + break;
> + case 22:
> + atom->d = stats->num_recoveries;
> + break;
> + default:
> + return PM_ERR_PMID;
> + }
> +
> + return 0;
> +}
> +
> +static int
> +fill_node(unsigned int item, pmAtomValue *atom)
> +{
> + switch (item) {
> + case 0:
> + atom->ul = stats->node.req_call;
> + break;
> + case 1:
> + atom->ul = stats->node.reply_call;
> + break;
> + case 2:
> + atom->ul = stats->node.req_dmaster;
> + break;
> + case 3:
> + atom->ul = stats->node.reply_dmaster;
> + break;
> + case 4:
> + atom->ul = stats->node.reply_error;
> + break;
> + case 5:
> + atom->ul = stats->node.req_message;
> + break;
> + case 6:
> + atom->ul = stats->node.req_control;
> + break;
> + case 7:
> atom->ul = stats->node.reply_control;
> break;
> default:
> @@ -310,17 +390,18 @@ fill_node(unsigned int item, pmAtomValue *atom)
> return 0;
> }
>
> +
> static int
> fill_client(unsigned int item, pmAtomValue *atom)
> {
> switch (item) {
> - case 18:
> + case 0:
> atom->ul = stats->client.req_call;
> break;
> - case 19:
> + case 1:
> atom->ul = stats->client.req_message;
> break;
> - case 20:
> + case 2:
> atom->ul = stats->client.req_control;
> break;
> default:
> @@ -334,13 +415,13 @@ static int
> fill_timeout(unsigned int item, pmAtomValue *atom)
> {
> switch (item) {
> - case 21:
> + case 0:
> atom->ul = stats->timeouts.call;
> break;
> - case 22:
> + case 1:
> atom->ul = stats->timeouts.control;
> break;
> - case 23:
> + case 2:
> atom->ul = stats->timeouts.traverse;
> break;
> default:
> @@ -372,92 +453,29 @@ pmda_ctdb_fetch_cb(pmdaMetric *mdesc, unsigned int
> inst, pmAtomValue *atom)
>
> switch (id->cluster) {
> case 0:
> - atom->ul = stats->num_clients;
> + ret = fill_base(id->item, atom);
> + if (ret) {
> + goto err_out;
> + }
> break;
> case 1:
> - atom->ul = stats->frozen;
> - break;
> - case 3:
> - atom->ul = stats->recovering;
> - break;
> - case 4:
> - atom->ul = stats->client_packets_sent;
> - break;
> - case 5:
> - atom->ul = stats->client_packets_recv;
> - break;
> - case 6:
> - atom->ul = stats->node_packets_sent;
> - break;
> - case 7:
> - atom->ul = stats->node_packets_recv;
> - break;
> - case 8:
> - atom->ul = stats->keepalive_packets_sent;
> - break;
> - case 9:
> - atom->ul = stats->keepalive_packets_recv;
> - break;
> - case 10:
> ret = fill_node(id->item, atom);
> if (ret) {
> goto err_out;
> }
> break;
> - case 11:
> + case 2:
> ret = fill_client(id->item, atom);
> if (ret) {
> goto err_out;
> }
> break;
> - case 12:
> + case 3:
> ret = fill_timeout(id->item, atom);
> if (ret) {
> goto err_out;
> }
> break;
> - case 13:
> - atom->ul = stats->total_calls;
> - break;
> - case 14:
> - atom->ul = stats->pending_calls;
> - break;
> - case 15:
> - atom->ul = stats->locks.num_calls;
> - break;
> - case 16:
> - atom->ul = stats->locks.num_pending;
> - break;
> - case 17:
> - atom->ul = stats->childwrite_calls;
> - break;
> - case 18:
> - atom->ul = stats->pending_childwrite_calls;
> - break;
> - case 19:
> - atom->ul = stats->memory_used;
> - break;
> - case 20:
> - atom->ul = stats->max_hop_count;
> - break;
> - case 21:
> - atom->d = stats->reclock.ctdbd.max;
> - break;
> - case 22:
> - atom->d = stats->reclock.recd.max;
> - break;
> - case 23:
> - atom->d = stats->call_latency.max;
> - break;
> - case 24:
> - atom->d = stats->locks.latency.max;
> - break;
> - case 25:
> - atom->d = stats->childwrite_latency.max;
> - break;
> - case 26:
> - atom->d = stats->num_recoveries;
> - break;
> default:
> return PM_ERR_PMID;
> }
> --
> 1.8.4.5
>
>
>
> ...
More information about the samba-technical
mailing list