Forum OpenACS Q&A: Re: Notes on reinstall of developmental computer

Collapse
16: Re: Notes on reinstall of developmental computer (response to 15)
Posted by Jeff Davis on 02/14/03 12:39 AM
the CVSROOT variable is ignored if you already have a
checkout.  In that case it looks in CVS/Root to find
the repository, so you should check that it is right there.
Collapse
17: CVS reinstall troubles (response to 16)
Posted by Jade Rubick on 02/14/03 01:00 AM
Thanks, Jeff. I think you may be on to something, although it's not completely fixed yet. Under /web/myservicename/CVS/Root on the production computer, the value is :ext:dev:/cvsweb, just like CVSROOT. However...

The cvs repository is on my dev computer. If I login as joeuser on the production computer and do: 

cvs co servicename
All my code is checked out of the repository on the dev computer.

Back on production: 

cd servicename
rm readme.txt
cvs update readme.txt
joeuser@devcomputer's password:
U readme.txt
However, it hangs at U readme.txt

I hate to bug you all with this, but I really do appreciate the help. I'm doing my best to find resources on the net as well.

Collapse
18: Re: CVS reinstall troubles (response to 17)
Posted by Jade Rubick on 02/14/03 01:35 AM
According to this page: http://mail.gnu.org/archive/html/info-cvs/2002-12/msg00015.html, there is a bug or incompatibility in the cvs 1.11.2 server (which ships by default on Redhat 8) that causes this problem. It is related to compression. Apparently, if I disable compression, it should work. So, again on the production computer. 
cd
rm -rf myservicename
cvs co myservicename
cd myservicename
rm readme.txt
cvs -z0 update readme.txt
However, I get the same problem as before. It freezes after showing U readme.txt
Collapse
19: Re: CVS reinstall troubles (response to 17)
Posted by Jade Rubick on 02/14/03 11:47 PM
I figured out the source of the problem. If you look at this page, it suggests that using older versions of ssh with a newer server can cause this problem. That seems to be the case.

Strangely, however, the workaround seems to be use use the trace option (-t). For example: 

cvs -t update readme.txt
works.

I'm going to ignore this problem for now, since I have a workaround. On to more interesting things:

Getting ACS 3.4.10 up again

  • su - joeuser
  • download the openacs4.tcl.txt configuration file. I'm not sure if this will work with ACS 3.4, but I'd like to try it. I edit it.
  • Hmm, looks like I didn't install the nsd-oracle and nsd-postgres scripts.
  • cd /tmp
  • wget https://openacs.org/openacs-4/files/nsd-oracle.txt
  • wget https://openacs.org/openacs-4/files/nsd-postgres.txt
  • su -
  • cd /usr/local/aolserver/bin
  • cp /tmp/nsd-oracle.txt ./nsd-oracle
  • cp /tmp/nsd-postgres.txt ./nsd-postgres
  • chmod 750 nsd-oracle
  • chmod 755 nsd-postgres Now, why does Postgres need different permissions? Hmm, it looks like nsd-oracle doesn't run from joeuser unless the permissions are 755. So I set them that way. Any security problems with that?
  • exit
  • /usr/local/aolserver/bin/nsd-oracle -t ~/web/myservicename/myservicename.tcl I get an error saying that no log directory exists. Yes, that's true, I better add it in. mkdir web/myservicename/log
  • I get these errors:

    Warning: modload: failed to load '/usr/local/aolserver/bin/ora8.so': 'libclntsh.so.8.0: cannot open shared object file: No such file or directory'
    Error: dbdrv: failed to load driver 'ora8'
    Error: dbinit: no such default pool 'pool1'
    Debug: dbinit: no configured pools

    That doesn't look good. Permissions are root.root on the aolserver bin and lib directories..

  • su -
  • cd /usr/local/aolserver
  • chgrp web bin lib
  • exit
  • killall nsd
  • /usr/local/aolserver/bin/nsd-oracle -t ~/web/myservicename/myservicename.tcl
  • That didn't seem to work. Same problem as before. So I change the groups back. Trying the same command as root doesn't work either:
  • /usr/local/aolserver/bin/nsd-oracle -t ~/web/myservicename/myservicename.tcl -u joeuser -g web
  • I see at this website that this is a sign that LD_LIBRARY_PATH is incorrect. And what do you know? Looking at nsd-oracle, it sure it. So I edit in and change 8.1.7 to 8.1.6
  • It seems like it might be working... Nope. In the log it says it failed to have permission to listen on 0.0.0.0, which I set it for. So I set the port back to 8000 instead of 80, and now...
  • Error: /tcl/user-group-defs.tcl: function ug_serve_group_pages: first element in url_list is not [ad_parameter GroupsDirectory ug]
  • I had to add two lines under ns/parameters in myservicename.tcl: 
    ns_param user joeuser
ns_param auxconfigdir ${serverroot}/parameters
    This is ACS 3.4, so that file is necessary. Now it seems to be working fine.
  • I set up daemontools. It was even easier than I thought it would be to set up.
  • For some reason, I wasn't able to get the run script to work unless I changed the user from nobody to joeuser. I'm certain that's not as good an option security-wise...
  • ACS is now functioning fine. I'll install OpenACS later, maybe next week or so.