Re: [fossil-users] self-hosted Fossil for a team
On Sat, 10 Aug 2013 20:07:41 -0600 Chad Perrin c...@apotheon.net wrote: Dr. Hipp's series of suggestions have, of course, also been informative for me, and while I do intend to expand capabilities to the point where a separate webserver (probably nginx) is involved for some purposes as described in one of his replies, for now I just need something quick, effective, and secure to get some projects underway. Nginx doesn't support cgi, and as its developers says, it will never have cgi support. --- --- Eduardo Morras emorr...@yahoo.es ___ 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] Single sign-on (Login Group) configuration?
On 10 Aug 2013 21:54:59 -0600 Andy Bradford amb-fos...@bradfords.org wrote: Hello, After having recently discovered the single sign-on functionality provided by the Login Groups configuration, I've started experimenting with it. I must be doing something wrong because it doesn't seem to work: I started a fossil server on port serving fossils out of /tmp. In /tmp I have 3 fossils (new.fossil,one.fossil,two.fossil). I added them all to the same Login Group and added a user to new.fossil named someone. Then I tried to clone two.clone: $ fossil clone http://someone@remote:/two twoclone.fossil Password for Fossil user someone: remember password (Y/n)? y Round-trips: 2 Artifacts sent: 0 received: 1 Error: login failed missing or incorrect password for user someone What have I missed? I googled and couldn't really find any documentation for how this is supposed to work, and I even grep'ed the www directory in the fossil repository to no avail (next step sources). Here's some data from the config table in the two.fossil DB: project-code|f2b6f81f58bff6b8e6b8be1a5c1a679d7402351b|1376190998 project-name|Two|1376191759 peer-repo-3aeaa6385a3e39cf|/tmp/new.fossil| peer-name-3aeaa6385a3e39cf|New| peer-name-7844a4a7c15dad42|One| peer-repo-7844a4a7c15dad42|/tmp/one.fossil| login-group-code|03c19721921c03aa| login-group-name|Team1| And new.fossil: project-code|3aeaa6385a3e39cf1f654e4ab54f3ecd36ed1e6b|1376152719 peer-repo-7844a4a7c15dad42|/tmp/one.fossil| peer-name-7844a4a7c15dad42|One| login-group-code|03c19721921c03aa| login-group-name|Team1| peer-name-f2b6f81f58bff6b8|Two|1376191901 peer-repo-f2b6f81f58bff6b8|/tmp/two.fossil|1376191901 Thanks, User information is not cloned. If you want clone it from original server to cloned one you must use : fossil configuration pull user --overwrite original_repo_url HTH --- --- Eduardo Morras emorr...@yahoo.es ___ 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] ssl implementation
On 2013-08-10 04:21, Chad Perrin wrote: On Sun, Aug 04, 2013 at 01:06:38PM +0200, Rene wrote: The reason I choose axTLS . . . snip . . . If this is of interest I can add it on a branch. I find it pretty interesting. The biggest problem I see with axTLS is the protocol support limitation you identified. Are there good howtos for using axTLS out there on the web somewhere? No there isn't. I used the information from http://axTLS.sf.net to create the fossil interface. on unix you can do make menuconfig and everything it provide can be selected. The writer Cameron Rich is responsive when asked questions. As to the protocol (http://en.wikipedia.org/wiki/Transport_Layer_Security) looking at ths table: Protocol version Website support Security SSL 2.0 27.4% Insecure SSL 3.0 99.7% Depends on cipher and depends on patching with RFC 5746 TLS 1.0 99.3% Depends on cipher TLS 1.1 14.5% Depends on cipher TLS 1.2 17.0% Depends on cipher It seems not to be a problem In testing I used fossil clone https://fossil-scm.org/ and I cloned via my own internal Apache web server I checked yesterday and you can build on windows with msc and cygwin. The documentation states that you always needs GnuMake (also under windows, The cygwin environment is used to build a config executable (make config or menuconfig But then you need the curses library). After that the config is started and you have your choice of build environment. As I stated before my frustration came from setting up openss[hl] on windows and Solaris. Therefore I looked at this option. Having read your question about team setup on freebsd, My recommendation is to go with ssh keys. Much simpler provided that all you need/want is cmdline access. With the standard ssh functionality you can get by. The only minor thing in that setup is that the log is not recording the user that did clone/sync/pull/push but the fossil owner. I quess that is easy enough to fix. But do use forced commands otherwise people can gain access to the fossil account. If you so wish to prevent logins. Or prevent logins by using the shell /bin/nologin. I have been looking at abusing the current ssh where users are elevated to the highest user level within fossil. I found it surprisingly difficult to get the tunnels to setup and talk to the fossil process I thought of socat but that is not something you pick of the net and use :-(. If your ssh package is flawed (You have a much bigger problem) or an unauthorized person got a hold of a ssh key or you have a rogue user (in al 3 cases they have access to test-http) I assume(BUT CAN NOT PROVE) that it is possible to look at the fossil source and craft a package that could rearrange your setup over ssh. Why someone would want that is beyond me! (AGAIN it is very possible that I'm completely wrong here!) Andy's patch will mean that you have to login into ssh and fossil. It means you have to administrate the users in fossil also. While in the standard the ssh key is enough. If you have a separation of jobs with different capabilities in fossil and you want to enforce them you need andy's patch -- Rene ___ 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] self-hosted Fossil for a team
On Sun, Aug 11, 2013 at 12:43:24PM +0200, Eduardo Morras wrote: On Sat, 10 Aug 2013 20:07:41 -0600 Chad Perrin c...@apotheon.net wrote: Dr. Hipp's series of suggestions have, of course, also been informative for me, and while I do intend to expand capabilities to the point where a separate webserver (probably nginx) is involved for some purposes as described in one of his replies, for now I just need something quick, effective, and secure to get some projects underway. Nginx doesn't support cgi, and as its developers says, it will never have cgi support. . . . but you can use fastcgi with nginx. Is that not good enough for Fossil? -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ 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] self-hosted Fossil for a team
On Sat, Aug 10, 2013 at 11:40:34PM -0600, Andy Bradford wrote: Thus said Chad Perrin on Sat, 10 Aug 2013 20:07:41 -0600: Thank you. This looks like it will probably suit our needs quite well for the time being. I'll investigate further on my own at this point, though if any more informative replies come through I'll of course learn from them as well. By the way, if you do it this way, all IP addresses logged with commits to your fossils will appear to come from 127.0.0.1 and not from the actual SSH client that is being used to access it. This may or may not be important to you. It should still log Fossil usernames though -- right? If so, that'll do, at least for now. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ 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] ssl implementation
Thanks for all your information about issues related to axTLS. Not everything you said warrants a specific response from me, but the thanks is my general response for everything to which I do not specifically respond below. Specific comments follow. On Sun, Aug 11, 2013 at 01:21:37PM +0200, Rene wrote: On 2013-08-10 04:21, Chad Perrin wrote: On Sun, Aug 04, 2013 at 01:06:38PM +0200, Rene wrote: The reason I choose axTLS . . . snip . . . If this is of interest I can add it on a branch. I find it pretty interesting. The biggest problem I see with axTLS is the protocol support limitation you identified. Are there good howtos for using axTLS out there on the web somewhere? No there isn't. I used the information from http://axTLS.sf.net to create the fossil interface. I hadn't been able to find any. I'm glad it's not just me who couldn't find them, but at the same time bummed that it means you can't suggest any for me. Bit of a quandary, there. Having read your question about team setup on freebsd, My recommendation is to go with ssh keys. That's my plan. My interest in axTLS is actually mostly unrelated to Fossil, though I support there being options other than OpenSSL or GnuTLS. In fact, both OpenSSL and (especially) GnutTLS have license compatibility problems that frankly annoy the crap out of me, and axTLS licensing neatly solves that if it also solves the technical needs of a project. Much simpler provided that all you need/want is cmdline access. With the standard ssh functionality you can get by. The only minor thing in that setup is that the log is not recording the user that did clone/sync/pull/push but the fossil owner. I quess that is easy enough to fix. But do use forced commands otherwise people can gain access to the fossil account. If you so wish to prevent logins. Or prevent logins by using the shell /bin/nologin. Err . . . wait. Is it not logging the *user*, or just the IP address? What would it log in place of the actual authenticated Fossil user account that initiated the sync? -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ 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] self-hosted Fossil for a team
On Sun, Aug 11, 2013 at 2:37 PM, Chad Perrin c...@apotheon.net wrote: . . . but you can use fastcgi with nginx. Is that not good enough for Fossil? Fossil is not fastcgi-compatible. i tried to get it working a few years ago but fastcgi requires that each execution of the app has a clean starting state, and fossil's app is built to work only for a single execution. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] self-hosted Fossil for a team
On Sun, Aug 11, 2013 at 3:18 PM, Stephan Beal sgb...@googlemail.com wrote: Fossil is not fastcgi-compatible. i tried to get it working a few years ago but fastcgi requires that each execution of the app has a clean starting state, and fossil's app is built to work only for a single execution. That wasn't terribly clear. FastCGI basically starts 1 instance of the app and keeps feeding it new data for each request. Fossil's structure does not allow it to do that. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] ssl implementation
On 2013-08-11 14:49, Chad Perrin wrote: Thanks for all your information about issues related to axTLS. Not everything you said warrants a specific response from me, but the thanks is my general response for everything to which I do not [snip] Much simpler provided that all you need/want is cmdline access. With the standard ssh functionality you can get by. The only minor thing in that setup is that the log is not recording the user that did clone/sync/pull/push but the fossil owner. I quess that is easy enough to fix. But do use forced commands otherwise people can gain access to the fossil account. If you so wish to prevent logins. Or prevent logins by using the shell /bin/nologin. Err . . . wait. Is it not logging the *user*, or just the IP address? What would it log in place of the actual authenticated Fossil user account that initiated the sync? The user in the current ssh functionality is not authenticated against fossil. And in a single user setup that makes sense. In most cases a ssh key has a 1 on 1 relation with the unix account. In which case having the ssh key is OK and login in to fossil is redundant. And since you are the owner of that account. You already have the highest level of capabilities. Logging the owner makes perfect sense because of this 1 on 1 relationship However If your going to break that relation by having n keys on 1 account then, I presume, your doing something with fossil which wasn't designed. -- Rene ___ 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] ssl implementation
On Sun, Aug 11, 2013 at 3:24 PM, Rene renew...@xs4all.nl wrote: However If your going to break that relation by having n keys on 1 account then, I presume, your doing something with fossil which wasn't designed. One of the devs (Andy?) has been working on integrating ssh forced commands with fossil so that ssh connections can use fossil's authentication. i'm not sure what the status of that is, but from what i've read it sounds like a promising solution. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] ssl implementation
On 2013-08-11 15:26, Stephan Beal wrote: On Sun, Aug 11, 2013 at 3:24 PM, Rene renew...@xs4all.nl wrote: However If your going to break that relation by having n keys on 1 account then, I presume, your doing something with fossil which wasn't designed. One of the devs (Andy?) has been working on integrating ssh forced commands with fossil so that ssh connections can use fossil's authentication. i'm not sure what the status of that is, but from what i've read it sounds like a promising solution. -- - stephan beal http://wanderinghorse.net/home/stephan/ [1] http://gplus.to/sgbeal [2] Links: -- [1] http://wanderinghorse.net/home/stephan/ [2] http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users It is. I have been testing it. As I said if you have a multi user project with different job responsibilities and you want to maintain that in fossil then you need andy's patch! -- Rene ___ 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] self-hosted Fossil for a team
Thus said Chad Perrin on Sun, 11 Aug 2013 06:38:45 -0600: It should still log Fossil usernames though -- right? If so, that'll do, at least for now. Yes, it will do that. Andy -- TAI64 timestamp: 400052079daa ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] SSH implementation.
Thus said Stephan Beal on Sun, 11 Aug 2013 15:26:50 +0200: One of the devs (Andy?) has been working on integrating ssh forced commands with fossil so that ssh connections can use fossil's authentication. i'm not sure what the status of that is, but from what i've read it sounds like a promising solution. Most of the foundational work is pretty much done. The biggest part was simply removing fossil's dependency on whatever shell might exist in the SSH account. Now it's simply a matter of figuring out when, and when not, to prompt for a Fossil account, and consequently, when to send and when not to send login credentials. And finally how much of that should be exposed in the global config database. I could use some feedback for the latter, but it might require a lengthy discussion of the cases in which the different behaviors might be desirable. :-) [lengthy discussion follows] The latest is here: http://www.fossil-scm.org/index.html/timeline?r=ssh-test-http Basically it restores the original test-http interface (for the 1 to 1 case) which will not prompt you for a Fossil username/password and uses test-http on the remoe side to provide localauth: fossil clone ssh://amb@remote//tmp/proj.fossil clone.fossil It retains all the new functionality which allows the user to use Fossil credentials with SSH by calling ``fossil http'' as the remote command. Cases in which it will prompt for password: # will prompt for Fossil user amb and login with SSH user amb: fossil clone -h on ssh://amb@remote//tmp/proj.fossil clone.fossil # will prompt for Fossil user otheruser but login to SSH user amb: fossil clone -h on -l otheruser ssh://amb@remote//tmp/proj.fossil clone.fossil # will prompt for Fossil user otheruser but login to SSH using local USER fossil clone -h on -l otheruser ssh://remote//tmp/proj.fossil clone.fossil The username specified with -l can currently be set in the global config and leads to the following behaviors: # set global ssh-fossil-user fossil settings ssh-fossil-user otheruser # will prompt for Fossil user otheruser but login to SSH user amb: fossil clone -h on ssh://amb@remote//tmp/proj.fossil clone.fossil # will prompt for Fossil user otheruser but login to SSH using local USER fossil clone -h on ssh://remote//tmp/proj.fossil clone.fossil All of the above work well both with and without SSH keys (and in some cases SSH keys that force a command) because the SSH user is the same as the remote SSH user. In the case where the remote SSH account requires SSH keys, and a force command that implements REMOTE_USER authentication (because we identify the Fossil user by their key), I suppose I could trick Fossil into not prompting using -h off. Then the fossil client will think it's doing ``fossil test-http'' on the remote connection, even though the remote side will really do something like ``fossil http /repos'' and setup REMOTE_USER. # will *correctly* not prompt for any Fossil remote user fossil clone -h off ssh://fossil@remote//tmp/proj.fossil clone.fossil Maybe this latter is the best way to deal with this case? If so, then I think it's mostly ready (just need some testers other than myself). Andy -- TAI64 timestamp: 40005207aacb ___ 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] self-hosted Fossil for a team
On Sun, Aug 11, 2013 at 9:20 AM, Stephan Beal sgb...@googlemail.com wrote: On Sun, Aug 11, 2013 at 3:18 PM, Stephan Beal sgb...@googlemail.comwrote: Fossil is not fastcgi-compatible. i tried to get it working a few years ago but fastcgi requires that each execution of the app has a clean starting state, and fossil's app is built to work only for a single execution. That wasn't terribly clear. FastCGI basically starts 1 instance of the app and keeps feeding it new data for each request. Fossil's structure does not allow it to do that. Does too. For Fossil to run FastCGI/SCGI, all that is needed is another command similar to fossil server or fossil ui. The fossil server listens for incoming HTTP requests and responds separately to each request. A fossil fastcgi or fossil scgi command would do basically the same thing, except that it would interpret the FastCGI or SCGI wire protocol rather than HTTP. Fossil does not support FastCGI or SCGI simply because I do not have ready access to a webserver that supports those things and hence no way to test any proposed implementation. -- 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
Re: [fossil-users] ssl implementation
On Sun, Aug 11, 2013 at 03:24:40PM +0200, Rene wrote: On 2013-08-11 14:49, Chad Perrin wrote: Err . . . wait. Is it not logging the *user*, or just the IP address? What would it log in place of the actual authenticated Fossil user account that initiated the sync? The user in the current ssh functionality is not authenticated against fossil. Ah, okay. I thought you meant the Fossil user account for a moment there. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ 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] self-hosted Fossil for a team
On Sun, Aug 11, 2013 at 6:10 PM, Richard Hipp d...@sqlite.org wrote: On Sun, Aug 11, 2013 at 9:20 AM, Stephan Beal sgb...@googlemail.comwrote: That wasn't terribly clear. FastCGI basically starts 1 instance of the app and keeps feeding it new data for each request. Fossil's structure does not allow it to do that. Does too. For Fossil to run FastCGI/SCGI, all that is needed is another command similar to fossil server or fossil ui. The fossil server listens for incoming HTTP requests and responds separately to each request. A fossil fastcgi or fossil scgi command would do basically the same thing, except that it would interpret the FastCGI or SCGI wire protocol rather than HTTP. It _can_ do that but that negates the benefit of using fastcgi because fossil ends up forking anyway. Fossil does not support FastCGI or SCGI simply because I do not have ready access to a webserver that supports those things and hence no way to test any proposed implementation. There were 3 problems when i attempted a fastcgi port way back when (2009? 2010?): - FastCGI replaces read() and write() with its own drop-in replacements, so all code has to be compiled using them. However, they got the signature wrong on the write() routine. They take a non-const (void*) for the src argument), meaning that no compliant code can compile against it. - FastCGI wants to initialize fossil one time and keep piping new POST/GET data through it. Fossil's environment, IIRC, would potentially pollute one request with data from another since they were all sharing the same memory. - Because of the singleton behaviour, it was necessary to fork a new instance on each request, eliminating the benefit of fastcgi. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] New user request
Very glad you like it. On Aug 10, 2013 10:55 PM, Sam Sellars philosopher@gmail.com wrote: Thank you sir! This is exactly the type of thing I am looking for. I appreciate the time you put into this. — Hi Sam. Welcome aboard. I think Fossil is excellent, and I hope you will too. I'm typing on a mobile device ATM, so please excuse the brevity and spelling errors. I use fossil for all my personal projects, as well as professionally. For personal projects, I make a project-specific dir under my project containing dir (~/work), such as ~/work/foo/, and create an out-of-tree repo: cd ~/work/foo; fossil new ../fossils/foo.fsl; fossil open ../fossils/foo.fsl . Then, in the project dir I make ./doc, ./src/vendor, ./test. Supporting third-party code goes into ./src/vendor/libawesome (for example), my own code goes into ./src, docs to ./doc, and tests to ./test. For an imaginary lib awesome project that I want to build against, I place the code in ./src/vendor/libawesome, fossil add ./src/vendor, then commit it to it's own branch: fossil ci -m libawesome v.1.2.3 --branch vendor For my own code, infrastructure, I go back to trunk (fossil co trunk), add my files: (cd ~/work/foo; fossil add ./Smakefile ./src/*.c ./src/*. h.in) and do initial commit: fossil ci -m initial commit. If you feel you need/may patch your vendor code, you can: fossil co vendor; [hack hack hack]; fossil ci -m custom patches against lib awesome for project foo --branch vend_patched -- and maintain this along with upstream lib awesome updates: fossil co vendor; [dump lib awesome v1.2.4 code over 1.2.3]; fossil ci -m update lib awesome 1.2.3 - 1.2.4 Import to vend_patched: fossil co vend_patched; fossil merge vendor; [check for conflicts, correctness], fossil ci -m merge latest lib awesome 1.2.4 from [vendor] Back to the code your writing yourself: fossil co trunk; fossil merge vend_patched; fossil ci -m import supporting vendor code; [hack hack hack]; fossil ci -m my useful commit msg here; [hack hack hack] ... now you (still on [trunk]) want to start on a potentially build-breaking experimental feature: a bunny themed widget set. Start hacking in bunny-code, but at first commit: fossil ci -m start of bunny conversion --branch hop_hop You've now got two branches that are interesting to you: current stable production in [trunk], and the Next Big Killer Feature (not ready for prime time), in hop_hop. You hack on [hop_hop] (which is a derivative of [trunk], and improve it. Along the way though, your boss says: I've heard lowercase is the new black; make all the dialogue in our current project lowercase. No title case, upper case, camel case... All user facing text is lowercase. [hop_hop] is still WIP (work in progress), not ready for public consumption, so you go back to [trunk] (which you are shipping). You're in the middle of hacking [hop_hop], and you're not really ready to commit, but you don't want to lose your work. No problem. Stash it. fossil stash add -m hop_hop fluffy tail feature - incomplete Your work is safe in a stash that is shared among all branches, and you have no pending commits in your working set (you just stashed it, and when that partial work was stashed, the pertinent files were reverted to the state of the last commit.) You prepare to start lowercasing: fossil co truck; [hack hack hack]; fossil ci -m lowercase here, lowercase there, and change all user dialogue, etc to lowercase, committing as you convert. You tag a new release: fossil tag add foo_5.4.3 trunk, notify q/a and release management, and get back to bunny hacking. fossil co hop_hop You start making a game plan for finishing fluffy tail feature, when you realize that the super-awesome lowercasing you just finished isn't in your hop_hop codebase. No problem: fossil merge foo_5.4.3; [check work for conflicts, nice importing]; fossil ci -m import lowercase excellence from [foo_5.4.3] Now, pick up your partial fluffy tail implementation: fossil stash pop (pops last stashed item like a stack operation), and you're ready to finish your interrupted coding and finish bunnifying. As you finish coding and commit, your boss comes up and says: What have you been working on these last 3 weeks? I'll show you, you say! fossil server [Open Firefox or opera, or chrome, etc], http://127.0.0.1:8080/ You are taken to the Foo Project Repository homepage, and from there you browse the timeline which has a pretty layout of each commit, each branch, each merge, each tag... Your boss is impressed. I'm impressed. But I want to give you some feature requests we've collected from clients. Would you like them as a crumpled collection of post it notes, or some other format? You say: Point your IE4 browser to 192.168.0.99:8080/, log in as superboss like I showed you, and add each item as a feature-request ticket, so we can all see the requests, and their state, and append notes to each
Re: [fossil-users] SSH implementation.
Thus said Andy Bradford on 11 Aug 2013 09:15:53 -0600: # will prompt for Fossil user otheruser but login to SSH using local USER fossil clone -h on -l otheruser ssh://remote//tmp/proj.fossil clone.fossil I'm also considering dropping -h altogether, and making neither options global settings, which will simplify the interface somewhat, at the expense of some flexibility. -l somefossillogin -h on Are somewhat redundant in my opinion, but are needed if the settings are stored in the global settings so they can be overidden when cloning new fossils. Andy -- TAI64 timestamp: 40005207f913 ___ 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] ssl implementation
Thus said Chad Perrin on Sun, 11 Aug 2013 10:10:40 -0600: On Sun, Aug 11, 2013 at 03:24:40PM +0200, Rene wrote: On 2013-08-11 14:49, Chad Perrin wrote: Err . . . wait. Is it not logging the *user*, or just the IP address? What would it log in place of the actual authenticated Fossil user account that initiated the sync? The user in the current ssh functionality is not authenticated against fossil. Ah, okay. I thought you meant the Fossil user account for a moment there. What he meant was this..., when you do the following: fossil clone ssh://chad@freebsdhost/fossils/project.fossil project.fossil There is no Fossil authentication that happens in this interaction. It is presumed that because you have SSH access to the file, that you also have Fossil access to the file. So the only entry that will show up in the log for chad is chad. This is fine, and it will probably even work if you want to give out an SSH account for each user that you want to access the fossil as long as the permissions on the fossils are correctly setup for Unix groups. But if you want to have a single SSH account under which to aggregate the fossils, then you won't be able to do it yet, because all access to the fossils would appear to be logged in from the exact same user. All that being said, this is not how you are currently planning on setting up. There, you are simply using SSH as a tunnel/proxy to get you to the Fossil daemon listening on port . Then you do: fossil clone http://chad@localhost:/project project.fossil And it will prompt you for Fossil user chad's credentials because it is not using SSH as the transport per se. Hopefully that clarifies. Andy -- TAI64 timestamp: 40005207fb33 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] libfossil minor milestone: tag app
Hi, all, Another status update for what is still tentatively known as libfossil... As of a few minutes ago its tagging support is more or less functional: [stephan@host:~/cvs/fossil/f2]$ ./f-tag Usage: ./f-tag -a ARTIFACT_TO_TAG -t TAGNAME [-v VALUE] [-u USER] [-R REPO_DB] Adds a tag to the given Fossil repository artifact. MARKER: f-tag.c:84:main(): Done! rc=103 (FSL_RC_MISUSE) [stephan@host:~/cvs/fossil/f2]$ ./f-tag -a=current -t=f-tag-test-3 -v 'again!' --verbose ... VERBOSE: f-tag.c:76:main(): Added tag [f-tag-test-3] to [current]. New tag rid=1127. MARKER: f-tag.c:84:main(): Done! rc=0 (FSL_RC_OK) And it's in the timeline: [stephan@host:~/cvs/fossil/f2]$ f time -t g -n 2 === 2013-08-11 === 21:31:39 [64df2f9505] Edit [2caba4c8]: Add -tag-test-3 with value again!. (user: stephan) (Side note: it accepts flags in (-flag VALUE) or (-flag=VALUE) form) The code for the f-tag mini-app is pretty small and self-explanitory: http://fossil.wanderinghorse.net/repos/f2/index.cgi/artifact/bfdef0fc52db97cdba7fd3ae746cc789c4281f03 Happy Hacking! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
