On Sun, Jun 03, 2001 at 07:56:41PM -0500, ctest_at_neural.dlsemc.com wrote:
> I use the .deb files.  here is a list of things that i have fixed on
> my system.  I'm posting them for future deb-ers to see, and to give
> ideas to the next person creating the packages.  

Thanks.

> #1.  /etc/init.d/{auth*,codasrv*} make reference to /var/lock/subsys.
> Debian has a /var/lock directory, but no /var/lock/subsys directory.
> Either mkdir /var/lock/subsys or edit the scripts to refer to
> /var/lock.  (note: i don't belive there is a /var/lock/subsys in the
> filesystem standard.  if there is, we should report it as a debian
> bug)

Nope, that's a redhat thingy. I only really made the coda-client .deb's
and never corrected the init scripts that go into the other packages.

> #2.  /etc/init.d/coda-update uses a variable $vicedir, but vicedir
> never gets initialized to any value :)  So solve this initialize it
> yourself, as vicedir=/vice.

It could also source /etc/coda/server.conf or something to allow
the user to override the defaults.

> #3.  vice-setup initializes rvm_log and rvm_data without pathnames.
> add them manually as "/vice/db/rvm_log" and "/vice/db/rvm_data" as
> mentioned in someones eirlier mail.
> 
> #4 the "packages" list is missing.  create this by downloading
> everything into a directory, then use the dpkg-scanpackages command.
> "dpkg-scanpackages . /dev/null > Packages"

Ahh, that's how the Packages list is created, I'll try to add that
dpkg-scanpackages script to our ftp-server (a redhat machine) so I can
create that file. I've created something that works with the following
line in /etc/apt/sources.list,
    deb http://www.coda.cs.cmu.edu/pub/coda/linux debian/binary-i386/

> Other notes: I hosed my access controll list... I think i did it by
> setting permissions for non-existant users, (like "cfs setacl AnyUser"
> instead of "cfs setacl System:AnyUser"). I'm not really shure how i
> did it, but recovering from it, seems to be dificult.  My solution was
> to re-install the OS and start again.

A system administrator should be able to set an ACL as long as he has
access to /coda. Once the ACL on /coda is hosed, it is still possible to
recover by creating a temporary volume, force a client to mount that
volume as root, mount the real-coda-root and set an ACL to allow
System:Administrators 'rl' permissions on the root volume.

    on the SCM server...
    # createvol_rep tmp:root E0000100

    on a client...
    # venus -init -rootvolume tmp:root &
    # cfs mkm /coda/root coda:root
    # cfs sa /coda/root System:Administrators rl
    # killall -9 venus ; umount /coda
    # venus -init &

Jan