9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Rudolf Sykora" <rudolf.sykora@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net>
Subject: Re: [9fans] mount followed by srvfs needs a sleep?
Date: Mon, 20 Oct 2008 16:43:32 +0200	[thread overview]
Message-ID: <a560a5d00810200743p6260fbf3i7fc33b05e543a71f@mail.gmail.com> (raw)
In-Reply-To: <e3b43f14f81f508ffa2b2ae41ebab5d5@quanstro.net>

[-- Attachment #1: Type: text/plain, Size: 3077 bytes --]

2008/10/20 erik quanstrom <quanstro@quanstro.net>

> >         #to solve the authentication --- see the text bellow
> >         mount /srv/penelopa $home/shared/penelopa
> >         unmount $home/shared/penelopa
>
> i don't see an explination for this below.  what does this
> accomplish?  if you are trying to load more keys into your
> factotum, this can be more cleanly be done by putting them
> in secstore(1).  secstored(8) will serve them.


Well. I mentioned this reason in the PS note. I do this only to be able to
enter my login and password somehow. If I leave out the mount/unmount
commands then the 'local mount' will ask for these instead, but then you
can't just enter those --- the input/output goes to somewhere (?
/dev/kprint) and you get to a situation that some of what you type goes
somewhere, some goes elsewhere... Is it better now? I have no other reason
than this one.
Further, I just didn't want to really serve those like you propose. I do not
have a real reason for this (though I could easily think of some). I am now
simply interested in the kind of authentication through giving a login and a
password, if it can be made secure (I also asked about this) like eg. an
ordinary ssh connection.


> >         local mount /srv/penelopa $home/shared/penelopa
> >         #sleep 1  # --- see the text bellow; this pertains to my main
>
> the plumber doesn't require that the command it runs finish
> before returning.  (think of plumbing a file.  you don't want
> to hang until the editor exits.)
>

Ok, understand. Thus I only either have to find a way to be sure the first
command has ended, or just rely it does during that 1s and live with that.


> > question
> >         local srvfs CALC $home/shared/penelopa/home/ruda/CPA-CALC  #****
> >         local mount /srv/CALC $home/shared/CALC
>
> why are you doing this?
>

Ok. By doing all the complicated dance _without_ these two commands, I
achieve I have _globally_ accesible files served by the penelopa machine.
These files can be accessed under $home/shared/penelopa. But usually I need
files from this filesystem that are rather deep down this filesystem, eg.
/usr/ruda/shared/penelopa/home/ruda/CPA-CALC/doing/leads/co/up. You just
can't work fine with such long paths (in acme you then don't see anything
else). So the first idea is to do some bind. And you want to do this bind
again in the namespace of the plumber through the 'local' trick (you want
this bind to be global too). Further, I want this "bind" to be bound into
the '$home/shared' directory, which, however, is taken care of by mntgen
(for basically any possible remote connection). I am unable to do bind there
(you cannot make a directory when mntgen is running). Thus I decided to
again serve a portion of the filesystem (all under /home/ruda/CPA-CALC) and
then mount it to $home/shared/CALC, which works. Uff.
[It's just so difficult to break the locality of the namespace to make
something nicely globally accessible... :))]

Hopefully I explained...

Ruda

[-- Attachment #2: Type: text/html, Size: 4104 bytes --]

  reply	other threads:[~2008-10-20 14:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-20 12:48 Rudolf Sykora
2008-10-20 13:05 ` erik quanstrom
2008-10-20 14:43   ` Rudolf Sykora [this message]
2008-10-20 15:24     ` erik quanstrom
2008-10-20 16:06       ` Rudolf Sykora
2008-10-20 23:10 ` Micah Stetson
2008-10-21  8:26   ` Rudolf Sykora

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a560a5d00810200743p6260fbf3i7fc33b05e543a71f@mail.gmail.com \
    --to=rudolf.sykora@gmail.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).