truncated gitlab samba-ad-dc-5 pipeline logs

Douglas Bagnall douglas.bagnall at catalyst.net.nz
Fri Feb 12 03:42:05 UTC 2021


Since around 18 September last year, the log for a successful
samba-ad-dc-5 job has ended like this:

  Job's log exceeded limit of 4194304 bytes.

e.g. https://gitlab.com/samba-team/devel/samba/-/jobs/744619956

Nobody cares about that, but now I have an *unsuccessful* samba-ad-dc-5
job that ends the same way, which is to say it fails too late to leave
any trace. Of course there couldn't possibly be a problem with my code;
I just want to know the logs agree.

Things I have noticed:

1. Some older samba-ad-dc-5 logs were bigger, and Gitlab allowed that.
They seem to have shrunken the limit.

2. this happened around the time of ZeroLogon, which increased the
verbosity with ~1M of this kind of thing:

client_account[schannel1$] client_computer_name[schannel1]
dcesrv_netr_creds_server_step_check: CVE-2020-1472(ZeroLogon): Check if
option 'server require schannel:schannel1$ = no' might be needed!
dcesrv_netr_creds_server_step_check: CVE-2020-1472(ZeroLogon):
netr_LogonSamLogon request (opnum[2]) without schannel from

which maybe pushed it over the edge.

3. The bulk of the log follows this pattern:

Failed to connect host 10.53.57.14 on port 135 -
NT_STATUS_OBJECT_NAME_NOT_FOUND
Failed to connect host 10.53.57.14
(1cae2ae0-54bf-4728-bf9d-7cc40958d0c6._msdcs.addom.samba.example.com) on
port 135 - NT_STATUS_OBJECT_NAME_NOT_FOUND.

The internet says we can't configure this limit (I checked the admin
screen anyway).

For now I have added a patch to shut up the NOT_FOUNDs; once my original
patches are vindicated, I will look into a proper solution. Does anyone
have any ideas? Do both those connection failure messages need to be
DEBUG(0,())?

Douglas



More information about the samba-technical mailing list