today I stumbled over the following warning when doing a checkin or sync:

Warning: uv-pull-only                                       
         Unable to push unversioned content because you lack
         sufficient permission on the server

after having generated a new server side repo (actually just a copy of my local repo) on a machine to which I talk via ssh. observations:

a) there is no unversioned content whatsoever to start with (neither there nor here)

b) I have a global setting uv-sync on and the warning goes away when I switch that off

c) local and remote user names are completely identical (local repo took over local OS user name when I generated it and the user name on the remote server is identical to it)

d) I do have adequate read/write permissions on the remote repo and can do checkins.

question: why is the warning triggered in the first place? and would uv-push fail (and for what reassons)?

The warning is probably triggered because sync tries to compare (possibly empty) lists of unversioned objects.

You need the "y" capability on the server to uv-push.

fossil link: /setup_ucap_list.

-- 
Regards,
Kees Nuyt

mmh. back in "capabilities interdependency hell" again it seems ...

some remarks

1. I am setup user on both repos (which are initially file system level copies of each other since that's how the server-side repo came into being in the present case). shouldn't "s" include everything anyway, especially uv-push?

2. it seems not adequate to me to issue warnings if the "unversioned" lists are empty even if a global uv-sync on is in effect. case in point: I do have this global setting since if I have unversioned content I always want it to sync. OTOH most of the repos don't have any such content but it seems that I now need to set the "y" capability for all of them (or new ones) in the future which is totally redundant.

3. I have never seen that warning before (not that I can remember) in similar setups. is it only happening with repos created recently?

shouldn't "s" include everything anyway

No, on purpose.

most of the repos don't have any such content but it seems that I now need to set the "y" capability for all of them

I think we need a reproduction case or access to your repos. I'm not having such problems with my repos, nor are many others, if we can go on the fact that only you have complained of this in the months since this change in capability handling went in. (Between 2.9 and 2.10.)

On most of my repos, I never had 'y' cap, not needing it at all for most repos, so it is not the case that you always require this capability to push.

On one of the two repos where I do need this capability from time to time (rare), it's assigned to a lesser-privileged user than my Setup user on purpose, and the machines where I log in as the Setup user, I don't get this complaint.

On the one repo where the Setup user also has 'y' cap, I just removed it and was still able to sync.

is it only happening with repos created recently?

If so, it would be easy for you to reproduce and post the script of commands that causes it. A reproducible bug is a dead bug walking.

Again, we need details or a reproduction case. Current Fossil version, host OS, command output, maybe even repo copies.

I've just re-tested it here using tip-of-trunk, I just pushed an unversioned file up from my local machine to a remote. This is with a repo that goes back to late 2016, so it was probably created with a pre-1.37 trunk build of Fossil.

What do you get from fossil user cap mlatu from within a repo checkout on both sides?

Both fossil binaries say: 2.10 [9d9ef82234] 2019-10-04 21:41:13 UTC

'remote' uname -a: 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u1 (2016-09-03) x86_64 GNU/Linux 'local' is windows 10 64b

Do I need a checkout on remote? I cannot provide copies of the repos, instead will try to reproduce in case it has something to do with the machines in use.

#Output on 'local':#

D:\Project>fossil user cap mlatu
vy

D:\Project>fossil uv ls
1-MS.NET_FW_4.7.1_NDP471-KB4033342-ENU.exe
2-MS_VS_Tools4Office_Runtime_2010_Redistributable.exe
3-USB-Serialport_driver.msi
15.10.2019-1040.exe
13.01.2020-1330.exe
15.05.2019-1500.exe

D:\Project>fossil uv remove 15.05.2019-1500.exe

D:\Project>fossil uv ls
1-MS.NET_FW_4.7.1_NDP471-KB4033342-ENU.exe
2-MS_VS_Tools4Office_Runtime_2010_Redistributable.exe
3-USB-Serialport_driver.msi
15.10.2019-1040.exe
13.01.2020-1330.exe

D:\Project>fossil sync -u
Sync with http://192.168.100.111/fossil/Project
Round-trips: 2   Artifacts sent: 0  received: 0
Server says: pull only - not authorized to push
Round-trips: 2   Artifacts sent: 0  received: 3
Sync done, sent: 4431  received: 9156  ip: 192.168.100.111

#Output on 'remote':#

mlatu@remote:~$ fossil user cap mlatu --repository /opt/fossil/Project.fossil
vy
mlatu@remote:~$ fossil uv ls --repository /opt/fossil/Project.fossil
1-MS.NET_FW_4.7.1_NDP471-KB4033342-ENU.exe
2-MS_VS_Tools4Office_Runtime_2010_Redistributable.exe
3-USB-Serialport_driver.msi
15.10.2019-1040.exe
13.01.2020-1330.exe
15.05.2019-1500.exe

http://192.168.100.111/fossil/Project

There’s no mlatu@ before the IP in that URL, but there needs to be if the remote is to grant your user caps.

The simplest way to update the URL is

    C:\> fossil sync http://mlatu@192.168.100.111/fossil/Project

It will ask for your password, then give you the full sync your user is allowed. A UV sync should then work.

Incidentally, this means your repo allows anonymous clones. Since you appear to have a private repo here, have its Setup user run the Security Audit tool. They may want to tighten some of that down.

Yeah that seemed to be the problem, thank you.

I need the hosted repository accessible on this LAN, at least the Tickets and UVLists.

Until the uv sync broke, everything worked well enough, which is why I didn't realize I was interacting anonymously with the remote repo, especialy since the timeline seemed to correctly associate my local commits with my remote user.

The relationship between the sender of a commit and the user on the receiving repo used is a little ambiguous.

Perhaps you could display this constellation with "User" as "anonymous (mlatu)" instead of plain "mlatu"?

Anyways, thank you.

EDIT: Hm.. I can give 'nobody' the cap "New Ticket" and "Read Tickets", but what about reading the UVlist?

The relationship between the sender of a commit and the user on the receiving repo used is a little ambiguous.

That's pretty much the nature of distributed version control.

If you want something to blame here, it's that Fossil normally makes a pretty good illusion of being a centralized VCS in the typical "central and direct clones" model, so that when it breaks down, as in your case, it's not immediately obvious that all of your commits are hitting the local blockchain only, not being sync'd up to the central repo.

I'll tell you how I solve this: I almost never use Fossil UI to look at the local timeline, only the remote one. I've got a button on my browser bookmark bar that takes me to the remote timeline; it's my default view of a Fossil repo, even when /home is something else. Until a commit is in at least two places, it doesn't exist yet. This practice makes diagnosing situations like yours trivial.

In the rare cases where I do want the local timeline as distinct from the remote, I use the command line view. It's much less detailed and powerful, but it usually suffices for such cases.

I can give 'nobody' the cap "New Ticket" and "Read Tickets", but what about reading the UVlist?

That's gated by the "Read" capability, letter 'o'. It's also implicitly set by Write (cap 'i') since Fossil apparently chooses not to be a write-only medium. :)

I never (ever) use fossil ui to look at the local timeline. In fact I never look at the local timeline at all since my "remote" repo is sitting on the same LAN just in another room and there is no point for me in looking at the local timeline since I work alone in this company, so there can never be a difference between them anyways. (I also know the drill about the commit in only one place is no commit at all. Still trying to find the time to implement an actual automatic backup in case my remote falls off the desk or something. I wish there was someone who'd handle the "admin junk" (no offense, but I hate messing with the configs and my "customer" just wont cut me some slack) so I could just code.)... sorry.

I was describing the REMOTE timeline.

On my remote timeline I can see NO distinction between the authors of ANY of my commits. Except for those I did before migrating from bitbucket which are missing the IP address in the "Received from" field: All of my commits' author fields look the same. INCLUDING those I did now after closing down the repo and commiting against the "mlatu@"-URL.

I would send you a screenshot but I'm not using mlatu as my username and I have no intention in putting my full name out here atm.

#Also#

My remote's UI has no Read capability, is that normal?

Still trying to find the time to implement an actual automatic backup in case my remote falls off the desk or something.

Cron a call to fossil all push on the central machine, and set remote-url for the repos hosted by it to a third machine which you deem sufficiently safe. Could be could be across the building, to a server running at home, or to rented service in the cloud.

A useful variation is to use SSH for this instead of HTTP[S], since the backup machine doesn't need to expose Fossil UI to the outside world.

I was describing the REMOTE timeline.

How were you able to sync local commits to the remote without a login?

On my remote timeline I can see NO distinction between the authors of ANY of my commits.

You haven't got anonymous commit enabled, have you? If so, that would also answer my prior question.

If so, a trip to the Security Audit tool should be enlightening.

My remote's UI has no Read capability, is that normal?

It's normally inherited from one of the four hard-coded user categories.

What does the following POSIX shell script give?

for u in $(fossil user ls | awk '{print $1}' | sort -u)
do
    echo -n "$u: "
    fossil user cap $u
done

---

Feel free to anonymize the user names. We just need distinct user names, not exact values.

admin: s
anonymous:
backup: g
developer: dei
nobody: nrt
mlatu: avy
reader: kptw

When was the cap 'o' added?

How were you able to sync local commits to the remote without a login?

Your guess is as good as mine, it synced against the same URL except without mlatu@

Could this be a consequence of importing from a git repo? Although I'm no longer confident whether or not I actually did import this from bitbucket or if this repository was created slightly after I switched to fossil everywhere.

I could try and restore the previous situation (i.e. so i can commit anonymously again) and enable server logs if that helps.

My security audit says:

    This repository is Mostly PRIVATE. A valid login and password is usually required, however some content can be accessed either anonymously or by self-registered users:
        Tickets 

    WARNING: Sensitive material such as login passwords can be sent over an unencrypted connection.

    Fix this by changing the "Redirect to HTTPS" setting on the Access Control page. If you were using the old "Redirect to HTTPS on Login Page" setting, switch to the new setting: it has a more secure implementation.

    Users with administrator privilege are: mlatu, admin

    Users with "Write-Unver" privilege: mlatu

    Load average limiting is turned off. This can cause the server to bog down if many requests for expensive services (such as large diffs or tarballs) arrive at about the same time.

    To fix this, set the "Server Load Average Limit" on the Access Control page to approximately the number of available cores on your server, or maybe just a little less.

    The server error log is disabled. To set up an error log, make an entry like "errorlog: FILENAME" in the CGI script at /usr/lib/cgi-bin/fossil.

    User capability summary:
     	Code	Forum	Tickets	Wiki	Unversioned Content
    "nobody" 	off 	off 	write 	off 	off
    "anonymous" 	off 	off 	write 	off 	off
    "reader" 	off 	off 	write 	write 	off
    "developer" 	write 	off 	write 	write 	read
    New User Default 	off 	off 	write 	off 	off
    Regular User 	off 	off 	write 	off 	off
    2 Adminstrators 	write 	write 	write 	write 	write

    Content Security Policy:
        default-src 'self' data:
        script-src 'self' 'nonce-##SOMEHASH##'
        style-src 'self' 'unsafe-inline' 

    Email alerts are disabled 

mlatu: avy

Which side is this? Only the HTTP server side matters when it comes to user caps; local caps aren't checked.

When was the cap 'o' added?

Approximately since Day 1. I chased it back to September 2007 before giving up on narrowing it further.

But again, cap 'i' implies 'o', so you don't always explicitly need it.

It's mainly useful for users or user categories that are read-only, as with the default 'nobody' category, which starts off with 'gjorz'.

Could this be a consequence of importing from a git repo?

I can't see how. Fossil doesn't consult anything in the block chain when checking user caps, and pretty much the only thing you get on the conversion is the block chain. The user table in particular is part of Fossil's purely relational DB bits, outside the block chain.

My security audit says:

As above, this is only useful if you're running this on the server, not on the local repo.

Which side is this?

On the remote, had to add --repository because I have no checkouts on that system.

As above, this is only useful if you're running this on the server, not on the local repo.

I don't mess with the local repo's web-ui except for the ignore settings. That security audit was from my remote repo.