On Mon, May 13, 2002 at 09:43:44PM -0700, Jim Carter wrote:
> > It's the userspace side of devfs support that was being worked on, venus
> > now automatically tries several possible paths to check for the kernel
> > module /dev/cfs0, /dev/coda/0, etc.
> 
> Perusing log files more carefully, I spotted the module version number:
> 5.3.15. Venus doesn't manage to trigger loading of the module. For the
> moment my startup script just does "modprobe coda" before starting Venus,
> but eventually I need to add to /etc/modules.conf:
>     alias /dev/coda coda
> (in addition to alias char-major-67 coda) which a standardly configured
> devfsd will throw at modprobe at the appropriate moment.

Cool, that is exactly the line I was looking for. Someone sent me
'alias /dev/coda* coda' but that didn't seem to work right.

> > Ehh, if script kiddies actually manage to get the Windows 95 client
> > working reliably without getting a BSOD all the time, I'd like to know
> > how they do that. Granted, the Windows NT/2000 client is probably a lot
> > more stable by now.
> 
> At UCLA-Mathnet our incoming (world writeable) FTP area got used as a warez
> distribution center, so I'm sensitive to the issue.  We stomped them, you
> can be sure, while preserving the writeability of the directory.

Same happened about 3 years ago with our Coda ftp, it lasted about 3
hours before facilities noticed the surge in network activity (amazing
how an illegal copy of Office is more popular than a completely legal
copy of Coda, or maybe it's just that much bigger :)

> I have another question: I'm trying to create the nonreplicated repair
> volumes mentioned in Admin Manual sect. 10.6 "Readonly Replication of a
> Volume". This is to make the root readonly. But the script createvol was
> removed in version 5.0.0. What should I do: use createvol_rep (replicated
> repair volumes), or omit the repair volumes, or leave the root read-write?

Readonly replicated volumes were inherited from AFS, however they do not
have version vectors and thus a client cannot revalidate the volume
after disconnection. The simple solution is that a client basically
always throwns away any unreferenced non-replicated object.

Disadvantage is that a client loses access to replicated volumes when
the root is a readonly replica. As many people have been bitten by this
(and as you can see, the manual even recommends it) I've removed the
createvol script.

What are the repair volumes you mention? It almost seems like you are
reading a different admin manual than I am. Chapter 10 is completely
about backups, 10.6 seems to be Backup Scripts.

In any case, our root volume is a simple triply-replicated read-write
volume that has write access for System:Administrators, and only
read/lookup permissions for System:AnyUser.

Jan