From ec37ca2901f0e88347f1e71f35c15ffc50e2f7ba Mon Sep 17 00:00:00 2001 From: distix ticketing system Date: Sun, 1 Apr 2018 11:38:03 +0000 Subject: imported mails --- .../Maildir/new/1522582683.M684766P14442Q1.koom | 148 +++++++++++++++++++++ 1 file changed, 148 insertions(+) create mode 100644 tickets/4bbc9995f89d40c59451b743be4a4811/Maildir/new/1522582683.M684766P14442Q1.koom diff --git a/tickets/4bbc9995f89d40c59451b743be4a4811/Maildir/new/1522582683.M684766P14442Q1.koom b/tickets/4bbc9995f89d40c59451b743be4a4811/Maildir/new/1522582683.M684766P14442Q1.koom new file mode 100644 index 0000000..93932db --- /dev/null +++ b/tickets/4bbc9995f89d40c59451b743be4a4811/Maildir/new/1522582683.M684766P14442Q1.koom @@ -0,0 +1,148 @@ +Return-Path: +X-Original-To: distix@pieni.net +Delivered-To: distix@pieni.net +Received: from yaffle.pepperfish.net (yaffle.pepperfish.net [88.99.213.221]) + by pieni.net (Postfix) with ESMTPS id 6670942EEC + for ; Sun, 1 Apr 2018 11:37:11 +0000 (UTC) +Received: from platypus.pepperfish.net (unknown [10.112.101.20]) + by yaffle.pepperfish.net (Postfix) with ESMTP id 0B725417C5 + for ; Sun, 1 Apr 2018 12:37:11 +0100 (BST) +Received: from ip6-localhost.nat ([::1] helo=platypus.pepperfish.net) + by platypus.pepperfish.net with esmtp (Exim 4.80 #2 (Debian)) + id 1f2bIM-0004FR-Vt; Sun, 01 Apr 2018 12:37:10 +0100 +Received: from [10.112.101.103] (helo=mx3.pepperfish.net) + by platypus.pepperfish.net with esmtps (Exim 4.80 #2 (Debian)) + id 1f2bIL-0004FD-RI + for ; Sun, 01 Apr 2018 12:37:09 +0100 +Received: from mail.steve.org.uk ([176.9.183.102] helo=ssh.steve.org.uk) + by mx3.pepperfish.net with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) + (Exim 4.84_2) (envelope-from ) + id 1f2bII-0004oH-Cm + for ick-discuss@ick.liw.fi; Sun, 01 Apr 2018 12:37:09 +0100 +DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; + d=steve.org.uk; s=20150726; h=References:In-Reply-To:Message-ID:Date:Subject: + From:Cc:To:Sender:Reply-To:MIME-Version:Content-Type: + Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: + Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: + List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; + bh=tai3oUY8wIGE9uoKrRpALz4Jsr7wkkb9GjT+IeETq9c=; b=R1hOKe5R5wlGuhh2dPlbbc9JF + YdutDBOrrXzIKPLxfxziEs+xlZJV2VC33e21PBJKntu9Xt9WcKbmWeZPpxZ1Phv2K0ja6YD8JGR/A + UOdy8IDgO+kR2JYHgPdmVmeOIIfS+TR34wkd67hOI/pPMNfVmRvdBt0w/33sB5tf8i5zM=; +Received: from steve by ssh.steve.org.uk with local (Exim 4.89) + (envelope-from ) id 1f2bI6-0002mi-FH + for ick-discuss@ick.liw.fi; Sun, 01 Apr 2018 11:36:54 +0000 +To: ick-discuss@ick.liw.fi +Cc: +From: Steve Kemp +Date: Sun, 01 Apr 2018 11:24:37 +0000 +Message-ID: <1522581877.10476.1@ssh.steve.org.uk> +In-Reply-To: <1522571699.2971.5.camel@liw.fi> +References: <1522571699.2971.5.camel@liw.fi> +X-added-header: steve.org.uk +X-Pepperfish-Transaction: a5f2-dac9-60da-1ebe +X-Spam-Score: -1.9 +X-Spam-Score-int: -18 +X-Spam-Bar: - +X-Scanned-By: pepperfish.net, Sun, 01 Apr 2018 12:37:09 +0100 +X-Spam-Report: Content analysis details: (-1.9 points) + pts rule name description + ---- ---------------------- -------------------------------------------------- + -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay + domain + -0.0 SPF_PASS SPF: sender matches SPF record + -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% + [score: 0.0000] + 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid +X-ACL-Warn: message may be spam +X-Scan-Signature: 3e0b2c8d84541a19cffce3c5c0904f3a +Subject: Re: What's needed before ick is ready for others to use? +X-BeenThere: ick-discuss@ick.liw.fi +X-Mailman-Version: 2.1.5 +Precedence: list +List-Id: discussions about the ick CI system +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +Sender: ick-discuss-bounces@ick.liw.fi +Errors-To: ick-discuss-bounces@ick.liw.fi + +> This morning I've been pondering on the following question: should I +> try to achieve "ready for others to use" as soon as possible, or +> should I concentrate on making sure all existing functionality is of +> high quality? + + I think there are pros and cons to either approach, but one thing + that I'm struggling with myself is the documentation. + + I would love to see an overview of all the moving parts: + + * There is one ick-server / controller. + * This is what it needs + * This is how you configure it. + + * There is one artifact server. + * This is what it needs. + * This is how you configure it. + + * There are N-workers / worker-managers. + * This is what they need. + * This is how you configure them. + + Right now I've spent more time than I'd enjoy getting the + package(s) installed - in the end I resorted to your debian repository + but even that wasn't sufficient. + + Getting the artifact-server running, for example, required installation + of `python3-requests`. There was also some confusion about +`python-cliapp` being a dependency, but the code using `python3-cliapp`, + the latter of which couldn't be installed without forcing, as it + overwrote a file in the previous package. + + The ansible role helps, but the random start-scripts in the top-level + are a distraction. + +> I am leaning towards the former. Perfectionism is good, but it makes +> things take a really long time and if things take too long, I get de- +> motivated. "Write shit, but fix it quickly." + +> What do you all think? Is there something you can think of that ick +> must do before you'd be willing to give it a try? + + I think your list is good, but I'd add documentation. Right now + I suspect there is a security problem with the artifact server, but + despite reading the architecture guide I'm missing the ability to + confirm it. + + I suspect these requests are both problems: + + GET /blobs/../../../etc/passwd + PUT /blobs/../../../etc/owned + + But the GET/PUT both require authentication that I don't know how + to handle. + + Looking at `blob_store.py` we see the code mostly boils down to: + + prefix + name + + Where name is user-submitted. But of course I might be missing + the obvious, maybe bottle is filtering ahead of this code. If that + is the case then things are probably OK, but there is an obvious + design-decision: Should names be unique? If two jobs both upload + an artifact called "latest-amd64.tar.gz" what happens? Should + uploads be namedspaced on job? Or should the second artifact upload + fail? + + +Steve +-- +https://www.steve.org.uk/ + +_______________________________________________ +ick-discuss mailing list +ick-discuss@ick.liw.fi +https://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/ick-discuss-ick.liw.fi -- cgit v1.2.1