From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Date: Tue, 27 Jun 2000 12:30:59 +0000 From: Wladimir Mutel Message-ID: <8ja5gp$2126$1@pandora.alkar.net> References: Subject: Re: [9fans] cpu/file/terminal server of my dream Topicbox-Message-UUID: cc07f2b8-eac8-11e9-9e20-41e7f4b1d025 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 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