[48417] in SIPB bug reports
Re: A proposal to encourage more use of /mit/sipb/bin
daemon@ATHENA.MIT.EDU (seph)
Thu Aug 22 02:20:11 2013
From seph@MIT.EDU Thu Aug 22 06:20:11 2013
Return-Path: <seph@MIT.EDU>
Delivered-To: bug-sipb-mtg@CHARON.mit.edu
Received: (qmail 16063 invoked from network); 22 Aug 2013 06:20:11 -0000
Received: from mailhub-dmz-2.mit.edu (18.7.62.37)
by charon.mit.edu with SMTP; 22 Aug 2013 06:20:11 -0000
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35])
by mailhub-dmz-2.mit.edu (8.13.8/8.9.2) with ESMTP id r7M6JlrE003658;
Thu, 22 Aug 2013 02:20:05 -0400
X-AuditID: 12074423-b7f168e00000095a-5d-5215ad9471aa
Authentication-Results: symauth.service.identifier
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27])
(using TLS with cipher AES256-SHA (256/256 bits))
(Client did not present a certificate)
by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id D7.9A.02394.49DA5125; Thu, 22 Aug 2013 02:20:04 -0400 (EDT)
Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43])
by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 733DF20BD3;
Thu, 22 Aug 2013 02:20:04 -0400 (EDT)
Received: from frontend1 ([10.202.2.160])
by compute3.internal (MEProxy); Thu, 22 Aug 2013 02:20:04 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
messagingengine.com; h=from:to:cc:subject:references:date
:in-reply-to:message-id:mime-version:content-type; s=smtpout;
bh=j+G/EZgg7TJSFUr4Wpi8kXApqm4=; b=KuoMaUwMJZ6hHogxaSBvJTccqc9T
9AawbzuYkZeZU7hl8Aji8uNc5ob/NApv3lR4hJSCs0rJa2+sTz1CuzQHSUzgx3JL
UFIVKHQ8i+0N5pFbFJqF0E7neoyo5kdi+j0moknlSE1I9mdudEbDJCocVTr93BE3
AzA+Kliv9hjEzqw=
X-Sasl-enc: dXs0JyaMolJb3B5ZImbwQJc+FwMkgyS9CVQc5ywr9DEj 1377152404
Received: from vpn2 (unknown [71.19.147.37])
by mail.messagingengine.com (Postfix) with ESMTPA id 1EE4DC00E87;
Thu, 22 Aug 2013 02:20:04 -0400 (EDT)
From: seph <seph@MIT.EDU>
To: Geoffrey Thomas <geofft@mit.edu>
Cc: bug-sipb@mit.edu
Subject: Re: A proposal to encourage more use of /mit/sipb/bin
References: <alpine.DEB.2.00.1308182122200.15460@team-rocket.mit.edu>
Date: Thu, 22 Aug 2013 02:14:47 -0400
In-Reply-To: <alpine.DEB.2.00.1308182122200.15460@team-rocket.mit.edu>
(Geoffrey Thomas's message of "Sun, 18 Aug 2013 22:23:32 -0700 (PDT)")
Message-ID: <ygewqnemeug.fsf@lame.message.id>
User-Agent: Gnus/5.110008 (No Gnus v0.8) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCKsWRWlGSWpSXmKPExsXilM8irTtlrWiQwdM1VhaH3l1ltfiyYxOj
A5NH05mjzAGMUVw2Kak5mWWpRfp2CVwZf2c8Yiy4y1Gx7u1T9gbGqexdjJwcEgImEj3/v7CA
2IwCRhK7z71ihYiLSVy4t56ti5GLQ0jgAJPE5ElnWCCcrYwSx+7dBHI4gJwcifW7REDiLAJ9
zBIvj+yGmuos8ffPXzYQW0hgBqPEma3CIDabgKTEqcPLweIiAioS+2acBqtnFhCRaD4zB+wK
YQE7iYsH57BBzHeVmPSuHiTMIqAqsb93KjPILk6BfkaJebcng93AK6Arsf4JH0iNqIC9xOnf
d8FG8goISpyc+YQFYryWxI1/L5kmMIrMQpKahSS1gJFpFaNsSm6Vbm5iZk5xarJucXJiXl5q
ka6ZXm5miV5qSukmRmCQC7G7KO9g/HNQ6RCjAAejEg/vhZ0iQUKsiWXFlbmHGCU5mJREea0X
iwYJ8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuH16gLK8aYkVlalFuXDpKQ5WJTEeZ89PRsoJJCe
WJKanZpakFoEk2XiYD/EKMPBoSTB67wGqFuwKDU9tSItM6cEWQ0niOACWcMDtObPapA1xQWJ
ucWZ6RBFpxgVpcR5FUEmCIAkMkrz4AbAEtMlRlkpYV5GBgYGIR6gC4AeR5V/xSgO9LQwbwfI
FJ7MvBK46a+AFjMBLZ6tIQSyuCQRISXVwLhdfcrR5c0s5te3f5GxN9Sp6T80Z2mSydefTQmB
tZeWrjVTuxccPUv43HHDmcHV9fN7BF8mrXbaek+ZJVTrkPOqKtYfz/TZm9emLZywafutR1r1
f2bv7Swxu3x+ncNd4aj5B+o3H3pyeTpvI4OSsfMMR8ajjeEZjRtnqqRavLk81cr/qrLu5iAl
luKMREMt5qLiRAC/y61/RwMAAA==
> A couple of us were talking on -c barnowl about the fact that barnowl
> and several other recent projects with widely-used binaries
> (mosh_project comes to mind) use their own lockers instead of the sipb
> locker, which means that, absent additional effort, they lose out on
> replication (including cross-cell replication).
I assume we end up in that state because people start in a locker, and
then something becomes popular, but also entrenched. That pattern
doesn't seem unreasonable. (Nor does using separate lockers for general
sprawl containment)
> What if we instead make e.g. /mit/sipb/bin/barnowl be a symlink to
> /mit/sipb/project/barnowl/bin/barnowl, where /mit/sipb/bin is tightly
> restricted (the same way that making Hesiod pointers is tightly
> restricted), and /mit/sipb/bin is accessible only to barnowl
> maintainers?
I'm kind of mixed. I don't think it solves your replication concerns,
and it creates a pretty complex set of symlinks to manage. Even scripted,
that's a lot of complexity.
How do you feel about athrun/attachandrun scripts in /mit/sipb/bin?
seph
