From owner-freebsd-ports@freebsd.org Tue Oct 29 08:53:27 2019 Return-Path: Delivered-To: freebsd-ports@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7940917F74D for ; Tue, 29 Oct 2019 08:53:27 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 472QNR0sJdz4GdR for ; Tue, 29 Oct 2019 08:53:27 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: by mailman.nyi.freebsd.org (Postfix) id 1D7CE17F74C; Tue, 29 Oct 2019 08:53:27 +0000 (UTC) Delivered-To: ports@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1D3E117F74B for ; Tue, 29 Oct 2019 08:53:27 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 472QNP5Z9Tz4GdQ for ; Tue, 29 Oct 2019 08:53:25 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id C207FAEC35; Tue, 29 Oct 2019 09:53:20 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyq68BKvHaPE; Tue, 29 Oct 2019 09:53:19 +0100 (CET) Received: from [192.168.10.9] (vaio [192.168.10.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id C9449AEC34; Tue, 29 Oct 2019 09:53:19 +0100 (CET) Subject: Re: packaging a port that uses npm during build. To: Adam Weinberger Cc: "ports@freebsd.org" References: <4f4ba55b-fc5e-f700-2d78-e0c210453d4d@digiware.nl> From: Willem Jan Withagen Message-ID: <0a027c56-79e9-4915-bac1-61de4d0da2d0@digiware.nl> Date: Tue, 29 Oct 2019 09:53:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: nl X-Rspamd-Queue-Id: 472QNP5Z9Tz4GdQ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of wjw@digiware.nl designates 2001:4cb8:90:ffff::3 as permitted sender) smtp.mailfrom=wjw@digiware.nl X-Spamd-Result: default: False [-4.32 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[digiware.nl]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; IP_SCORE(-2.02)[ip: (-9.53), asn: 28878(-0.57), country: NL(0.02)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:28878, ipnet:2001:4cb8::/29, country:NL]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2019 08:53:27 -0000 On 29-10-2019 01:41, Adam Weinberger wrote: > On Mon, Oct 28, 2019 at 6:34 AM Willem Jan Withagen wrote: >> On 28-10-2019 13:28, Adam Weinberger wrote: >>> On Mon, Oct 28, 2019 at 5:17 AM Willem Jan Withagen wrote: >>>> Hi, >>>> >>>> The ceph ports should have a manager module called dashboard that >>>> exists of a large bundle op JS-scripts that get installed with npm/node >>>> during running make on the configured build. >>>> >>>> Uptil now I've exclude that from builds, but that gets more and more >>>> complicated. Ceph cluster status is not reported not healty if the >>>> dashboard is not running.... >>>> >>>> Apart from the fact that npm does not like to be ran as 'root', >>>> poudriere also complains about fetching data afte the fetch fase. >>>> >>>> There are about 1000 npm-modules included in this project. >>>> So that would be a large set of things to maintain correctly. >>>> >>>> Is there a way around this? >>>> Or does anybody here have experience with this? >>>> >>>> I think I read once somewhere that there is also a "flag" that indicates >>>> that the port wants network access during the build. Is that feasible? >>> Can the modules be installed after installation? As in, does a >>> package.json get installed somewhere? If so, I'd put the `npm install` >>> instructions in pkg-message. >> I'd have to dig deeper, but as far as I can now see it is a rather >> convoluted part of the Cmake infra that gets called by gmake to run >> several scripts and others... >> But the hint is very temping if it was only like: call npm in something >> like /usr/local/share/ceph/dasboard/frontend > It looks like in the tarball there is > src/pybind/mgr/dashboard/frontend/package.json. Does this have what > you're looking for? Yup, ATM I'm testing to see if your trick works and just cd to     /usr/local/share/ceph/mgr/dashboard/frontend and go     npm ci Question is: will this deliver a working dashboard. It looks like it, but I'm still missing some other components. So I guess that the plan will be an addendum to the post install text. Note that this will delivers an incomplete setup, untill this is manually fixed by the operator. >>> The flag you're talking about has to go in poudriere.conf, so it >>> wouldn't be able to help much here. It's for local control. >> Bummer... >> What is the latest moment a (Make)script can get access to the network? >> Tried finding this in the porters manual, but could not find that detail. > The fetch phase is the only time that the network is available, > unfortunately. It's a great feature, though it does require rethinking > in situations like this. I think I understand the rationale behind it, but now the user starts donwloading things himself post install. Not per definition increasing the level of security. --WjW