9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
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


  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).