Spurred by the recent discussion of NIS, NIS+, LDAP et al, I'm curious what
the landscape was like for distributing administrative information in early
Unix networks.
Specifically I'm thinking about things like the Newcastle Connection, etc.
I imagine that PDP-11's connected to the ARPAnet running Unix would (e.g.,
RFC 681 style) would have adapted the HOSTS.TXT format somehow. What about
CHAOS? Newcastle? Datakit?
What was the introduction of DNS into the mix like? I can imagine that that
changed all sorts of assumptions about failure modes and the like.
NIS and playing around with Hesiod are probably the earliest such things I
ever saw, but I know there must have been prior art.
Supposedly field 5 from /etc/passwd is the GECOS username for remote job
entry (or printing)? How did that work?
- Dan C.
> I have a vague intuition right now that the hyphenation decisions
> ...
> should be accessible without having to invoke the output driver.
Would't that require some way to detect a hyphenation event?
Offhand, I can't think of a way to do that.
But if you know in advance what word's hyphenation is in
question, you could switch environments, use the .ll 1u
trick in a diversion, and base your decision on the result.
Doug
UNIX was half a billion (500000000) seconds old on Tue Nov 5 00:53:20
1985 GMT (measuring since the time(2) epoch).
-- Andy Tannenbaum
Hmmm... According to my rough calculations, it hit a billion (US) seconds
around 2000.
-- Dave
Does anyone have any experience with YP / NIS / NIS+ / LDAP as a central
directory on Unix?
I'm contemplating playing with them for historical reasons.
As such, I'm wondering what the current evolution is for a pure Unix
environment. Read: No Active Directory. Is there a current central
directory service for Unix (or Linux)? If so, what is it?
I'm guessing it's LDAP combined with Kerberos, but I'm not sure.
--
Grant. . . .
unix || die
Interesting. /crp was a regular part of the Research world
in the mid-1980s when I joined up. It was nothing special,
just an extra file system for extra junk, which might or might
not be backed up depending on the system.
I had no idea its roots ran so far back in time.
I always thought it was an abbreviation for `crap,' though,
oddly, the conventional pronunciation seemed to be creep.
Norman Wilson
Toronto ON
A. P. Garcia:
I'd be interested in knowing where a pure unix environment
exists, beyond my imagination and dreams that is.
====
For starters, the computing facility used for teaching
in the Department of Computer Science at the University
of Toronto. Linux workstations throughout our labs; Linux
file servers and other back-ends, except OpenBSD for the
Kerberos KDCs and firewalls.
And yes, we use Kerberos, including Kerberized NFS for
(almost) all exports to lab workstations, which cannot
be made wholly secure against physical breakins by students.
(There's no practical way to prevent that entirely.)
Except we also use traditional UNIX /etc/shadow files
and non-Kerberized NFS for systems that are physically
secure, including the host to which people can ssh from
outside. If you don't type a password when you log in,
you cannot get a Kerberos TGT, so you wouldn't have access
to your home directory were it Kerberized there; and we
aren't willing to (and probably couldn't) forbid use of
.ssh/authorized_keys for users who know how to do that.
Because we need to maintain the password in two places,
and because we create logins automatically in bulk from
course-registration data, we've had to write some of our
own tools. PAM and the ssh GSSAPI support suffice for
logging in, but not for password changes or account
creation and removal.
Someday we will have time to look at LDAP. Meanwhile we
distribute /etc/passwd and /etc/shadow files (the latter
mostly blanked out to most systems) via our configuration-
management system, which we need to have to manage many
other files anyway.
Norman Wilson
Toronto ON
I was just reading this book review:
http://www.pathsensitive.com/2018/10/book-review-philosophy-of-software.html
and came across these paragraphs:
<book quote>
The mechanism for file IO provided by the Unix operating system
and its descendants, such as Linux, is a beautiful example of a
deep interface. There are only five basic system calls for I/O,
with simple signatures:
int open(const char* path, int flags, mode_t permissions);
ssize_t read(int fd, void* buffer, size_t count);
ssize_t write(int fd, const void* buffer, size_t count);
off_t lseek(int fd, off_t offset, int referencePosition);
int close(int fd);
</book quote>
The POSIX file API is a great example, but not of a deep
interface. Rather, it’s a great example of how code with a very
complicated interface may look deceptively simple when reduced to C-style
function signatures. It’s a stateful API with interesting orderings
and interactions between calls. The flags and permissions parameters
of open hide an enormous amount of complexity, with hidden requirements
like “exactly one of these five bits should be specified.” open may
return 20 different error codes, each with their own meaning, and many
with references to specific implementations.
The authors of SibylIFS tried to write down an exact description of the
open interface. Their annotated version[1] of the POSIX standard is over
3000 words. Not counting basic machinery, it took them over 200 lines[2]
to write down the properties of open in higher-order logic, and another
70 to give the interactions between open and close.
[1]: https://github.com/sibylfs/sibylfs_src/blob/8a7f53ba58654249b0ec0725ce38878…
[2]: https://github.com/sibylfs/sibylfs_src/blob/8a7f53ba58654249b0ec0725ce38878…
I just thought it was a thought-provoking comment on the apparent elegance
of the Unix file API that actually has some subtle complexity.
Cheers, Warren
> From: Lars Brinkhoff
> Let's hope it's OK!
Indeed! It will be fun to see that code.
> I suppose I'll have to add a simulation of the Unibus CH11 Chaosnet
> interface to SIMH.
Why? Once 10M Ethernet hardware was available, people switched pretty rapidly
to using that, instead of the CHAOS hardware. (It was available off the shelf,
and the analog hardware was better designed.) That's part of the reason ARP is
multi-protocol.
Some hard-to-run cables (e.g. under the street from Tech Sq to main campus)
stayed CHAOS hardware because it was easier to just keep using what was there,
but most new machines got Ethernet cards.
Noel
