Re: [fossil-users] Unintuitive CGI error message with missing /tmp directory in chroot.
Hi Stephan, On Wed, Jul 29, 2015 at 5:28 PM, Paul Pereira pjspere...@gmail.com wrote: It's not common practice (for me, at least) to put the repo file in a path reachable by www clients. On my hoster all of my CGI-hosted repos live in some dir under my home dir, writable by my account, the CGI scripts all point to those, and sqlite writes its temp files there (unless i'm sorely mistaken and it's using /tmp). It sounds to me like the message is just a bit vague/generic. The path /var/www is the chroot folder. It is not publicly visible by www clients. The default document root is /var/www/htdocs. The fossil is in /var/www/fossil/... because it must be accessible by the CGI script in /var/www/cgi-bin. As far as the script is concerned, the path to the fossil is at /fossil/... The CGI script cannot see my home directory or anything outside of /var/www due to the chroot (change root). The Fossil program is located at /var/www/usr/local/bin/fossil, and the required libraries are also under /var/www . Based on the current documentation, I thought that Fossil would create its temporary files in the directory of the repository, but that was not the case. It attempted to create its temporary files in the directory of the script, /var/www/cgi-bin, since I had not provided a /tmp folder. I believe this is due to sqlite3's default behaviour, which would normally make sense were it not for the fact that the database is being accessed indirectly through the CGI script in the cgi-bin directory. I am only pointing this out because the error message suggested that Fossil requires permissions that would make its use insecure. It stated it could not create files in the CGI script's own directory, which is cgi-bin. The current permissions requirements state: ... Can you suggest specific improvements to that (IIRC those instructions were written over 5 years ago)? I would add - Fossil must be able to create temporary files, the default directory for which depends on the OS. When the CGI process is operating within a chroot, ensure that this directory exists and is readable/writeable by the user who executes the Fossil binary. Regards, Paul Pereira ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Unintuitive CGI error message with missing /tmp directory in chroot.
It may be worth mentioning in the CGI setup instructions that Fossil/sqlite needs to be able to create temporary files for rollback logs in some manner particular to the OS, such as by writing to /tmp. In my case, I installed Fossil according to the standard chroot procedure in OpenBSD for CGI applications, by placing the CGI script in /var/www/cgi-bin. Sqlite failed to create a temporary file and attempted to create one in the script's current working directory, (/var/www)/cgi-bin before failing. The error message suggested that Fossil needed write access to the /cgi-bin directory. This is a bad idea. I was able to get Fossil to work correctly by providing (/var/www)/tmp. The current permissions requirements state: - The Fossil binary must be readable/executable, and ALL directories leading up to it must be readable by the process which executes the CGI. - ALL directories leading to the CGI script must also be readable and the CGI script itself must be executable for the user under which it will run (which often differs from the one running the web server - consult your site's documentation or administrator). - The repository file AND the directory containing it must be writable by the same account which executes the Fossil binary (again, this might differ from the WWW user). The directory needs to be writable so that sqlite can write its journal files. Regards, Paul Pereira ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Unintuitive CGI error message with missing /tmp directory in chroot.
On Wed, Jul 29, 2015 at 5:28 PM, Paul Pereira pjspere...@gmail.com wrote: It may be worth mentioning in the CGI setup instructions that Fossil/sqlite needs to be able to create temporary files for rollback logs in some manner particular to the OS, such as by writing to /tmp. In my case, I installed Fossil according to the standard chroot procedure in OpenBSD for CGI applications, by placing the CGI script in /var/www/cgi-bin. Sqlite failed to create a temporary file and attempted to create one in the script's current working directory, (/var/www)/cgi-bin before failing. The error message suggested that Fossil needed write access to the /cgi-bin directory. This is a bad idea. I was able to get Fossil to work correctly by providing (/var/www)/tmp. It's not common practice (for me, at least) to put the repo file in a path reachable by www clients. On my hoster all of my CGI-hosted repos live in some dir under my home dir, writable by my account, the CGI scripts all point to those, and sqlite writes its temp files there (unless i'm sorely mistaken and it's using /tmp). It sounds to me like the message is just a bit vague/generic. The current permissions requirements state: - The Fossil binary must be readable/executable, and ALL directories leading up to it must be readable by the process which executes the CGI. - ALL directories leading to the CGI script must also be readable and the CGI script itself must be executable for the user under which it will run (which often differs from the one running the web server - consult your site's documentation or administrator). - The repository file AND the directory containing it must be writable by the same account which executes the Fossil binary (again, this might differ from the WWW user). The directory needs to be writable so that sqlite can write its journal files. Can you suggest specific improvements to that (IIRC those instructions were written over 5 years ago)? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] check-in-edit branch ready?
Thus said Joe Mistachkin on Tue, 28 Jul 2015 21:02:49 -0700: It might be nice to have test coverage for the new command. Yes, very good point. I'll add some later today (time permitting). Thanks, Andy -- TAI64 timestamp: 400055b90a22 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 'mv' semantics
On 29 July 2015 at 16:50, Michai Ramakers m.ramak...@gmail.com wrote: Hello, using 'fossil mv' for the first time, and for some reason I don't understand what happens here (see pasted output) - instead of renaming a dir, it creates a zero-byte file (and leaves the original dir as-is). I have the feeling I'm doing something really simple really wrong. Ideas..? Right... creating the target-dir 'd2' beforehand worked in my case; any subdir existing under 'd' seems to be moved under 'd2' afterwards. Is it true what I wanted to do (rename a dir) needs to be a 2-step process, always? I thought that's exactly what '--hard' was meant to simplify. (I could rename the dir in the filesystem manually, and then use 'fossil mv' (without '--hard') to do the same thing, I think.) Then again, I didn't really follow the discussion about 'mv' semantics w.r.t. --hard and --soft and legacy behaviour a while ago. Michai ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Unintuitive CGI error message with missing /tmp directory in chroot.
On Wed, Jul 29, 2015 at 7:22 PM, Paul Pereira pjspere...@gmail.com wrote: The path /var/www is the chroot folder. It is not publicly visible by Ah, right - chroot. i run on a cheap shared hoster where chroot isn't an option, so i've never used that feature :/. I would add - Fossil must be able to create temporary files, the default directory for which depends on the OS. When the CGI process is operating within a chroot, ensure that this directory exists and is readable/writeable by the user who executes the Fossil binary. Here you go: https://www.fossil-scm.org/index.html/info/1d3a80474b903539 Thanks for the feedback! BTW: i just checked - it wasn't 5 years ago, only (almost) 2 years. It just seems like 5 years. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 'mv' semantics
Michai Ramakers wrote: I was unclear; this is the corresponding timeline: === 2015-07-29 === 19:58:39 [70b61c707b] *CURRENT* x (user: michai tags: trunk) DELETED d/dd/f DELETED d/f ADDED e/dd/f ADDED e/f 19:57:26 [998d26af68] a (user: michai tags: trunk) ADDED d/dd/f ADDED d/f 19:56:53 [07d0f795af] initial empty check-in (user: michai tags: trunk) Yeah, I've seen that happen to; however, in this case I believe it's a red herring. The --hard option makes no different in how the timeline is presented. I'm not saying there isn't an issue with the timeline; I'm saying it's unrelated to the --hard option. -- Joe Mistachkin ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 'mv' semantics
On 29 July 2015 at 22:02, Michai Ramakers m.ramak...@gmail.com wrote: On 29 July 2015 at 21:29, Joe Mistachkin sql...@mistachkin.com wrote: Michai Ramakers wrote: Right... creating the target-dir 'd2' beforehand worked in my case; any subdir existing under 'd' seems to be moved under 'd2' afterwards. I think the following change will fix the issue: https://www.fossil-scm.org/fossil/info/b86127e187a00bfc thanks for the quick action. However, I think this is not exactly it: ... I was unclear; this is the corresponding timeline: === 2015-07-29 === 19:58:39 [70b61c707b] *CURRENT* x (user: michai tags: trunk) DELETED d/dd/f DELETED d/f ADDED e/dd/f ADDED e/f 19:57:26 [998d26af68] a (user: michai tags: trunk) ADDED d/dd/f ADDED d/f 19:56:53 [07d0f795af] initial empty check-in (user: michai tags: trunk) Michai ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 'mv' semantics
On 29 July 2015 at 21:29, Joe Mistachkin sql...@mistachkin.com wrote: Michai Ramakers wrote: Right... creating the target-dir 'd2' beforehand worked in my case; any subdir existing under 'd' seems to be moved under 'd2' afterwards. I think the following change will fix the issue: https://www.fossil-scm.org/fossil/info/b86127e187a00bfc thanks for the quick action. However, I think this is not exactly it: michai@work-lap:/tmp/g/f$ $F ver This is fossil version 1.33 [b86127e187] 2015-07-29 18:44:10 UTC michai@work-lap:/tmp/g/f$ ll total 0 drwxr-xr-x 3 michai michai 80 Jul 29 21:57 d michai@work-lap:/tmp/g/f$ $F mv --hard d e RENAME d e MOVED_FILE /tmp/g/f/d michai@work-lap:/tmp/g/f$ $F cha MISSINGd/dd/f MISSINGd/f michai@work-lap:/tmp/g/f$ $F addr ADDED e/dd/f ADDED e/f DELETED d/dd/f DELETED d/f added 2 files, deleted 2 files (the corresponding timeline shows 2 added and 2 deleted files, and history is lost) My testdir is './d/dd/' with a file 'f' in each of the directories 'd' and 'dd'. Michai ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 'mv' semantics
On 29 July 2015 at 22:02, Michai Ramakers m.ramak...@gmail.com wrote: (the corresponding timeline shows 2 added and 2 deleted files, and history is lost) I mean of course: there is no relation between the added and deleted files, history-wise. Michai ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 'mv' semantics
Michai Ramakers wrote: Right... creating the target-dir 'd2' beforehand worked in my case; any subdir existing under 'd' seems to be moved under 'd2' afterwards. I think the following change will fix the issue: https://www.fossil-scm.org/fossil/info/b86127e187a00bfc -- Joe Mistachkin ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] no unmerged forks / no common ancestor messages - bug?
I would appreciate if anyone on the list can clarify if the following is a bug or expected behaviour. I hope the diagrams will come out OK when this is posted. I'm developing some features in 'x' branch, with a plan to merge periodically in another branch 'y', when stable. So I have added some files in 'x' to checkpoint (0), merged to 'y'. X Y | | (0) M(0) Next, I've added several more files in a check-in (1) to a branch 'y', but realised they had issues. I've edited that check-in (1) to be a start on new 'mistake' branch, and modified the files in subsequent check-in (2) there. I merged 'mistake' back to my 'y', all good - commit to (3) on 'y'. X Y | | (0) M(0)mistake | (1) | | (3)M(2) Then I realised changes in (3) shouldn't be in 'y', but in 'x'. No probs - I'll just do a baseline merge and put them there, I thought. 1. This is the first surprise. When doing 'f merge --baseline (1)' in branch 'x' checkout, I get the message 'no unmerged forks of branch x'. What does this mean? I thought it would have pulled (1), (2)/(3) into branch 'x'. So instead, I did two cherry-pick merges, one on top of the other: from (1), then (2) to 'x' - (3) was a no-op - committed, all good. Or so I thought. X Y | | (0) M(0)mistake | | (1)-| | | | | | (3)M(2) | | | | (12)CM--|---| 2. Later, I had some more changes committed in 'x' (4) and tried to merge them to 'y'. Another surprise: when doing 'f merge x' in branch 'y' checkout, I get 'no common ancestor' warnings on *all* files that I have added previously in both (0) *and* (1). Why is this? X Y | | (0) M(0)mistake | | (1)-| | | | | | (3)M(2) | | | | (1,2)CM-|---| | | (4)---M(warnings) So I lost modifications on some of those files that were committed in (4). However, the *new* file I committed in (4) was successfully 'added_by_merge'. This does not make sense to me. I thought that files that have been merged into 'y'(3), and then later cherry-pick merged to 'x'(1,2), would have had the common ancestors in (1) and (2). I also don't understand why am I receiving such warnings for files that have been committed in 'X' in (0) and successfully merged to 'Y' at the beginning. Is this a bug? Fossil 1.32 [6c40678e91] downloaded from Fossil site, Windows. Cheers, Steve ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] 'mv' semantics
Hello, using 'fossil mv' for the first time, and for some reason I don't understand what happens here (see pasted output) - instead of renaming a dir, it creates a zero-byte file (and leaves the original dir as-is). I have the feeling I'm doing something really simple really wrong. Ideas..? Michai michai@work-lap:/tmp/f$ f ver This is fossil version 1.33 [7d2ee2c7bb] 2015-07-21 06:17:42 UTC michai@work-lap:/tmp/f$ f new f.f project-id: fc58f1483a9426d77f86e7ea17e8ea0d3e12963e server-id: 00acdf8d6d35d62142492dcfa1f491784ae4d29d admin-user: michai (initial password is 3c0cce) michai@work-lap:/tmp/f$ mkdir f michai@work-lap:/tmp/f$ cd f michai@work-lap:/tmp/f/f$ f open ../f.f project-name: unnamed repository: /tmp/f/f/../f.f local-root: /tmp/f/f/ config-db:/home/michai/.fossil project-code: fc58f1483a9426d77f86e7ea17e8ea0d3e12963e checkout: 78b5210be0555156ff81814f599afc642d9f397d 2015-07-29 14:46:33 UTC tags: trunk comment: initial empty check-in (user: michai) check-ins:1 michai@work-lap:/tmp/f/f$ mkdir d michai@work-lap:/tmp/f/f$ date d/f michai@work-lap:/tmp/f/f$ f add d/f ADDED d/f michai@work-lap:/tmp/f/f$ f ci -m 'added f' New_Version: 0110b020b66073d6ca35d9eb691e107f433a06ee michai@work-lap:/tmp/f/f$ ls -l total 0 drwxr-xr-x 2 michai michai 60 Jul 29 16:46 d michai@work-lap:/tmp/f/f$ f mv --hard d d2 RENAME d d2 MOVED_FILE /tmp/f/f/d michai@work-lap:/tmp/f/f$ ls -l total 0 drwxr-xr-x 2 michai michai 60 Jul 29 16:46 d -rw-r--r-- 1 michai michai 0 Jul 29 16:47 d2 michai@work-lap:/tmp/f/f$ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Link to latest version of filename
On 7/29/15, Sean Woods s...@seanwoods.com wrote: If I use the URL /artifact/artifact_id I am taken to a source code listing of artifact_id. How can I do the same by filename? Suppose I want the HEAD version of a given file, and I always want that URL to point to the HEAD version? Also (if not too much trouble) -- if someone could point me to the code where this is implemented it would be very instructive for me. I tried, briefly, to follow the code path for the /artifact URL but wasn't successful... https://www.fossil-scm.org/fossil/artifact/f04e5aae?ln=1810 The answer to your first question is contained in the header comment. Note that to find the implementation of *any* webpage, you grep for 'WEBPAGE: pagename'. Similarly, to find the implementation of any command, grep for 'COMMAND: cmdname'. Thanks! ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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] Link to latest version of filename
If I use the URL /artifact/artifact_id I am taken to a source code listing of artifact_id. How can I do the same by filename? Suppose I want the HEAD version of a given file, and I always want that URL to point to the HEAD version? Also (if not too much trouble) -- if someone could point me to the code where this is implemented it would be very instructive for me. I tried, briefly, to follow the code path for the /artifact URL but wasn't successful... Thanks! ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fine(r) commit granularity
On Wed, Jul 29, 2015 at 6:34 AM, Steve Stefanovich s...@stef.rs wrote: From: Paolo Bolzoni Sent: Wednesday, 29 July 2015 08:38 fossil commit filename might help you in your problem? It gets messy when there is a number of files, on Windows at least where using pipes and xargs is limited compared to Unix. Sorry, I have no experience with Windows. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
