Re: [fossil-users] /dev/null and /dev/urandom not available ?

2017-05-13 Thread Richard Hipp
On 5/13/17, Olivier R.  wrote:
> Hello,
>
> I’m running Fossil on Debian Jessie 8.2
> (x86_64-debian-jessie-2016-04-06_15:26) at Scaleway.com (VC1S).
>
> In the admin panel, Fossil says:
>
>WARNING: Device "/dev/null" is not available for reading and writing.
>WARNING: Device "/dev/urandom" is not available for reading. This
> means that the pseudo-random number generator used by SQLite will be
> poorly seeded.
>
> fossil is in usr/bin.
> repo.fossil is in /root/repo.
>
> To launch the server, I simply type:
>
>fossil open repo.fossil
>nohup fossil server &

Are you running the commands above as root?  If so, Fossil will
automatically put itself in a chroot jail on the directory containing
the repository and drop root privileges before doing anything else.
This is a security feature.

If you are going into a chroot jail, probably /dev/null and
/dev/urandom are no longer in that chroot jail.  You can fix that by
running:

   mkdir dev
   mknod dev/null c 1 3
   mknod dev/urandom c 1 9

See also the "managing server load" heading of
http://fossil-scm.org/fossil/doc/trunk/www/server.wiki where it talks
about the importance of making /proc available inside the chroot jail
so that Fossil can determine the load average.

Or, you can use the --nojail option on the "fossil server" command, in
which case Fossil will still drop its root privilege but will not
attempt to form a chroot jail.  This is less secure, but probably
still plenty safe.



>
> In /dev, there is:
>
>crw-rw-rw- 1 root root 1, 3 Apr 8 2016 null
>crw-rw-rw- 1 root root 1, 9 Apr 8 2016 urandom
>
>
> If I clone the repository, modify something, commit the modification,
> fossil says when trying to sync:
>
>Autosync:  http://xxx.xxx.xxx.xxx:8080
>Round-trips: 1  Artifacts sent: 0  received: 0
>Pull done, sent: 312  received: 328  ip: xxx.xxx.xxx.xxx
>New_Version: _hash_code_x
>Autosync:  http://xxx.xxx.xxx.xxx:8080
>Round-trips: 1  Artifacts sent: 2  received: 0
>Error: not authorized to write
>Round-trips: 1  Artifacts sent: 2  received: 0
>Sync done, sent: 759  received: 355  ip: xxx.xxx.xxx.xxx
>Autosync failed.
>
> The repository has not been updated.
>
> How to solve these problems?
>
> Olivier
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


[fossil-users] /dev/null and /dev/urandom not available ?

2017-05-13 Thread Olivier R.

Hello,

I’m running Fossil on Debian Jessie 8.2 
(x86_64-debian-jessie-2016-04-06_15:26) at Scaleway.com (VC1S).


In the admin panel, Fossil says:

  WARNING: Device "/dev/null" is not available for reading and writing.
  WARNING: Device "/dev/urandom" is not available for reading. This 
means that the pseudo-random number generator used by SQLite will be 
poorly seeded.


fossil is in usr/bin.
repo.fossil is in /root/repo.

To launch the server, I simply type:

  fossil open repo.fossil
  nohup fossil server &

In /dev, there is:

  crw-rw-rw- 1 root root 1, 3 Apr 8 2016 null
  crw-rw-rw- 1 root root 1, 9 Apr 8 2016 urandom


If I clone the repository, modify something, commit the modification, 
fossil says when trying to sync:


  Autosync:  http://xxx.xxx.xxx.xxx:8080
  Round-trips: 1  Artifacts sent: 0  received: 0
  Pull done, sent: 312  received: 328  ip: xxx.xxx.xxx.xxx
  New_Version: _hash_code_x
  Autosync:  http://xxx.xxx.xxx.xxx:8080
  Round-trips: 1  Artifacts sent: 2  received: 0
  Error: not authorized to write
  Round-trips: 1  Artifacts sent: 2  received: 0
  Sync done, sent: 759  received: 355  ip: xxx.xxx.xxx.xxx
  Autosync failed.

The repository has not been updated.

How to solve these problems?

Olivier
___
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] Problem with: fossil revert -r xxx

2017-05-13 Thread Ron Aaron

  
  
On 11/05/2017 16:14, Richard Hipp wrote:


  On 5/10/17, Ron Aaron  wrote:

  
I tried to revert to a good revision 'xxx' using "fossil revert -r xxx"

Despite the help stating "Revert all files if no file name is provided",
instead fossil told me, "the --revision option does not work for the
entire tree".

  
  
Amid all the confusion, I'm not sure this question was ever answered.
So let me now try...

The "fossil revert" command is intended to undo edits to the local
check-out and restore the content of files back to the last committed
version.  For example, you start making some change and decide that
your idea isn't really working out, so you type "fossil revert" to
take you back to a pristine state.  Or you do "fossil revert
$filename" to undo all of the local edits for a particular file while
retaining the edits to other files.

The "fossil revert" command only affects the local check-out.  It
makes no changes to the repository.

If you want to move your whole check-out to a different baseline,
better to do so using:

 fossil revert
 fossil update $newbaseline

If you want to change a single file to be the same as it was several
check-ins ago, better to do something like this:

My desire was to have the effect of "merge --backout"
  of all the revisions back to a given one.  Perhaps it would be
  possible to add "merge --backout-all" or something similar, to
  have that effect?


  

___
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] /dev/null and /dev/urandom not available ?

2017-05-13 Thread Olivier R.

Thanks.

Olivier


Are you running the commands above as root?  If so, Fossil will
automatically put itself in a chroot jail on the directory containing
the repository and drop root privileges before doing anything else.
This is a security feature.

If you are going into a chroot jail, probably /dev/null and
/dev/urandom are no longer in that chroot jail.  You can fix that by
running:

mkdir dev
mknod dev/null c 1 3
mknod dev/urandom c 1 9

See also the "managing server load" heading of
http://fossil-scm.org/fossil/doc/trunk/www/server.wiki where it talks
about the importance of making /proc available inside the chroot jail
so that Fossil can determine the load average.

Or, you can use the --nojail option on the "fossil server" command, in
which case Fossil will still drop its root privilege but will not
attempt to form a chroot jail.  This is less secure, but probably
still plenty safe.


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users