From: Wladimir Mutel <mwg@alkar.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] cpu/file/terminal server of my dream
Date: Tue, 27 Jun 2000 12:30:59 +0000 [thread overview]
Message-ID: <8ja5gp$2126$1@pandora.alkar.net> (raw)
In-Reply-To: <E136ryQ-0007x5-0Y@anchor-post-34.mail.demon.net>
miller@hamnavoe.demon.co.uk wrote:
> I think what your Unix colleagues want is not 9term but drawterm(8),
> "a program that users of non-Plan 9 systems can use to establish graphical
> cpu(1) connections with Plan 9 CPU servers".
Oh, thank you for correction. I checked mans on 9term and found
that it is only local. drawterm is the program I indeed wanted to
mean.
> access onto separate machines. A Plan 9 file server (presumably kept behind
> a locked door) exports only one service to the outside world, which is
> subject to authentication by a trusted machine. You can't log in to the
> file server remotely or exploit flaws in obscure network services to run
> malicious programs there -- in fact the file server can't run anything which
> is not built into its kernel. A cpu server is a shared system, but can
Please explain what could I loss if I set up central file server on
existing unix by u9fs ? I do not have spare machine to deploy
full-blown fs(8) there. But, suppose, I do not need its backup
facility and some other extended features. Can u9fs satisfy me then ?
(provided I am aware of my unix security)
> only be accessed via an external connection authenticated by a trusted
> machine, with no superuser or setuid to break through the separation
> between user resources, and no chance of bypassing file protections by
> accessing disk devices directly because they are attached to the file server.
To say, is there any cpu-server emulator for unixes ?
It might be a great thing for deploying or migration to Plan9.
> Finally, the only machine under physical control of the user is the Plan 9
> terminal, which is a intended as a single-user resource, not a server; its
> local disk, if any, is for swapping and cacheing of temporary copies of files.
Oh, but Bell Labs offer to download only that 'poor'
configuration assuming that local harddisk holds entire main
filesystem.
Being on their place, I should in addition offer the following
separate downloads:
1. the main file system image, the fs(8) kernel or u9fs
software, and initial deployment instructions for
both of them;
2. boot diskette image or instructions on network booting,
documents on supported hardware for
terminal servers, on proper usage of local hardisk,
etc.
3. cpu server emulator for unix or windows
(would be great, heh !)
However I think I could make two first things by myself,
using currently available distribution of
Plan9.
> Subsequent users "login" to a terminal by rebooting from the network, so
> they know they are talking to a fresh instance of Plan 9 and not to a
> login spoofing program which a previous user has left running to collect
> passwords...
So, does my above proposal lend a newcomer exactly on this
'proper' way ? To say, 'newcomers' often already have unixes or
even networks of them. Like we do.
> The real "basic Plan9 setup" -- i.e. the minimal configuration intended to
> export and use services on a network -- uses at least three machines.
> whatever the operating system. Most Unix PC's can be booted in single
> user mode, or booted from a floppy with a specially doctored kernel.
Yes, you are about real physical security. I know well that
somebody can boot from diskette and mount my unix fs anyway, but I
simply do not consider this case now. Really, local kfs filesystem
is good only for transient data, but we usually have quite large
harddisk on every modern PC workstation - can we ever generate
such amount of transient files or swap per single terminal server
session ? That is a main question for me.
> to run out of resources. So I've implemented a kfscmd which tells kfs
> to export a fully authenticated file service to the network. Russ Cox is
> currently trying this out, so my changes may find their way into the
> standard system; if not, I can post them to 9fans.
Yes, this could be a step increasing 'household' usability of
Plan9.
> Some years ago, Vadim Antonov <avg@postman.ncube.com> posted changes to
> make a cpu server act as a terminal for successive users -- init(8) reads
> and authenticates a user name, and control of resources is split between
> #c/termowner (screen, keyboard, mouse and floppy) and #c/hostowner
> (everything else). So this is feasible too. But I think it's worthwhile
> to spend some time getting to know Plan 9 as it is before rushing to make
> it more like Unix.
Ok, thanks. The root of all my grief is that I just do not have
enough spare computers to deploy 'real' Plan9 on them :>
--
mwg@alkar.net
next prev parent reply other threads:[~2000-06-27 12:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-06-27 9:39 miller
2000-06-27 12:30 ` Wladimir Mutel [this message]
-- strict thread matches above, loose matches on Subject: below --
2000-06-29 17:50 presotto
2000-06-28 18:40 rsc
2000-06-28 17:34 miller
2000-06-29 16:49 ` Wladimir Mutel
2000-06-28 15:56 miller
2000-06-28 16:13 ` Steve Kotsopoulos
2000-06-26 9:01 Wladimir Mutel
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='8ja5gp$2126$1@pandora.alkar.net' \
--to=mwg@alkar.net \
--cc=9fans@cse.psu.edu \
/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).