From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 99C97C43334 for ; Tue, 12 Jul 2022 18:57:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1657652245; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=1ZRqnWeSuJpaVMCyrC1KC4vJHUkWWqdEDtA6SUn3SMw=; b=atQTDaY9XWBWn3F5dHDltnNvFEmp8xExDQd8hZZaWU6aXGy5oL7Wei0ww88bWcDwLT1sB1 TULvcDSEGd5hPN1kRwGIjDcCgrsnRfTxkHSlGg1qTwXXClznrnTNTDmaW0nFesZxVozpr7 b16Ckz0U0hNneIUkUyx4lJHuhPEugxw= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-204-ggSnmYfeOiKDjpEXSpSqRA-1; Tue, 12 Jul 2022 14:57:16 -0400 X-MC-Unique: ggSnmYfeOiKDjpEXSpSqRA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C76FF811767; Tue, 12 Jul 2022 18:57:14 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (unknown [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id 89FE2C202C5; Tue, 12 Jul 2022 18:57:13 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 2E06E1947060; Tue, 12 Jul 2022 18:57:13 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id A14A1194705F for ; Tue, 12 Jul 2022 18:57:11 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 8E3931415118; Tue, 12 Jul 2022 18:57:11 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast01.extmail.prod.ext.rdu2.redhat.com [10.11.55.17]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 89886141510F for ; Tue, 12 Jul 2022 18:57:11 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 7230385A581 for ; Tue, 12 Jul 2022 18:57:11 +0000 (UTC) Received: from pb-smtp1.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-402-Eg06e6X0OOCVhXds2j_RMA-1; Tue, 12 Jul 2022 14:57:02 -0400 X-MC-Unique: Eg06e6X0OOCVhXds2j_RMA-1 Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 6C5EC133BA6; Tue, 12 Jul 2022 14:57:02 -0400 (EDT) (envelope-from kenh@pobox.com) Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 43C82133BA5; Tue, 12 Jul 2022 14:57:02 -0400 (EDT) (envelope-from kenh@pobox.com) Received: from pietro.internal (unknown [72.66.57.248]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id A1C00133BA2; Tue, 12 Jul 2022 14:57:01 -0400 (EDT) (envelope-from kenh@pobox.com) From: Ken Hornstein To: Steve Grubb Subject: Re: Trying to understand audisp-remote network behavior In-Reply-To: <5592113.DvuYhMxLoT@x2> References: <20220707040529.DFABD138817@pb-smtp1.pobox.com> <13478993.uLZWGnKmhe@x2> <20220712021441.1075B12DBDC@pb-smtp1.pobox.com> <5592113.DvuYhMxLoT@x2> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` MIME-Version: 1.0 Date: Tue, 12 Jul 2022 14:57:00 -0400 X-Pobox-Relay-ID: 69DC8732-0214-11ED-8FE3-5E84C8D8090B-90216062!pb-smtp1.pobox.com Message-Id: <20220712185702.43C82133BA5@pb-smtp1.pobox.com> X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 2.85 on 10.11.54.7 X-BeenThere: linux-audit@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Audit Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-audit@redhat.com Errors-To: linux-audit-bounces@redhat.com Sender: "Linux-audit" X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=linux-audit-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >> Well, the default configuration is that heartbeats are turned off, so >> the general impression I would take away from that is you should only >> turn on heartbeats if you have some unusual requirement. > >This has to be coordinated between the client and server as many of these >setting need to be. I can add some discussion to the man page that this is >recommended. Errr ... does it? I certainly turned them on all of our clients but did not on turn them on our server. Did not cause any problems. I mean, yes, I could see that turning them on the server might be helpful, but it doesn't seem to be required to make them work; from my reading of the code that the server will respond to a heartbeat message whether or not they are configured, and since connections all initiate from the clients that's the end that has to notice the connection has dropped. And yes, some additional documentation might be helpful. Like if there was a note in the man page that said, "Enabling heartbeats is the only way to ensure that a connection will be retried if it is lost", that might have clued me in that heartbeats are essentially required for reliable connectivity (I am assuming we all agree that statement is true; as far as I can tell, even with the latest code it still is!). --Ken -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit