From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by ewsd; Wed Jul 29 18:36:58 EDT 2020 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id CC4905C00A8 for <9front@9front.org>; Wed, 29 Jul 2020 18:36:56 -0400 (EDT) Received: from imap35 ([10.202.2.85]) by compute1.internal (MEProxy); Wed, 29 Jul 2020 18:36:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=fxprdPVjBSHFExpf/hMQ9MPv5Llzbvh kDf9UlozFktU=; b=wDbI/XEWELEzVOcUOfGJrZs9oxs5eAkSa4DqrR++Bs2SmyG 8UdJvWJpoJp3QCcodRK276rlysHnWRFuAXmBH4fz5pH3WJOyYWrCCOmr/+yT0Q55 dfM5z5RK4+WqFJkF50bumkt5GGAKTZsiSBUJB5/ANIH2NrWZektYd63wTeC+DvfO WCti3vN+4t6u7IoO94SfZHU3s1pXchi39OyobopF7+2LT+nDlRnG5JGOLiQDQ3MI UkCK75pDF52nGFa22OITaIrTkmB94GoRhsANoduDO9CTzvsxbKWF8wsOzSmhLwim UrwZAnJpxzJuF1bCDo7T2ztIE655jSzF97+8n0A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=fxprdP VjBSHFExpf/hMQ9MPv5LlzbvhkDf9UlozFktU=; b=NNC3+XfXP1GqaxocWUjNSZ U8np/KpP1k0ECP90fsbhYBBgOnB95zBGWnbcLGCoifHZQ4hNn3DNEewF6bmzt81F 7qhtbpmcX0jfF4s0RUJSmjLVCwcfPxTWG19vOq63BOnjhmDlURBS+LB+Z1u9LB42 3f4s8/adukGWx4TIuT5vbnKIS4niil+5kk0CYwGl9Zb8nsmHOqisU1hA2NiTPpbQ EpU33quP7bYe8Pr0wxOBMt4KEHxZSJW/XMrKaMWdxuWZx8I9gutPvWg7O80SHoMX YKPDeH68TEjRe+rl6CCai/ecHJG2cQ66nxM7OoD0XESH0Ky7QoFWzu2Guryj+8gg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrieehgdduvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdfgthhhrghnucfirghruggvnhgvrhdfuceovggvkhgvvgeh jeesfhgrshhtmhgrihhlrdhfmheqnecuggftrfgrthhtvghrnhepffdvtdehgeekfeefgf eufeejudetvdfggfffkefgjefhteekgeevjedvfeeuueeinecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvggvkhgvvgehjeesfhgrshhtmhgrih hlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5636B14C02C5; Wed, 29 Jul 2020 18:36:56 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-128-gd51a832-fm-20200728.001-gd51a8328 Mime-Version: 1.0 Message-Id: <69df9f0d-1f89-4f06-9834-caf4d7c10439@www.fastmail.com> In-Reply-To: References: Date: Wed, 29 Jul 2020 23:36:36 +0100 From: "Ethan Gardener" To: 9front@9front.org Subject: Re: [9front] The 9 Documentation Project Content-Type: text/plain List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: generic package On Tue, Jul 28, 2020, at 8:10 PM, cinap_lenrek@felloff.net wrote: > i think alot of confusion comes from the auth= atribute in the > ip/ipnet= entry vs. auth= attribute on the authdom= entry. ... > but once you'r booted, factotum will actually look for authdom= > attribute in ndb to resolve the authentication server for a particular > domain presented in the p9any handshake, and IGNORE the auth= > attribute on a host or ipnet completely. i don't think that particular thing got me, but thanks for the clarification. (i think you probably explained it to me in irc, years ago.) > the protocol (omiting nonce and dh/dp9ik steps) works like this: > > 0) client connects to server > 1) server presetns a list of domains, host identities and protocols > 2) client picks a protocol and uses the domain and find the > authentication > server for the domain and does a ticket request > 3) decrypts client part of the ticket with its own password and > extracts shared secret > 4) forwards the server part of the ticket to the server > 5) server decrypts the ticket with his own password and extracts shared > secret > 6) client and server verify that they each other known the shared secret > 7) success. optinally use shared secret to establish encrypted channel > (tlssrtv) > > the step that bugs most people is 2), as in the protocol, only > the authentication DOMAIN is send over the wire. finding the AS > is the job of the CLIENT. i think you told me all this years ago, but i still had trouble. (this is good; it's better to see it in a document rather than chat.) i think my problem was i kept getting confused about the syntax of ndb. what on earth is a "tuple" when it's not one of python's immutable lists? a key-value pair? also, i was never clear on where to put things, despite your help. there's these different sections with different names which make no sense, and it makes no sense why you can't put some netwide-default things in what appears to be the netwide-defaults section... that's what i felt, anyway. > the issue with dns is that newbies dont have dns under their control. > so p9auth is out. srv records is out. the only thing left what we can > do is find ways to avoid this hack and deprecate the auth= attribute. > maybe have dhcpd automatically determine authdom by dialing the root > fileserver and doing the resolution of authserver on behalf of the > client. this! i'm pretty sure my plan 9 machines worked best when i statically set their ips. i also set them up on my natbox so it wouldn't conflict, and when it was time to reconfigure, i thought "why am i setting these twice?" and made it worse. also... i think that one time i set the ips statically is probably the time you helped me the most. ;) dhcpd dialing the root fileserver is probably a good idea. more automatic *and* less confusing. no idea about the other two methods, i can't visualize them so easily, but if they have the same result, that's fine with me. > in any case, i think we could avoid alot of confusion by improving > the way of this bootstrap mechanism works. some confusion, certainly. something of the same sort of bootstrap problem is on the horizon of my forth. not with the network, but with defining things more than once because the regular definition isn't available until after a bootstrap definition is made. i'll figure it out. "an adequate bootstrap is a contradiction in terms." - linus torvalds. i'm not sure about 'adequate', but substitute 'clean' and the statement works quite well.