Comment by nomadbyte | Hacker News Reader

Comment by nomadbyte | Hacker News Reader

Parent Full thread

Seems like you were trying to create a centralized server, akin to GitHub or ChiselApp to serve as a main repo and registration site, allowing users to self-register.

Fossil as such does not need a central server; each user may just as well be self-sufficient, and if needed, to share his/her repo to other users (fossil server).

Still one easy way to accomplish the centralized setup is to designate one Fossil instance as the main/origin, create a repo, and launch 'fossil server', it will show the port on which it listens. Then make other users connect to the main by http://hostname:port.

To allow users to self-register, you need to log-in as admin-user and check an option in Admin::Access:Allow users to register themselves. Keep it checked at least until all of your users have registered. Make sure users have a Developer privilege, so that they can push the changes to the main repo.

This will add user names to the central repo, and will prompt for authorization at clone/commit/pull/push/update. In case the registered username is different from local login username, the users may need to make it as local fossil admin (`fossil clone <url> --admin-user <username>`). Then after `fossil open`, make this username as cloned repo default (`fossil user default <username> --user <username>`)

HTTP connect is fairly robust, with additional layer of security added on the Fossil's side to somewhat compensate for the clear-text login. Should suffice in trusted environment.

Your LAN should have no problems routing this as it's indeed a local traffic.

BTW, Fossil has a nice convenience feature called "autosync" which makes login/password use transparent, only enter it once and then all commits would automatically attempt to sync to origin repo. It can be turned-off in settings if not needed, on per-clone basis (fossil set autosync off)

Hope this helps.

I very much wanted/needed a "distributed/centralised" model - everyone is working on the same repo. I never did get sync/push to work - I could pull down repo and wiki, but neither code nor wiki changes would auto-sync over http - I forget the exact error I got, but it seemed others had come across the issue in older versions - the suggested fix was to make sure server and client was on the same version of Fossil - due to some change in handling of storing usernames and password hashes - but this was in a version quite a few point-releases older than the oldest binary I tried. And I also tried with latest stable with a pristine repo.

I only ever got sync/push to work over ssh.

I might have tried having users pull changes from each other - but with 25+ students a central server/repo for resolving merge conflicts becomes necessary - not to mention that it would be hopeless for people new to the concept of version control in general and distributed vcs in particular.

Has anyone actually got auto-sync to work over http with Fossil of late?

It's hard to know what your problems are from such a vague description, but I've been using Fossil over HTTP on private LANs for years now. I only use Fossil over SSH when I need to tunnel to a remote server that can't forward HTTP out to where the client can see it.

Try this:

    fossil clone http://fossil-scm.org x.fossil

Success? You just used Fossil over HTTP. :)

I have two guesses about what your problem was:

1. You didn't realize that Fossil normally listens on port 8080 by default, incrementing when it gets a bind failure, so that it could be on some higher port number, like 8082 if you have two other Fossil server instances running. If you need Fossil to bind to a specific port number, you need to pass -P to the "fossil server" command.

2. Your server machine's firewall blocks the Fossil listening port by default, and you didn't open it up.

Here's my "fossil server" wrapper script, which may help you the next time you try this:

    #!/bin/bash
    OLDPID=`pgrep fossil`
    if [ -n "$OLDPID" ]
    then
        echo "Killing old Fossil instance (PID $OLDPID) first..."
        kill $OLDPID
    
        typeset -i i=1
        while kill -0 $OLDPID > /dev/null 2>&1 && [ $i -lt 30 ]
        do
            if [ $i -eq 1 ]
            then
                echo -n "Waiting for it to die..."
            fi
            sleep '0.1s'
            i=i+1
        done
        echo
    fi
    
    fossil server -P 3691 --repolist /museum > /dev/null &
    echo Fossil server running, PID $!.

This is a Bash script, so for Windows you'd have to run it under either Cygwin or WSL.

It assumes your Fossils are stored in /museum — because where else would you keep fossils? — and that you like svnserve+1 as your Fossil port number. Adjust to taste.

To clone from such a server, say:

    fossil clone http://myuser@myserver:3691/reponame reponame.fossil

To view its web pages, visit:

    http://myserver:3691/reponame

That is, because we're serving a directory of Fossils in this case, you need to give the repository name to view a specific repository name. However, since we passed --repolist to "fossil server", if you visit the web root URL, you get a list of available repositories rather than an HTTP error.

Cloning worked fine. I could not push/sync or auto sync over authenticated http. So I could pull down code, and serve that code. But the only way to sync would have been push over ssh, or pull from the server - which doesn't really scale with 26+ clients.

[ed: I'm away from the computers I tested on, but I remember I found quite a few stories like this, which all seemed to be a few years old, and had no resolution:

http://fossil-users.fossil-scm.narkive.com/iM7AQS3b/authenti...

Which is why I asked if anyone has been able to, with a current Fossil build, to:

On server "a" (in my case running Ubuntu 16.10, but testing both machines running Windows 10 would also be interesting): run fossil init ; fossil ui #change auth, register normal users user1, user2; fossil serve

Clone from a as user1, user2 on machine b with defined passwords (I got this far).

On b, run fossil ui, edit wiki as user1 and/or user2 - have sync work. Or edit and commit code and have sync work. ]

> Cloning worked fine. I could not push/sync or auto sync over authenticated http.

That sounds like your Fossil instance allows anonymous cloning but not anonymous checkins, and that you did not give a user name with the clone command, so that when you tried to check in a change (or sync, as you say) the remote server refused to accept the anonymous contribution.

Note in my examples above the `myuser@` part.

> I found quite a few stories like this...with no resolution

The specific one you pointed me to shows exactly the problem I describe above. The URL "http://pi:8193" gives a machine name and a port, but no user name.

Fossil will use your local user name as the Fossil user in some circumstances, but not in the clone command, because that signals an anonymous clone.

[Re-reading] your comment and it may be this is what I missed (although I'm fairly certain I tried both with "developer" and ["administrator" privs]):

> Make sure users have a Developer privilege, so that they can push the changes to the main repo.

And/or:

> In case the registered username is different from local login username, the users may need to make it as local fossil admin (`fossil clone <url> --admin-user <username>`). Then after `fossil open`, make this username as cloned repo default (`fossil user default <username> --user <username>`)

(although I'm fairly certain the error messages I got mentioned the correct user names. Is the bit about --admin-user in the Fossil docs?).

Reply on news.ycombinator.com