From nobody Fri Jan 21 11:47:14 2022 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 19A32195AAEE for ; Fri, 21 Jan 2022 11:47:28 +0000 (UTC) (envelope-from se@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JgHg34vrPz3kTj; Fri, 21 Jan 2022 11:47:27 +0000 (UTC) (envelope-from se@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1642765647; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Sv0BhVKIfHP4XCA7wkZoTlDKzJIMmoH0jtD2CLYSGk8=; b=voJiAqkvTFsXC5ZJT2huq87yZUcUCkHLBm4flEpw3S1FVFboHKl6qheZtiSDvrT4S66r8d kB6ddME/8PjmqV6GR/hjuOEcacxA0XVVA2m+PFdn2PwcQEbP7O+2WqJKnTszZP3Gn4cwgi OGE81/mRtVB8xh0tI6pLGs4s+uNTtgBvxyVwYLKMtm7pgADSNBH3SJwFwY91Fvfbvthjkj +oIWf+cZhfM0HKgOEtTfIMpEIDbzTIMyZbAsXoesIrtSrOIUjnTgdGRde5WJ28TXOe5Jn2 ys5Pqw5n96OrFryDHiaKm/JWtqgXL3UtqTptZxkrtipcc3h5ED01tJqDTn1JFg== Received: from [IPV6:2003:cd:5f22:3300:8d18:e6a6:fb5e:b723] (p200300cd5f2233008d18e6a6fb5eb723.dip0.t-ipconnect.de [IPv6:2003:cd:5f22:3300:8d18:e6a6:fb5e:b723]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id D9E082A05C; Fri, 21 Jan 2022 11:47:26 +0000 (UTC) (envelope-from se@FreeBSD.org) Message-ID: <0f2c301f-565a-a2b5-3ed1-1a3ffb86aa2c@FreeBSD.org> Date: Fri, 21 Jan 2022 12:47:14 +0100 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: service management and upgrades Content-Language: en-US To: marco+freebsd@crowdsec.net References: From: Stefan Esser Cc: freebsd-ports@freebsd.org In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------5AxunA95RSFGeM08xdMpjhts" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1642765647; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Sv0BhVKIfHP4XCA7wkZoTlDKzJIMmoH0jtD2CLYSGk8=; b=I7KSiuOTkvCTxkJMgw1JNdN5oyu7LXkulVBOcPnfUXxR1JeMsLsKXYezslZ1IAK73/T/iE dFwUmDuGgaopmfZQ+KR/QEeRdI1lHjR96qh3pdg03K+FrjT+tngRWV3u6qbuDuYqzHcsqC 4ZfM1lNHMfmuXp0xHptZOnoZ/1cK1s5Ph+dvlgYhxLVUYnvr40YhAdgySkBwFepQr9hVeO ZVC6wiBGlVfdpzdwuQ0qPoCIemaKbUZBd2o0hI8zi5c2y+P31Yjd4zHKXJhAxhNVZdXGFB VR7QFaU+fK8fsuTPCZX0bJkK1RFGBodgGNYD+LMEqc7DnQAZ12d3IzIuWfQYog== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1642765647; a=rsa-sha256; cv=none; b=vLXO1TkUHGc8J4ahDIqGwMVFBwfJszzkTgCLNEH/EfC+oZd+pLHqhyUm5C3na/7wx48W6V sErU6ifRN70wzniwEyY9SNJFiTNRnutsEkhe+hz6w4XJl+BsAMMzHvG4QWWRssNDMmXez0 /KzottdKUDupHeLBcsw408Z19dLE2M9hBBfk7b5IVt1OiCmRj6fWBM32zuWTHSfsDgCOXS jrQX5H1j6eCEONdFdz9qJ+8GpzmLr4X578q70BXgBv0utHR8O6cnjPnYkPlg/erjW4jzfh 5nYVeRzdbAm5hhYVo1WfsJ+i0dY8uy0oTJcD4l4wW6398gSRQM8kjgybMY6LWw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------5AxunA95RSFGeM08xdMpjhts Content-Type: multipart/mixed; boundary="------------yilCAHSoiJh3b2bkBSlG9dyF"; protected-headers="v1" From: Stefan Esser To: marco+freebsd@crowdsec.net Cc: freebsd-ports@freebsd.org Message-ID: <0f2c301f-565a-a2b5-3ed1-1a3ffb86aa2c@FreeBSD.org> Subject: Re: service management and upgrades References: In-Reply-To: --------------yilCAHSoiJh3b2bkBSlG9dyF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 21.01.22 um 10:03 schrieb marco+freebsd@crowdsec.net: > Hello! >=20 > I have a doubt about service management in the context of my ports. >=20 > We develop a couple of daemons, we can call them agent and bouncer. > They work in cooperation and the pkg-message explains how to enable and= run them > (sysrc _enable=3D"YES"; service start). >=20 > My question is: in case of package removal, do I need to stop the servi= ces myself? This can be required, e.g. if the running service expects to have access to files that will have been removed (e.g. to start as sub-processes). Many ports do not have such a requirement, they process a configuration file at start-up and expect their data directories to continue to exist, but can continue to run even if their package has been deinstalled. This is true for the file serving by the SAMBA server ports, for example,= but not for certain maintenance tasks of those ports. This allows to upgrade a running service and then to perform a service restart when the new version is ready to run. It does obviously not work for all ports - you have to know what you are doing ... > I suppose yes, so I have put a "service stop" in pkg-deinstall.i= n > , otherwise the daemons keep running after the= ir > executable and configuration files are removed. You could have mentioned that you are talking about the security/crowdsec= port and security/crowdsec-firewall-bouncer, but as I understand it in the context of a more complex platform. Is this correct? > The problem comes with package upgrades - as far as I know I have no wa= y to > tell a deinstall from an upgrade, so I cannot restart the dead service = in the > new post-install function. You could use a mechanism outside the ports system to enable restarting of the service. You could for example write a token to a directory that is under control of the service, which indicates it was running at the time if de-installation and that it should be restarted. > This means every time a package is upgraded, its application has to be > restarted by the user (and if the agent goes down, soon the bouncer wil= l go > down too). You do not mention how long those processes could be kept running without= the service. If they can survive over the duration of a "normal" package upgrade, then you'll only have to manually restart them after a failed upgrade. > If the above is correct I can live with that, even if it requires manua= l > intervention. >=20 > But now a third player comes to the field: I have an OPNsense plugin th= at uses > the above two services. It depends on them at installation time, and it= takes > care of enabling and starting/stopping them. So far so good. >=20 > What happens if the agent or the bouncer are upgraded and therefore sto= pped? > The OPNsense plugin has no way to know that they are down and must be r= estarted. The plugin could periodically check their status and try to restart them,= if a reasonable scan period can be found. Maybe the solution is to give the plugin full control over the starting and stopping the service (but only if the plugin is installed, too). The service could have a @preunexec clause in the pkg-plist, which lets the OPNsense plugin expect the service to be stopped and unavailable for some time. The installation of the new version of the service could then signal its availability to the running OPNsense plugin, which could decid= e whether it wants to restart the service. If the OPNserve plugin is not installed or configured to start and stop the service, it could still do it directly via the service command. > The only solution I found (but not applied yet) is putting this on the > pkg-install of the agent and bouncer: "service enabled && servic= e > start". If the OPNsense plugin is central to running the service, then it seems best to have it take control of starting the service. There is no need to disable a service during de-installation, and OPNsense can see that it had been enabled before the new version has been installed and can then assume that the new version should be started, too. > I have found nothing of the sort in the port repository, the post-insta= ll is > usually for configuration and does not run services. You can make liberal use of @{pre,post}exec and ...unexec in pkg-plist. > What am I missing or doing wrong? >=20 > Thank you for your time and suggestions. Let me know if I misunderstood the problem or if the above might work but= is lacking in detail ... Regards, STefan --------------yilCAHSoiJh3b2bkBSlG9dyF-- --------------5AxunA95RSFGeM08xdMpjhts Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmHqnUIFAwAAAAAACgkQR+u171r99USQ wggApLSXzUC2THVWxfvSWrcRK2qPuQmnOVOhRcvvG6aN1X2dDbnqi9Zpjr/Kw8om7KAuTdWG7P21 1LP/BhyVpIOgj6Rma1tyCm79tlzYvYoWlWQ46eIbwKjFqkfePEqhonW9UnCnnw4w+/Z3IQgQAsxi 6eB+O3fJzR6aSmR2Xum/Z1UwI1kRODUzddLk/69dNvyqn/eTD2MB+YGNFavVo5Y0+dfBn4jlG4eD pdUdFCJMoAGWLkPTGRPQS9YERS657TJoivfiyzPXzSzHXIWb4WYnYZ0Jd0h4Cxefb0TmMX+yM7jm R2z6BYZv+5dnvuOiku7gdReywXP9j2NP3bPSGyfL/w== =l9y+ -----END PGP SIGNATURE----- --------------5AxunA95RSFGeM08xdMpjhts--