HDTenEightyP/NetNews huggingface dataset:
From: fred@maccs.dcss.mcmaster.ca (Fred Whiteside)
Newsgroups: comp.protocols.nfs,comp.protocols.tcp-ip.ibmpc
Subject: Re: Can you chmod 111 in a DOS NFS redirector?
Date: 11 Nov 92 14:49:51 GMT
Reply-To: fred@bws.com (Fred Whiteside)
Organization: Beame & Whiteside Software Ltd.

In <1992Nov11.000531.576@alf.cooper.edu>, hak@alf.cooper.edu writes:
>I've tried this with MD-DOS/IP, an NFS client which used to
>be available from Univ. of Maryland, but it didn't work.
>I was wondering if what I want can be done on other NFS clients, such
>as PC-NFS, B&W or FTP...
>
>I want to have a DOS .EXE file residing on a UNIX host, with
>permissions set to 111, that is, execute-only.  In other
>words, the DOS client can execute the file over NFS, but
>can't copy it.  I seem to recall that Novell Netware can do
>this, but Netware does not use the redirector interface--
>it traps INT 21 directly.  DOS does not seem to distinguish
>between reads being done to execute and plain reads when
>calling the redirector (INt 2F).  Any thoughts, comments, experiences, etc?

	BW-NFS will do this provided that the DOS .EXE file does not
attempt to read itself.  Similarly, *true* windows apps will not run with
such permissions, as windows reads such .exe's right off the bat.

	not being 100% certain of the capabilities of the new versions
of the other vendors offerings, i'll let them speak for themselves rather
than mis-inform.

Fred Whiteside
-- 
Fred Whiteside   Beame & Whiteside Software Ltd., Caledonia, Ontario
fred@bws.com   fred@maccs.DCSS.McMaster.CA   ...!uunet!utai!utgpu!maccs!fred
From: geoff@tyger.Eng.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
Newsgroups: comp.protocols.nfs,comp.protocols.tcp-ip.ibmpc
Subject: Re: Can you chmod 111 in a DOS NFS redirector?
Date: 11 Nov 1992 14:01:05 GMT
Organization: SunSelect
NNTP-Posting-Host: tyger.east.sun.com

Marking an executable as 111 (execute only) to prevent copying
works on PC-NFS, as long as the app doesn't need to open its own
executable for any purpose. (Some apps read overlays, strings, etc.
from their own .EXE. The hypertext version of the Interrupt List
which ships with Undocumented DOS is a classic example.)

--
Geoff Arnold, PC-NFS architect, Sun Select. (geoff.arnold@East.Sun.COM)
-----------
News software that enforces a four-line .signature limit is responsible for
the fact that these postings just go on and on and on and seem to end in mid-
Newsgroups: comp.protocols.nfs,comp.unix.ultrix
From: luigi@pical2.uucp (Luigi Rizzo)
Subject: Use of reserved port (on Ultrix)
Organization: Dip. di Ingegneria dell'Informazione, Univ. di Pisa (ITALY)
Date: Mon, 9 Nov 1992 19:41:56 GMT


I have troubles with 386BSD in mounting a disk from a Decstation
(running Ultrix 4.1 for what it matters). The server keeps replying

Bad MNT RPC: RPC: Authentication error; why = Invalid client credential

despite the fact the stuff in /etc/exports and /etc/hosts seems ok (and
the server is set to avoid checking internet addresses anyway).  People
on the net suggested it's a problem with the use of reserved port for
incoming connections:  some machine expect connections to come from
reserved ports, and 386bsd normally uses non-reserved addresses. Now, I
recompiled the kernel and now connections come from ports in the range
1023..512, but the problem remains. Might it be that Ultrix restricts
even more the set of ports an NFS connection can come from ?

	Thanks
	Luigi
====================================================================
Luigi Rizzo                     Dip. di Ingegneria dell'Informazione
email: luigi@iet.unipi.it       Universita' di Pisa
tel: +39-50-568533              via Diotisalvi 2, 56124 PISA (Italy)
fax: +39-50-568522
====================================================================
Newsgroups: comp.protocols.nfs,comp.unix.ultrix
From: boyd@prl.dec.com (Boyd Roberts)
Subject: Re: Use of reserved port (on Ultrix)
Organization: Digital Equipment Corporation - Paris Research Laboratory
Date: Tue, 10 Nov 1992 09:19:48 GMT

In article <1992Nov9.194156.9935@di.unipi.it>, luigi@pical2.uucp (Luigi Rizzo) writes:
> 
> I have troubles with 386BSD in mounting a disk from a Decstation
> (running Ultrix 4.1 for what it matters). The server keeps replying
> 
> Bad MNT RPC: RPC: Authentication error; why = Invalid client credential
> 

Check out how many groups root is it.  If it's more than 8 then there's
your problem.


Boyd Roberts			boyd@prl.dec.com

``Not only is UNIX dead, it's starting to smell really bad.''  -- Rob Pike
Newsgroups: comp.protocols.nfs
From: erick@sunee.uwaterloo.ca (Erick Engelke)
Subject: Re: PC-NFS and Bootp
Organization: University of Waterloo
Date: Thu, 5 Nov 1992 21:29:56 GMT

geoff@tyger.Eng.Sun.COM writes:
>Quoth dan@willamette.edu (Dan Revel) (in <Bx7pzE.6DL@willamette.edu>):
>#I would like to be able to use BOOTP to provide boot info (ip address,
>#etc.) to our PC-NFS clients.  Right now they are RARPing, but I would
>#like to be able to set up clients on a subnet that does not have a RARP
>#server.  Is this possible?  Is it the 'right' approach?
>
>Our current thinking (*not* committed product plans, please note!) is
>that we'll skip BOOTP and adopt DHCP, which is a much more complete
>solution.

I would suggest adopting widely supported standards before
soon-to-be-ratified replacements for standards which may offer
more but are not widely available.  Sure, adopt DHCP, but please
think of BOOTP first.

Just remember (ooops, Sun guy, better not mention NeFS)...
all the various transports and alternative mail and file
exchange protocols which we have seen get RFCed and which
never caught on despite their obvious superiority.

I know I going to get a few flames from selfconcious OSIers
who think I'm talking about them. Don't bother, this is
honestly a post about IP based protocols.


>.... Bear in mind
>that DHCP is still not an RFC, though the client-server protocol seems
>essentially stable. 

Erick

-- 
----------------------------------------------------------------------------
Erick Engelke				 	            WATTCP Architect
erick@development.uwaterloo.ca     TCP/IP was easy but i still can't work VI
Newsgroups: comp.protocols.nfs
From: hh2@prism.gatech.EDU (Hap Haas)
Newsgroups: comp.protocols.nfs
Subject: Problems installing PCNFSLPD on PC for PC-NFS. Pointers?
Date: 13 Nov 92 19:40:49 GMT
Organization: Georgia Institute of Technology

I am having problems getting a Sun SPARCStation to print to my PC
which is running PC-NFS.  Everything seems to load, the Sun seems
to find my PC, but nothing prints.  Any help would be appreciated.

The printcap entry on the SPARC is:

------
lp1:\
	:lp=:rm=haas:rp=LPT1:sd=/var/spool/hphlj2:
------

I start PCNFSLPD.EXE on my PC with the following command:

------
pcnfslpd -P LPT1: lp1 -l
------

And typing "LPT a status" on the PC returns the following:

------
LPT1 ready and printing.

NFSP039: LPT1 - printing enabled, spool queue enabled, spooling enabled, 0 jobs in queue; no line-feed translation, no banner page printed,  logging.
NFSP037: Command complete.
------

If I do an "lpq -Plp1" on the Sun, the PC's PCNFSLPD.LOG file looks like:

------
Open system log for lpd.

>>Fri Nov 13 14:15:55 1992:: 128.61.14.xxx requests displayq short.
(with the real IP number.)
------

But when I try to print - nothing happens.  And there's nothing in the
log file.

Any pointers?

Thanks in advance.

hh
---
Harry Haas  GTRI/RIDL/SB    |    Georgia Tech Research Institute
Research Engineer II        |    225 North Ave.
harry.haas@gtri.gatech.edu  |    Atlanta Georgia, 30332
"I know engineers . . . . they *love* to change things"  - Bones
From: jpe@jhunix.hcf.jhu.edu (John Paul Elrod)
Newsgroups: comp.protocols.time.ntp
Subject: Porting xntp3 to Data General Aviion (DG/UX)
Date: 11 Nov 92 17:31:46 GMT
Article-I.D.: jhunix.1992Nov11.173146.24817
Reply-To: jpe@jhuspo.ca.jhu.edu (John Paul Elrod)
Organization: Johns Hopkins University, Research Administration Services

I'm trying to port xntp3 to a Data General Aviion 5240 running
DG/UX 5.41 (a SVR4 derivative).  There isn't a Config file for DG/UX in
the source I obtained, and my efforts to create one have not been very
successful.  Has anybody ever ported xntp3 to DG/UX?  Or does anyone
know of a Config.dgux file in any archive site?  In the alternative, is there
a more generic SVR4 Config file somewhere?  Thanks in advance.
-- 
John Paul Elrod                     -    jpe@jhuspo.ca.jhu.edu
Information Systems Manager         -    (410) 516-8732
Research Administration Services    -    300 Whitehead Hall
Johns Hopkins University            -    Baltimore, Maryland 21218
Newsgroups: comp.protocols.time.ntp
From: kardel@faui45d.informatik.uni-erlangen.de (Frank Kardel)
Subject: Re: xntp3, DOSYNCTODR_SUCKS
Organization: CSD., University of Erlangen
Date: Thu, 12 Nov 1992 11:13:59 GMT

stevo@elroy.Jpl.Nasa.Gov (Steve Groom) writes:

>...  In particular, when the machine comes back up
>after being powered off, the clock seemed to be set to a reasonable value,
>or at least I didn't notice that it was far enough off to be a problem.
>In xntp3, this DOSYNCTODR_SUCKS thing has a comment that seems
>to indicate that if I don't define this, the hardware clock doesn't get
>updated by xntpd.
True when you also use tickadj to disable SW clock setting from the HW clock.

>Is this something new in v3?
Yes.

>Also, there is a comment
>that says that I probably only need this if I'm not on a network.  It seems
>to me that if this is indeed a problem, the machine could wake up
>with the clock far enough out of whack that xntpd would give up, making
>this an issue for "networked" machines as well.

As long as you stay with the HW clock within 1000 seconds of the time everything
is fine. And each time xntp has to set the SW clock because it is of by 
more than 128ms the HW clock will also be set and thus stay "close" to what
it should be. When you are away for a long time from the net or you are synched
very nicely via xntp your HW clock may drift quite a bit. Therefore a periodic
settimeofday(gettimofday) is done when you define DOSYNCTODR_SUCKS. This is fine
for machines synchronized not better then 5ms.
DOSYNCTODR_SUCKS pertains mostly to Suns.

WARNING:
DOSYNCTODR_SUCKS introduces a glitch of ~ 800us ervery hour on Suns (SS2) and is
thus NOT USABLE for high precision hosts.

--
  Frank Kardel (time@informatik.uni-erlangen.de)
Newsgroups: comp.protocols.time.ntp
From: stevo@elroy.Jpl.Nasa.Gov (Steve Groom)
Subject: xntp3, DOSYNCTODR_SUCKS
Organization: Image Analysis Systems Group, JPL
Date: Mon, 9 Nov 1992 21:40:08 GMT

I installed xntp3 last week.  We've been running an older xntp (v2) for
a long time and it appeared quite stable, but I wanted to upgrade since
a lot of other machines around here were installing the newer version
and having trouble if they didn't put the "version 2" for our hosts in
their config files.  Easier to upgrade than fixing everyone else,
I thought.

I have a question about the DOSYNCTODR_SUCKS definition in the config file.
We are running a bunch of Suns, and we've been using tickadj to turn off
dosynctodr when the system boots.  Using that, everything has been
working just fine.  In particular, when the machine comes back up
after being powered off, the clock seemed to be set to a reasonable value,
or at least I didn't notice that it was far enough off to be a problem.
In xntp3, this DOSYNCTODR_SUCKS thing has a comment that seems
to indicate that if I don't define this, the hardware clock doesn't get
updated by xntpd.  Is this something new in v3?  Also, there is a comment
that says that I probably only need this if I'm not on a network.  It seems
to me that if this is indeed a problem, the machine could wake up
with the clock far enough out of whack that xntpd would give up, making
this an issue for "networked" machines as well.

I initially xntpd (v3) with this definition disabled.  When I booted the
machine after being powered off over the weekend, the clock was 14
seconds off.  This isn't great, but it sounds reasonable for a
battery-powered CPU clock.  It looks to me like the CPU's hardware
clock must have been OK when the system went down.  Since I got this
fairly reasonable behavior with DOSYNCTODR_SUCKS undefined, what is
the benefit of having it defined?

One other comment about xntpd v3 compared to v2:  boy, does that
thing like to make a lot of noise in the logfiles!  There's now all
this status information being sent to syslog at LOG_INFO, which in
steady-state used to only have the hourly drift messages.  I would still
like to see the drift info, but not all that other junk.  In order
to do this, I'll have to go hack the code or just forego the drift messages
by fixing syslog.conf.  Has anyone else noticed this verbosity?  Will
it fade away after everything settles down, or should I do something
now to avoid filling all my root partitions?

thanks
-- 
Steve Groom, stevo@elroy.jpl.nasa.gov
Jet Propulsion Laboratory, Pasadena, CA
From: eggert@twinsun.com (Paul Eggert)
Newsgroups: comp.protocols.time.ntp
Subject: Re: Daylight/Std Time & Time Zones
Date: 13 Nov 92 19:29:12 GMT
Organization: Twin Sun, Inc

greg@perry.berkeley.edu (Greg Anderson) writes:

	I am wondering if anyone out there knows of a source where one
	can get the *entire* definitive history of the rules for
	determining Daylight vs. Standard Time.

Please look at Arthur David Olson's time zone package, which you can
FTP from elsie.nci.nih.gov in pub/tz92b.tar.Z.  It's not a definitive
history, but I doubt whether you'll find anything better.
From: Mills@UDEL.EDU
Newsgroups: comp.protocols.time.ntp
Subject: churchy la morte
Date: 6 Nov 92 15:20:52 GMT
Distribution: inet
Organization: The Internet

Folks,

For those of you who itch to chime, note churchy.udel.edu has become
quiet, at least temporarily. The kind folk at Bancomm recalled the
beast, which is one of their NTP-in-a-box widgets, for demo elsewhere.
I am told it may return in a month or so. Meanwhile, rackety.udel.edu
continues faithful chime.

Dave
From: resnick@cogsci.uiuc.edu (Pete Resnick)
Newsgroups: comp.protocols.time.ntp
Subject: Re: Daylight/Std Time & Time Zones
Date: 13 Nov 92 00:32:06 GMT
Distribution: inet
Organization: University of Illinois at Urbana

greg@perry.berkeley.edu (Greg Anderson) writes:

>We would like to be able to convert dates and times (in UTC)
>to their equivalent dates and times in various time zones, including
>Pacific Daylight and Standard Time, and vice versa.  I am wondering 
>if anyone out there knows of a source where one can get the *entire*
>definitive history of the rules for determining Daylight vs. Standard
>Time.  

The news about this is pretty bad. I have searched endlessly for a
central source for this information. There is none. Here's the deal:

In the US, going on daylight savings is up to each local government; I
don't even think it's a state decision since some parts of Indiana do
and some don't. Currently, the rules in the US are daylight time
starts at 2am on the first Sunday of April and ends 2am on the last
Sunday of October. The US Department of Transportation keeps track of
the rules throughout the US.

Now, international is even worse. Checking with the UN, timezones and
daylight time rules are kept track of entirely by local regional
offices of the Commerce, Trade and Transport office (whose name
changes from region to region) and there is no central collection of
such information. The UN Library in NY has been asked about this
information several times and has considered collecting the
information, but the resources required to collect the information are
just not there.

So, keeping track of this stuff is other than fun.

pr
-- 
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: resnick@cogsci.uiuc.edu
Newsgroups: comp.protocols.time.ntp
From: femenia@power.ci.uv.es (Jose M. Femenia Herrero)
Subject: xntp3 on HP-7xx (HP-UX 8.0x)
Date: Thu, 12 Nov 1992 18:40:22 GMT
Organization: Universitat de Valencia, Spain
X-Newsreader: TIN [version 1.1 PL6]
Keywords: xntp3, HP

Hello!

We are installing xntp protocol on different machines. We are using xntp3 from
louie.udel.edu, and it work fine on IBM RS6000 AIX 3.2. Also it work on HP 385
with HPUX 8.00, but we are not sure it do so well. But the problem is when
we run xntpd on HP 720 with HP-UX 8.05. The soft compile fine, xntpd seem
comunicate correctly with peers and servers, but xntpd crash without notice
when it try to adjust time. We are running adjtime on this HP's, but on 385
the xntpd run also without it.
The problem is exactly the same on other HP 705 with HPUX 8.07.

Any sugesstion?

Many tanks in advance.

                       Jose Miguel


--
Jose Miguel Femenia Herrero        Internet: femenia@graf.ci.uv.es
Servei d'Informatica               EARN:     FEMENIA at EVALUN11
Universitat de Valencia            X400:   S=femenia;OU=vm;OU=ci;O=uv;P=iris;
46100 Burjassot (Valencia) SPAIN           A=mensatex;C=es
From: jcs@zoo.bt.co.uk (John C Sager)
Newsgroups: comp.protocols.time.ntp
Subject: Re: churchy la morte
Date: 13 Nov 92 09:36:43 GMT
Distribution: inet
Organization: British Telecommunications plc

It's a pity that churchy is off the Internet - I hope only temporarily -
as it is the only other GPS-referenced stratum 1 server on the Internet
that I know of. (Any others not in clock.txt yet?). It has been instructive
to look at the declared offsets that my server, bear.zoo.bt.co.uk,
quotes for churchy, knowing that the true offset is in the low microsecond
range. I almost always got offsets at least in the tens of millisecond
range & often above 100ms - and almost always negative. This is directly
attributable to asymmetric propagation delay on the Internet.
Plotting the raw samples over a period to get the 'arrowhead' diagram shown
in rfc1128 gave me a fairly well-defined offset at the arrow point of about 1ms,
which is probably the inherent asymmetric delay not caused by queueing in
routers. There were far more points on the negative side of the arrowhead
than on the positive side, which shows that there is an asymmetric bottleneck
somewhere on the route from me to the US.

Come back soon...

John C Sager					Mail:	B67 G18, BT Labs
Email:	jcs@zoo.bt.co.uk				Martlesham Heath
Tel:	+44 473 642623					IPSWICH  IP5 7RE
Fax:	+44 473 637614					England
Newsgroups: comp.protocols.time.ntp
From: bgriffin@x102a.harris-atd.com (griffin ben 79743)
Subject: Leap Second testing
Date: Tue, 10 Nov 1992 22:12:42 GMT
Reply-To: bgriffin@x102a.ess.harris.com (griffin ben 79743)    
Organization: Harris Corporation GSS, Melbourne, Florida

I am in the middle of designing a distributed system that will use
NTP for synchronization.  A key element of the system relies on a certain
machine being within 100ms of our reference server (Bancomm bc635LAN).
This threshold seems easy enough to maintain. 

My question is what happens when a leap second is introduced into the system.
The bc635LAN only uses the IRIG-B info, so no leap second warning is distributed
and this machine is using a version one implementation of NTP.
I need to find out how long it takes for the machine to be synchronized within
the threshold after the leap second.  I am willing to try to test this, but not exactly sure how.  There is a Time Code Generator connected to the bc635LAN, so
should I just try to set the generator ahead one second and watch what happens?

Comments would be appreciated.


Ben Griffin
Harris Corporation        BGriffin@Rhino.ess.harris.com     (407)984-6384

Newsgroups: comp.protocols.time.ntp
From: art@cs.UAlberta.CA (Art Mulder)
Subject: xntp3, Config, -DREFCLOCK (Novice Question)
Summary: Is -DREFCLOCK only needed if you have a radio clock?
Organization: University of Alberta, Edmonton, Canada
Date: Tue, 10 Nov 1992 15:42:02 GMT


Novice Question: regarding how to edit the Config file for Xntp3.

  The Config file says this about -DREFCLOCK

# The flag -DREFCLOCK causes the basic reference clock support to be
#       compiled into the daemon.  ...

  Am I correct then in assuming that this flag should only be set if you
  have an actual radio clock hooked up to your machine?   (I'm curious,
  because in the default config file, this flag *is* set, and I would think
  that most sites do *not* have a radio clock, so I'm puzzled as to why it
  would be set by default)

  Please email, I'll summarize to the net.
  Thanks!
--
 ...art mulder ( art@cs.ualberta.ca )    | "Do not be conformed to this world,
 Department of Computing Science         |  but be transformed by the renewal
 University of Alberta, Edmonton, Canada |  of your mind, ..."  Romans 12:2
Newsgroups: comp.protocols.time.ntp
From: elegore@blackslacks.nswc.navy.mil (Eric LeGore)
Subject:  Wanted:  NTPQ or XNTPDC information (new address)
Organization: NSWC
Date: Thu, 12 Nov 1992 20:08:19 GMT


Hello,

Please excuse this 2nd call for help, but due to an ill-timed network 
problem (resolved 7 days later) immediately following the first posting, I
did not receive any responses (then again maybe no one sent any).
Anyway, here is the original posting with an additional, and hopefully more
reliable address:

I have recently installed Xntpd (ntp version 2) on 5 workstations
(DecStation 5000s) in an isolated lab (no source of UTC).  One of
the workstations has been configured as a stratum 1 time server and
the remaining workstations as clients/peers.

I would like to know how closely the clocks are synchronized which
leads to the following two questions:


1.  I suspect "ntpq" and "xntpdc" may be used to validate 
    the synchronization but have no documentation on how
    these utilities obtain their data or how to
    interpret the information they provide.  
    
    Is there documentation out there for ntpq and/ or xntpdc ?



2.  Who out there is using Xntpd?  What kind of precision do you 
    see(i.e. delays between clocks) and how did you measure it?




    Thanks,
    Eric

	 elegore@unode1.nswc.navy.mil
	
	or

      elegore@blackslacks.nswc.navy.mil
	 
Newsgroups: comp.protocols.time.ntp
From: ham@hal.nta.no (Terje Hammer)
Subject: PPS support
Organization: Norwegian Telecom Research
Date: Wed, 11 Nov 92 15:11:29 GMT

We are currently considering setting up a SPARC (ECL) as a
stratum 1 NTP time server.

One of our problems is that we currently only have equipment
that distribute accurate PPS signals but no timecode information.

We are wondering if it is possible to setup a SPARC running xntp
with the PPS support as a stratum 1 NTP time server, without
using any timecode. The on-time epoch could be obtained
via the NTP protocol from other NTP time servers.

If any of you have any idea if this is possible, or have
a simular setup, please email me.

Terje Hammer

-------------------------------------------------------------------------------
Terje Hammer       Norwegian Telecom         Phone:  +47 6 80 91 62
ham@hal.nta.no     Research Dept.            Fax:    +47 6 81 00 76
                   Postbox 83
                   N-2007 Kjeller
~