truncated gitlab samba-ad-dc-5 pipeline logs

[Stefan Metzmacher]

Am 12.02.21 um 04:42 schrieb Douglas Bagnall via samba-technical:
> 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.

Maybe we can drop these messages similar to SAMBA_DEPRECATED_SUPPRESS,
that some maybe set globally in selftest.pl.

> 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,())?

Maybe not, but I think a fix would more that we remember the failure in
repsFrom/repsTo and also throttle the retries.

The same also happens in real world installations, when a dc is not available.

metze


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20210212/6a1288e4/signature.sig>