[fossil-users] question about parms and ownership of repo vs current/parent dir
Hello,
ran to something I didn't understand just now, and turned out to be
(likely) a thing concerning permissions.
In short, syncing with repo seems to work or not depending of
perms/ownership of that repo:
root@main:/tmp/ftmp# ls -ld * .
drwxr-xr-x 2 root wheel 512 May 29 15:32 .
-rw-r--r-- 1 ftp ftp3435520 May 29 15:32 f_f
-rw-r--r-- 1 root wheel 3592192 May 29 15:32 r_w
root@main:/tmp/ftmp# f sync r_w -R f_f
Round-trips: 1 Artifacts sent: 0 received: 0
Sync finished with 637 bytes sent, 615 bytes received
root@main:/tmp/ftmp# f sync f_f -R r_w
Round-trips: 1 Artifacts sent: 0 received: 0
Error: Database error: unable to open database file: {CREATE TEMP
TABLE onremote(rid INTEGER PRIMARY KEY);}
Round-trips: 1 Artifacts sent: 0 received: 0
Sync finished with 638 bytes sent, 319 bytes received
root@main:/tmp/ftmp# chown root.wheel f_f
root@main:/tmp/ftmp# ls -ld * .
drwxr-xr-x 2 root wheel 512 May 29 15:33 .
-rw-r--r-- 1 root wheel 3435520 May 29 15:33 f_f
-rw-r--r-- 1 root wheel 3592192 May 29 15:33 r_w
root@main:/tmp/ftmp# f sync f_f -R r_w
Round-trips: 1 Artifacts sent: 0 received: 0
Sync finished with 635 bytes sent, 614 bytes received
root@main:/tmp/ftmp# f ver
This is fossil version 1.29 [87130593e4] 2014-05-26 20:55:57 UTC
Can anyone tell what happens under the hood here..?
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] question about parms and ownership of repo vs current/parent dir
On Thu, May 29, 2014 at 9:35 AM, Michai Ramakers m.ramak...@gmail.com
wrote:
Hello,
ran to something I didn't understand just now, and turned out to be
(likely) a thing concerning permissions.
In short, syncing with repo seems to work or not depending of
perms/ownership of that repo:
root@main:/tmp/ftmp# ls -ld * .
drwxr-xr-x 2 root wheel 512 May 29 15:32 .
-rw-r--r-- 1 ftp ftp3435520 May 29 15:32 f_f
-rw-r--r-- 1 root wheel 3592192 May 29 15:32 r_w
root@main:/tmp/ftmp# f sync r_w -R f_f
Round-trips: 1 Artifacts sent: 0 received: 0
Sync finished with 637 bytes sent, 615 bytes received
root@main:/tmp/ftmp# f sync f_f -R r_w
Round-trips: 1 Artifacts sent: 0 received: 0
Error: Database error: unable to open database file: {CREATE TEMP
TABLE onremote(rid INTEGER PRIMARY KEY);}
It is acting like you do not have write permission on /var/tmp.
Round-trips: 1 Artifacts sent: 0 received: 0
Sync finished with 638 bytes sent, 319 bytes received
root@main:/tmp/ftmp# chown root.wheel f_f
root@main:/tmp/ftmp# ls -ld * .
drwxr-xr-x 2 root wheel 512 May 29 15:33 .
-rw-r--r-- 1 root wheel 3435520 May 29 15:33 f_f
-rw-r--r-- 1 root wheel 3592192 May 29 15:33 r_w
root@main:/tmp/ftmp# f sync f_f -R r_w
Round-trips: 1 Artifacts sent: 0 received: 0
Sync finished with 635 bytes sent, 614 bytes received
root@main:/tmp/ftmp# f ver
This is fossil version 1.29 [87130593e4] 2014-05-26 20:55:57 UTC
Can anyone tell what happens under the hood here..?
Michai
___
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
Re: [fossil-users] question about parms and ownership of repo vs current/parent dir
On 29 May 2014 15:44, Richard Hipp d...@sqlite.org wrote:
On Thu, May 29, 2014 at 9:35 AM, Michai Ramakers m.ramak...@gmail.com
wrote:
In short, syncing with repo seems to work or not depending of
perms/ownership of that repo:
root@main:/tmp/ftmp# ls -ld * .
drwxr-xr-x 2 root wheel 512 May 29 15:32 .
-rw-r--r-- 1 ftp ftp3435520 May 29 15:32 f_f
-rw-r--r-- 1 root wheel 3592192 May 29 15:32 r_w
root@main:/tmp/ftmp# f sync r_w -R f_f
Round-trips: 1 Artifacts sent: 0 received: 0
Sync finished with 637 bytes sent, 615 bytes received
root@main:/tmp/ftmp# f sync f_f -R r_w
Round-trips: 1 Artifacts sent: 0 received: 0
Error: Database error: unable to open database file: {CREATE TEMP
TABLE onremote(rid INTEGER PRIMARY KEY);}
It is acting like you do not have write permission on /var/tmp.
drwxrwxrwt 4 root wheel 512 May 29 15:33 /var/tmp
In the example above, I su'd root.
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] question about parms and ownership of repo vs current/parent dir
On Thu, May 29, 2014 at 3:35 PM, Michai Ramakers m.ramak...@gmail.com
wrote:
In short, syncing with repo seems to work or not depending of
perms/ownership of that repo:
root@main:/tmp/ftmp# ls -ld * .
root@main:/tmp/ftmp# f sync r_w -R f_f
...
root@main:/tmp/ftmp# f sync f_f -R r_w
Round-trips: 1 Artifacts sent: 0 received: 0
Error: Database error: unable to open database file: {CREATE TEMP
TABLE onremote(rid INTEGER PRIMARY KEY);}
This is likely (i'm speculating!) a chroot-related problem, because (A)
root has (at the OS level) no permissions restrictions and (B) fossil
always chroot's when run as root. We recently had a bug where the current
dir was not being properly determined in a chroot case, and maybe (again,
speculating) there's a similar case which only triggers in this setup.
(Remember that fossil does not know about OS-level users, with the single
exception of the root user.)
--
- 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] question about parms and ownership of repo vs current/parent dir
On 29 May 2014 15:57, Stephan Beal sgb...@googlemail.com wrote:
On Thu, May 29, 2014 at 3:35 PM, Michai Ramakers m.ramak...@gmail.com
wrote:
In short, syncing with repo seems to work or not depending of
perms/ownership of that repo:
root@main:/tmp/ftmp# ls -ld * .
root@main:/tmp/ftmp# f sync r_w -R f_f
...
root@main:/tmp/ftmp# f sync f_f -R r_w
Round-trips: 1 Artifacts sent: 0 received: 0
Error: Database error: unable to open database file: {CREATE TEMP
TABLE onremote(rid INTEGER PRIMARY KEY);}
This is likely (i'm speculating!) a chroot-related problem, because (A) root
has (at the OS level) no permissions restrictions and (B) fossil always
chroot's when run as root.
We recently had a bug where the current dir was
not being properly determined in a chroot case, and maybe (again,
speculating) there's a similar case which only triggers in this setup.
(Remember that fossil does not know about OS-level users, with the single
exception of the root user.)
Alright... I did not realise or forgot about always chrooting.
If anyone wants to pick this up, I would be happy to test/try. I'm
assuming it is easy to reproduce, although 'f_f' and 'r_w' were actual
repos here. (My issue here is long gone, mind - this was caused by
FTP'd repos.)
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] question about parms and ownership of repo vs current/parent dir
On Thu, May 29, 2014 at 9:57 AM, Stephan Beal sgb...@googlemail.com wrote: (B) fossil always chroot's when run as root. That sounds right to me. Running Fossil as root causes a chroot and /var/tmp does not exist inside the chroot jail. -- 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] question about parms and ownership of repo vs current/parent dir
On Thu, May 29, 2014 at 4:11 PM, Richard Hipp d...@sqlite.org wrote: On Thu, May 29, 2014 at 9:57 AM, Stephan Beal sgb...@googlemail.com wrote: (B) fossil always chroot's when run as root. That sounds right to me. Running Fossil as root causes a chroot and /var/tmp does not exist inside the chroot jail. In this case, both syncs were run as root from the same dir, but the owner of the repo is different in each. i don't remember ever seeing code which uses file-level ownership to determine who is who, so i'm at a loss to explain the behaviour difference. -- - 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] question about parms and ownership of repo vs current/parent dir
Thus said Michai Ramakers on Thu, 29 May 2014 15:35:37 +0200: root@main:/tmp/ftmp# ls -ld * . drwxr-xr-x 2 root wheel 512 May 29 15:32 . -rw-r--r-- 1 ftp ftp3435520 May 29 15:32 f_f -rw-r--r-- 1 root wheel 3592192 May 29 15:32 r_w root@main:/tmp/ftmp# f sync r_w -R f_f When you run as root, it will drop privileges to the user that owns the named repository. I suspect that in this case, f_f is owned by ftp, so it drops privileges to ftp but then is unable to write to r_w. I could be wrong, but one thing you could try to verify is: chown ftp.ftp r_w f sync r_w -R f_f Andy -- TAI64 timestamp: 400053874612 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Autosync retry?
Hello, I introduced some code on the autosync-tries branch that causes autosync to retry if it fails, up to a maximum of 3 tries. 1) Should autosync retry? 2) Should the number of tries be configurable? I would like to either merge or abandon, but would like some additional feedback first. Here are the current changes: http://www.fossil-scm.org/index.html/vdiff?from=8a5f192b40401748to=9f33dbae40a02321sbs=1 Thanks, Andy -- TAI64 timestamp: 40005387487e ___ 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] Autosync retry?
On Thu, May 29, 2014 at 4:53 PM, Richard Hipp d...@sqlite.org wrote: On Thu, May 29, 2014 at 10:46 AM, Andy Bradford amb-fos...@bradfords.org wrote: 1) Should autosync retry? In my experience, autosync only fails when WIFI is down (or turned off). Retries won't help that. It just takes longer to finish. Maybe instead of autosync being a toggle... autosync 0 == off 1 == current behaviour 2+ == retry up to N-1 times or some such? -- - 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] question about parms and ownership of repo vs current/parent dir
On 29 May 2014 16:36, Andy Bradford amb-sendok-1403966191.gpijlhaollnogheom...@bradfords.org wrote: Thus said Michai Ramakers on Thu, 29 May 2014 15:35:37 +0200: root@main:/tmp/ftmp# ls -ld * . drwxr-xr-x 2 root wheel 512 May 29 15:32 . -rw-r--r-- 1 ftp ftp3435520 May 29 15:32 f_f -rw-r--r-- 1 root wheel 3592192 May 29 15:32 r_w root@main:/tmp/ftmp# f sync r_w -R f_f When you run as root, it will drop privileges to the user that owns the named repository. I suspect that in this case, f_f is owned by ftp, so it drops privileges to ftp but then is unable to write to r_w. I could be wrong, but one thing you could try to verify is: chown ftp.ftp r_w f sync r_w -R f_f In case both files are owned ftp.ftp and their parent-dir is owned root.wheel, sync either way gives an error (instead of just 1 error in the pasted shell dialog.) In case both files as well as their parent-dir are owned ftp.ftp, both syncs work fine. 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] question about parms and ownership of repo vs current/parent dir
On Thu, May 29, 2014 at 5:08 PM, Michai Ramakers m.ramak...@gmail.com
wrote:
In case both files as well as their parent-dir are owned ftp.ftp, both
syncs work fine.
If fossil drops permissions as Andy suggests (i'm still trying to find the
relevant code, but have no reason to believe he's wrong), then that's the
problem. It would go something like this:
chroot to /tmp/...
switch user to ftp
try to create a temp file somewhere under the new root
== no rights
Ah, here it is:
** If running as root, chroot to the directory containing the
** repository zRepo and then drop root privileges. Return the
** new repository name.
**
if( stat(zRepo, sStat)!=0 ){
fossil_fatal(cannot stat() repository: %s, zRepo);
}
i = setgid(sStat.st_gid);
i = i || setuid(sStat.st_uid);
sure enough. It switches back to the owning user/group of the repo.
IMO, that's not a bug, just an unfortunate side effect of your setup.
--
- 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] question about parms and ownership of repo vs current/parent dir
On 29 May 2014 17:08, Michai Ramakers m.ramak...@gmail.com wrote: On 29 May 2014 16:36, Andy Bradford amb-sendok-1403966191.gpijlhaollnogheom...@bradfords.org wrote: Thus said Michai Ramakers on Thu, 29 May 2014 15:35:37 +0200: ... I could be wrong, but one thing you could try to verify is: chown ftp.ftp r_w f sync r_w -R f_f In case both files are owned ftp.ftp and their parent-dir is owned root.wheel, sync either way gives an error (instead of just 1 error in the pasted shell dialog.) In case both files as well as their parent-dir are owned ftp.ftp, both syncs work fine. And... if one of the files is owned root.wheel, and the other file as well as their parent-dir is owned ftp.ftp, both syncs works fine. 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] Autosync retry?
On Thu, May 29, 2014 at 10:46 AM, Andy Bradford amb-fos...@bradfords.org wrote: Hello, I introduced some code on the autosync-tries branch that causes autosync to retry if it fails, up to a maximum of 3 tries. 1) Should autosync retry? In my experience, autosync only fails when WIFI is down (or turned off). Retries won't help that. It just takes longer to finish. 2) Should the number of tries be configurable? I would like to either merge or abandon, but would like some additional feedback first. Here are the current changes: http://www.fossil-scm.org/index.html/vdiff?from=8a5f192b40401748to=9f33dbae40a02321sbs=1 Thanks, Andy -- TAI64 timestamp: 40005387487e ___ 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
Re: [fossil-users] question about parms and ownership of repo vs current/parent dir
On 29 May 2014 17:12, Stephan Beal sgb...@googlemail.com wrote:
On Thu, May 29, 2014 at 5:08 PM, Michai Ramakers m.ramak...@gmail.com
wrote:
In case both files as well as their parent-dir are owned ftp.ftp, both
syncs work fine.
If fossil drops permissions as Andy suggests (i'm still trying to find the
relevant code, but have no reason to believe he's wrong), then that's the
problem. It would go something like this:
chroot to /tmp/...
switch user to ftp
try to create a temp file somewhere under the new root
== no rights
Ah, here it is:
** If running as root, chroot to the directory containing the
** repository zRepo and then drop root privileges. Return the
** new repository name.
**
if( stat(zRepo, sStat)!=0 ){
fossil_fatal(cannot stat() repository: %s, zRepo);
}
i = setgid(sStat.st_gid);
i = i || setuid(sStat.st_uid);
sure enough. It switches back to the owning user/group of the repo.
IMO, that's not a bug, just an unfortunate side effect of your setup.
Alright, thanks for looking into this (, all).
Does this also explain my last mail (in case one file is owned
root.wheel, and the other file and parent-dir are owned ftp.ftp, all
works fine)?
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] question about parms and ownership of repo vs current/parent dir
On Thu, May 29, 2014 at 11:12 AM, Stephan Beal sgb...@googlemail.com wrote: On Thu, May 29, 2014 at 5:08 PM, Michai Ramakers m.ramak...@gmail.com wrote: In case both files as well as their parent-dir are owned ftp.ftp, both syncs work fine. If fossil drops permissions as Andy suggests (i'm still trying to find the relevant code, but have no reason to believe he's wrong), then that's the problem. To find the code: grep for setuid. Fossil does drop permissions back to an unprivileged user when running as root. This is a security feature, to prevent a bug in Fossil from providing root shell access to an attacker. Also, root can break out of a chroot jail, so the chroot jail is only effective for normal 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
Re: [fossil-users] Autosync retry?
I'd rather autosync remained a toggle (indicating whether work is local or not). A separate setting for number of retries seems reasonable. On Thu, May 29, 2014 at 3:56 PM, Stephan Beal sgb...@googlemail.com wrote: On Thu, May 29, 2014 at 4:53 PM, Richard Hipp d...@sqlite.org wrote: On Thu, May 29, 2014 at 10:46 AM, Andy Bradford amb-fos...@bradfords.org wrote: 1) Should autosync retry? In my experience, autosync only fails when WIFI is down (or turned off). Retries won't help that. It just takes longer to finish. Maybe instead of autosync being a toggle... autosync 0 == off 1 == current behaviour 2+ == retry up to N-1 times or some such? -- - 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 ___ 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] Autosync retry?
Thus said Richard Hipp on Thu, 29 May 2014 10:53:57 -0400: In my experience, autosync only fails when WIFI is down (or turned off). Retries won't help that. It just takes longer to finish. I agree that for network related failures, retry won't help. Others have reported non-network related failures (primarily due to locking or other similar problems). Perhaps if we make the default to be 1 sync but then add a settting that governs the number of attempts when it fails? Thanks, Andy -- TAI64 timestamp: 400053875485 ___ 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] question about parms and ownership of repo vs current/parent dir
Thus said Michai Ramakers on Thu, 29 May 2014 17:08:52 +0200: In case both files as well as their parent-dir are owned ftp.ftp, both syncs work fine. Sounds like a simple case of permissions problems to me. The user that is running the sync must have sufficient Unix filesystem privileges to be able to write to the fossil. If you run as root, the privileges will drop to the owner of the fossil. At that point, whatever that user can do should be doable, but if the directory is not writable by that user, then fossil will not be able to write to the fossil repo. Andy ___ 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] question about parms and ownership of repo vs current/parent dir
Thus said Stephan Beal on Thu, 29 May 2014 17:12:35 +0200: i = setgid(sStat.st_gid); i = i || setuid(sStat.st_uid); sure enough. It switches back to the owning user/group of the repo. IMO, that's not a bug, just an unfortunate side effect of your setup. In fact, it's intended behavior when running as root: https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg01486.html Andy -- TAI64 timestamp: 40005387560c ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] permissions / running as root
Hello, [ re recent post about running as root / file-permissions/-ownership / chroot ] just ran into another thing having to do with permissions - naturally caused by myself as well. (Running as root, working with repo containing system-config in /etc and so forth.) Come to think of it, quite a few issues I have with fossil turn out to be permission-related. And they are always solved fairly quick, with or without suggestions from the list. However... is it an idea to at least hint at at permissions being the cause of an error, if it is clear at that point in code? (Errors like the one given in my example-snippet are not always clear to me.) 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] question about parms and ownership of repo vs current/parent dir
On Thu, May 29, 2014 at 5:22 PM, Michai Ramakers m.ramak...@gmail.com wrote: Does this also explain my last mail (in case one file is owned root.wheel, and the other file and parent-dir are owned ftp.ftp, all works fine)? Yes - because the file is owned by root, the dropping of privileges is actually a no-op, in that we're dropping back from root to root. At least that's my understanding of the code. -- - 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] Autosync retry?
Retry on autosync would be a big help in my environment. Autosync failures due to overlapping access are a regular and annoying occurrence. I like Stephan's approach of 0, 1, N for off, on, multi-try On Thu, May 29, 2014 at 8:49 AM, Andy Bradford amb-fos...@bradfords.orgwrote: Thus said Marc Simpson on Thu, 29 May 2014 16:35:50 +0100: I'd rather autosync remained a toggle (indicating whether work is local or not). A separate setting for number of retries seems reasonable. Well, strictly speaking, autosync isn't a toggle, it can also be set to ``pull-only'' :-) But I am of the opinion that autosync-tries should be a separate setting. Andy -- TAI64 timestamp: 400053875710 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ 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] permissions / running as root
On Thu, May 29, 2014 at 5:45 PM, Michai Ramakers m.ramak...@gmail.com
wrote:
However... is it an idea to at least hint at at permissions being the
cause of an error, if it is clear at that point in code? (Errors like
the one given in my example-snippet are not always clear to me.)
In fact, you hinted at the problem being potentially permissions-related in
your first post:
In short, syncing with repo seems to work or not depending of
perms/ownership of that repo:
;)
This level of error:
Error: Database error: unable to open database file: {CREATE TEMP
TABLE onremote(rid INTEGER PRIMARY KEY);}
That happens one level below fossil (in sqlite), and (A) i'm not certain
fossil could recognize it as a permissions problem and (B) the vast, vast
majority of fossil's internals will exit() on any sort of error, which
could lead to the exit() happening in before the code which triggers the
error has a chance to evaluate the error code. Fossil's fail-fast approach
greatly simplifies writing higher-level bits, but also makes it (at times)
impossible (without bypassing the internal APIs) to detect the exact nature
of the error.
--
- 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] Autosync retry?
On Thu, May 29, 2014 at 6:00 PM, Matt Welland estifo...@gmail.com wrote: Retry on autosync would be a big help in my environment. Autosync failures due to overlapping access are a regular and annoying occurrence. I like Stephan's approach of 0, 1, N for off, on, multi-try That could also (more simply, i think) be interpreted as: 0 == off 1+ == number of times to try -- - 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] permissions / running as root
On 29 May 2014 18:05, Stephan Beal sgb...@googlemail.com wrote:
On Thu, May 29, 2014 at 5:45 PM, Michai Ramakers m.ramak...@gmail.com
wrote:
However... is it an idea to at least hint at at permissions being the
cause of an error, if it is clear at that point in code? (Errors like
the one given in my example-snippet are not always clear to me.)
In fact, you hinted at the problem being potentially permissions-related in
your first post:
In short, syncing with repo seems to work or not depending of
perms/ownership of that repo:
;)
I had to laugh a bit, thank you. (My post was after headscratching and
trying this and that.)
This level of error:
Error: Database error: unable to open database file: {CREATE TEMP
TABLE onremote(rid INTEGER PRIMARY KEY);}
That happens one level below fossil (in sqlite), and (A) i'm not certain
fossil could recognize it as a permissions problem and (B) the vast, vast
majority of fossil's internals will exit() on any sort of error, which could
lead to the exit() happening in before the code which triggers the error has
a chance to evaluate the error code. Fossil's fail-fast approach greatly
simplifies writing higher-level bits, but also makes it (at times)
impossible (without bypassing the internal APIs) to detect the exact nature
of the error.
Right - that's clear, thanks. This is not a big issue and indeed
eventually always gets solved. Just something new users may encounter.
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] permissions / running as root
On Thu, May 29, 2014 at 6:22 PM, Michai Ramakers m.ramak...@gmail.com wrote: Right - that's clear, thanks. This is not a big issue and indeed eventually always gets solved. Just something new users may encounter. i agree, i just don't see a way to do this consistently (for all commands) in the current code base because the bits which trigger such errors will normally cause fossil to exit before the command-level code could tell the user hey, this might be due to a permissions problem. -- - 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
[fossil-users] libfossil minor milestone: Raspberry Pi
Hi, all, after fixing some bits which assumed too much about the signedness of the (char) data type, libfossil now builds (slowly!) and runs (slowly!) on Raspbian OS on Raspberry Pi hardware. As a comparison of runtime speeds, here's the results of the core sanity tests on my workstation (a (very loud) Sony Vaio laptop): ... If you made it this far, no assertions were triggered. Now try again with valgrind. Total run time: 0.165307 seconds of CPU time Compared to the Pi, running on an external USB drive (as opposed to the SD card): Total run time: 6.88 seconds of CPU time The Pi is not fast, but it's really, really, really quiet (no noise whatsoever). Happy Fossiling! -- - 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
[fossil-users] encrypted repos?
Hello, I am planning to keep backups of my fossil repos on a remote site, where I have SSH access. What I would like, is to have at least some way of encryption used on the resulting remote repo-files (assuming 'fossil sync' is used as backup method), in case the remote machine gets stolen, say. What would work is choose something other than 'fossil sync' to backup, encrypt repos locally and then transfer them, but some of these are fairly large (~ 1 GB) and have small but frequent changes, which would probably result in a very different encrypted repo-file. Does anyone have an idea how to do this in a sane way? Fossil's own sync mechanism is very nice, and if possible I would like to use it. Right now I'm thinking of a loopback-mounted encrypted filesystem in a big file on the remote side, but likely there are better ideas out there. (Summary: it's not the connection itself that needs encrypting - that's what SSH does fine - but rather the storage.) 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] encrypted repos?
On 29 May 2014 20:40, Richard Hipp d...@sqlite.org wrote: On Thu, May 29, 2014 at 2:36 PM, Michai Ramakers m.ramak...@gmail.com wrote: ... What would work is choose something other than 'fossil sync' to backup, encrypt repos locally and then transfer them, but some of these are fairly large (~ 1 GB) and have small but frequent changes, which would probably result in a very different encrypted repo-file. Large sections of the repository file likely remain unchanged, even with frequent updates. (Running fossil rebuild is a different story, of course.) So you should be able to encrypt a copy of the repo locally, then rsync it to the remote location. Ok, that's worth a try and probably the simplest, thanks. I was thinking the resulting encrypted repo would change a lot, when only certain blocks in the unencrypted repo change. Would this not be so? 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] encrypted repos?
On Thu, May 29, 2014 at 2:52 PM, Michai Ramakers m.ramak...@gmail.com wrote: I was thinking the resulting encrypted repo would change a lot, when only certain blocks in the unencrypted repo change. Would this not be so? I suppose that depends on what software you use to do the encryption. -- 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] encrypted repos?
On Thu, May 29, 2014 at 2:52 PM, Michai Ramakers m.ramak...@gmail.com wrote: I was thinking the resulting encrypted repo would change a lot, when only certain blocks in the unencrypted repo change. Would this not be so? When encrypting the file, you should be doing the encryption in CBC mode. In that case, any change will affect all the subsequent cipher text. In fact, each time you encrypt, you should use a different Initialization Vector (IV), which will result in the entire cipher text being different. It is possible to encrypting using ECB mode, which will only affect the cipher text around each change, but is extremely insecure. Counter Mode is another option, but is still very insecure. ___ 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] question about parms and ownership of repo vs current/parent dir
Thus said Michai Ramakers on Thu, 29 May 2014 17:22:08 +0200: Alright, thanks for looking into this (, all). Does this also explain my last mail (in case one file is owned root.wheel, and the other file and parent-dir are owned ftp.ftp, all works fine)? I may have mispoken earlier. Fossil only does chroot and drop privileges when serving files (e.g. fossil server), however, the email you originally sent was simply a ``fossil sync'' operation from one local file to another. You also mentioned that you became root by doing su. Perhaps there is something more in the way you are doing things that has been missed. Clearly there is a permission problem, so maybe my claim that it was due to chroot/privilege dropping was premature. This might require additional information/investigation. Andy -- TAI64 timestamp: 400053878bbd ___ 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] Autosync retry?
Thus said Stephan Beal on Thu, 29 May 2014 18:06:49 +0200: That could also (more simply, i think) be interpreted as: 0 == off 1+ == number of times to try I'm a bit confused, however, in how 0 and 1 should be interpreted... Given that Fossil currently does 1 autosync attempt: Does 0 mean no autosync attempts (seem that's the purpose of the current autosync setting)? Or does it mean the current behavior of 1 attempt? Furthermore, does 1 mean 1 more than the current behavior of 1 autosync attempt? Thanks, Andy -- TAI64 timestamp: 400053878cb7 ___ 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] Autosync retry?
0 means no autosync, 1 means one attempt (same as now), 2+ means retry N times. But because there really is no difference between try and retry, 1+ is the same logic: For(i=0; i N; ++i) attempt to sync, break on success. (sent from a mobile device - please excuse brevity, typos, and top-posting) - stephan beal http://wanderinghorse.net On May 29, 2014 9:38 PM, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Stephan Beal on Thu, 29 May 2014 18:06:49 +0200: That could also (more simply, i think) be interpreted as: 0 == off 1+ == number of times to try I'm a bit confused, however, in how 0 and 1 should be interpreted... Given that Fossil currently does 1 autosync attempt: Does 0 mean no autosync attempts (seem that's the purpose of the current autosync setting)? Or does it mean the current behavior of 1 attempt? Furthermore, does 1 mean 1 more than the current behavior of 1 autosync attempt? Thanks, Andy -- TAI64 timestamp: 400053878cb7 ___ 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] Autosync retry?
Thus said Stephan Beal on Thu, 29 May 2014 21:44:12 +0200: 0 means no autosync, 1 means one attempt (same as now), 2+ means retry N times. But because there really is no difference between try and retry, 1+ is the same logic: I assume we're talking about a different setting than the current autosync setting because I might want to have autosync try multiple times *and* have it set to pull-only. Given this, if autosync is on (or pull-only) and autosync-tries is 0, does that mean autosync does not happen? Effectively making 2 ways to express the desire to have autosync off. Or should autosync-tries be ignored if 0 (e.g. just use the current behavior)? Thanks, Andy -- TAI64 timestamp: 400053878fe0 ___ 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] Autosync retry?
Wasn't even aware of pull-only until earlier today. i am completely ambivalent on the topic - never had any problems with autosync - this was just what came to mind when you posted. Seemed easier than adding a new option, but was not aware of the pull-only feature (so a second option might be simpler). (sent from a mobile device - please excuse brevity, typos, and top-posting) - stephan beal http://wanderinghorse.net On May 29, 2014 9:51 PM, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Stephan Beal on Thu, 29 May 2014 21:44:12 +0200: 0 means no autosync, 1 means one attempt (same as now), 2+ means retry N times. But because there really is no difference between try and retry, 1+ is the same logic: I assume we're talking about a different setting than the current autosync setting because I might want to have autosync try multiple times *and* have it set to pull-only. Given this, if autosync is on (or pull-only) and autosync-tries is 0, does that mean autosync does not happen? Effectively making 2 ways to express the desire to have autosync off. Or should autosync-tries be ignored if 0 (e.g. just use the current behavior)? Thanks, Andy -- TAI64 timestamp: 400053878fe0 ___ 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] Autosync retry?
On Thu, May 29, 2014 at 11:38 AM, Andy Bradford amb-fos...@bradfords.org wrote: I agree that for network related failures, retry won't help. Others have reported non-network related failures (primarily due to locking or other similar problems). Intermittent network failures can be a problem.So, when I'm not at the office, I usually turn off auto sync and run a sync script that tries the sync 5 times, wating a minute between tries. This usually works, but is rather slow. (Besides the office, my work involves hands on time in various labs and manufacturing facilities that are electrically noisy. (The machinery is connected to an ethernet that has no connection to even the company intranet, let alone the internet)) ___ 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] libfossil minor milestone: Raspberry Pi
On 5/29/2014 10:57, Stephan Beal wrote: after fixing some bits which assumed too much about the signedness of the (char) data type, PowerPC does some strange things with char, too. You might have fixed that in passing. As a comparison of runtime speeds, here's the results of the core sanity tests on my workstation How much work does this test do compared to normal user operations? Say, a normal checkin, or a pull of the /tree URL from fossil server? You show a ~42x speed difference, but if a normal user operation takes 1 ms to process on a fast PC, it'll still take an [insignificant][1] amount of time on a Pi. A Pi really isn't all that slow, in historical terms. It's only about 10 years behind the times, in terms of raw horsepower. Raspbian comes with Mathematica after all, and it runs reasonably well under X. The Pi is not fast, but it's really, really, really quiet (no noise whatsoever). Yeah, plug the headphone port into a power amplifier and get back to me about no noise whatsoever. ;) A Pi is fanless because your laptop draws about 10x more power than the Pi, and most power that goes into a computer gets turned into heat. Where I live, a continuously running server costs [around $1/W/yr][2]. Dropping from 20-30 W to 2-3 W pays for the Pi in ~2 years. If your Fossil server is a disused desktop PC instead, moving your repo to a Pi pays off in months. [1]: A human's think-then-react time is around 100 ms. Anything faster than that that is instant to a person in any context that requires thought. Humans can do some things faster -- typing, playing sports, flinching... -- but only by instinct or long training. [2]: It costs less in winter where the heat produced reduces the heating bill, but doubles in summer where every watt produced has to be removed by the AC system. ___ 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] Autosync retry?
Thus said Stephan Beal on Thu, 29 May 2014 22:10:24 +0200: Wasn't even aware of pull-only until earlier today. i am completely ambivalent on the topic - never had any problems with autosync - this was just what came to mind when you posted. Seemed easier than adding a new option, but was not aware of the pull-only feature (so a second option might be simpler). Actually, I thought it was a great idea except that it conflicted with pull-only. I agree that it will be simpler as a separate setting: http://www.fossil-scm.org/index.html/info/7653ab63420e4ab4ca6372a53de9314a18e1b946 It will default to 1 so it retains the same behavior as Fossil without the setting. Setting it greater than 1 allows those who want Fossil to try harder to get more tries. Autosync (on/off) itself is still governed by the autosync setting. Andy -- TAI64 timestamp: 40005387fc6d ___ 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] Autosync retry?
I was going to +1 sbeals idea, but the pull-only autosync note came up, and now I think I may not know all there is about autosync. Thanks for keeping it interesting, folks. On May 29, 2014 8:34 PM, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Stephan Beal on Thu, 29 May 2014 22:10:24 +0200: Wasn't even aware of pull-only until earlier today. i am completely ambivalent on the topic - never had any problems with autosync - this was just what came to mind when you posted. Seemed easier than adding a new option, but was not aware of the pull-only feature (so a second option might be simpler). Actually, I thought it was a great idea except that it conflicted with pull-only. I agree that it will be simpler as a separate setting: http://www.fossil-scm.org/index.html/info/7653ab63420e4ab4ca6372a53de9314a18e1b946 It will default to 1 so it retains the same behavior as Fossil without the setting. Setting it greater than 1 allows those who want Fossil to try harder to get more tries. Autosync (on/off) itself is still governed by the autosync setting. Andy -- TAI64 timestamp: 40005387fc6d ___ 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
