Another challenge! I'm running fossil from within a CGI of my own... I want to do things like `fossil new foo.fossil`
But fossil decides it is running as a CGI itself and doesn't do what I ask. Running it as `exec - /usr/local/bin/fossil new foo.fossil` kind of works, but some things are still strange. I reset GATEWAY_INTERFACE and PATH_INFO to '' but that didn't solve it. The actual fossil name I'm using looks like: A+foo_bar.com+oth_re.ex.fossil - would that be causing me strange problems? Also this CGI that's calling fossil is running setuid... does fossil use the system to determine permissions or does it use stat etc. to look at the files directly. I.e. do I need to call seteuid? I thought this was going to be easy to use it (in this very idiosyncratic way), but it's been a pile of hassles. The reason for this weirdness is that I need to create fossils on the fly and change permissions/passwords, etc. Thanks On 26 September 2017 at 12:01, David Mason <dma...@ryerson.ca> wrote: > This is proxy, not CGI, but the same appears to apply: > > fossil clone http://dmason%40ryerson.ca@localhost:8081/f2017/A-dmason_ > ryerson.ca x.fossil > > (talking directly to the server) also doesn't seem to want the .fossil > extension, whereas ssh: and file: do. > > This seems inconsistent to me, though obviously you won't be changing it!!! > > Thanks again (both for the immediate help, and for fossil itself)! > > ../Dave > > On 26 September 2017 at 10:05, Richard Hipp <d...@sqlite.org> wrote: > >> On 9/26/17, David Mason <dma...@ryerson.ca> wrote: >> > Indeed! Thanks... I already noted that in the web access, but the file >> does >> > end in .fossil and I've always used that before when cloning (using the >> > ssh: access method). Is there a difference in how fossil names are >> > recognized in ssh: vs http(s): ? >> >> When using http(s), you need to tell the web server the name of the >> CGI script, not the name of the repository. Apache doesn't know >> anything about Fossil and has no idea how to deal with it. But Apache >> does know how to run CGI. >> >> When using the ssh: access method, the client uses the "ssh" command >> to run "fossil server $repo" on the remote side, where $repo is the >> name of the repository as specified in the URL. In this case, the >> command being run is "fossil" and it does know how to deal directly >> with a repository. Hence, ssh: is a little different from https: in >> that ssh: wants the name of the repository whereas https: wants the >> name of the CGI script. >> >> Note that it is usually undesirable to download the repository file >> directly, as the repository contains additional information such as >> usernames and password hashes and log files that should normally be >> kept private. If you ever do need to share a Fossil repository with >> an untrusted third party, first make a copy of the repo, then run the >> "fossil scrub" command on the copy in order to remove all sensitive >> information. Share the copy, not the original. >> >> -- >> D. Richard Hipp >> d...@sqlite.org >> _______________________________________________ >> fossil-users mailing list >> fossil-users@lists.fossil-scm.org >> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >> > >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
