sqlite[S8]: attempt to write a readonly database
Hi,
I am *very* new to svn. I just set up a server (svnserve, version 1.8.14
(r1692801)) on OpenBSD-5.8.
(See http://daemonforums.org/showpost.php?p=58638&postcount=2).
The repository was created with: doas -u _svn svnadmin create /var/svn/project-A
The server runs as: doas -u _svn svnserve -d -r /var/svn
Directories were created with: svn mkdir
svn://minerva.bohemia.net/project-A/{trunk,tags,branches}
Then I did an: svn checkout svn://minerva.bohemia.net/project-A
I copied some files into the new ~/project-A/trunk
Then from ~/project-A/trunk:
svn import bin svn://minerva.bohemia.net/project-A/trunk/bin
Authentication realm: minerva.bohemia.net
Password for 'hanzer': **
Adding bin/foo.tcl
Adding bin/getem.tcl
Adding bin/update_db.tcl
Committed revision 5.
Warning: post commit FS processing had error:
sqlite[S8]: attempt to write a readonly database
Is this a known problem? I see rep-cache.db might be the problem:
ls -la /var/svn/project-A/db
total 72
drwxr-sr-x 6 _svn _svn 512 Apr 10 13:10 ./
drwxr-xr-x 6 _svn _svn 512 Apr 9 17:35 ../
-rw-r--r-- 1 _svn _svn 2 Apr 10 13:10 current
-r--r--r-- 1 _svn _svn22 Apr 9 17:35 format
-rw-r--r-- 1 _svn _svn 5 Apr 9 17:35 fs-type
-rw-r--r-- 1 _svn _svn 6838 Apr 9 17:35 fsfs.conf
-rw-r--r-- 1 _svn _svn 2 Apr 9 17:35 min-unpacked-rev
-rw-r--r-- 1 root _svn 3072 Apr 9 17:56 rep-cache.db
drwxr-xr-x 3 _svn _svn 512 Apr 9 17:35 revprops/
drwxr-xr-x 3 _svn _svn 512 Apr 9 17:35 revs/
drwxr-xr-x 2 _svn _svn 512 Apr 10 13:10 transactions/
-rw-r--r-- 1 _svn _svn 2 Apr 10 13:10 txn-current
-rw-r--r-- 1 _svn _svn 0 Apr 9 17:35 txn-current-lock
drwxr-xr-x 2 _svn _svn 512 Apr 10 13:10 txn-protorevs/
-rw-r--r-- 1 _svn _svn37 Apr 9 17:35 uuid
-rw-r--r-- 1 _svn _svn 0 Apr 9 17:35 write-lock
But those permissions were set up automatically by svn. Is it a reasonable fix
to just manually change rep-cache.db permissions or ownership? Or did I make a
mistake when setting up the environment?
Re: sqlite[S8]: attempt to write a readonly database
On Sun, 10 Apr 2016 14:36:09 -0700
Joseph Bruni wrote:
> rep-cache couldn't be owned by root unless svnserve was running as root at
> the time it was last modified. You can change permissions to be correct, but
> there is some reason root was the UID at the time it was created. I'm not
> familiar with doas. I'm guessing it is similar to sudo? Maybe doas changes
> effective UID at odd times?
Thanks for the sanity check, it looks like I might have botched something early
in the repository creation. My bad (It was my first time ;)
To verify (with svnserve running as user _svn):
doas -u _svn svnadmin create /var/svn/project-C
doas -u _svn vi /var/svn/project-C/conf/svnserve.conf
[general]
anon-access = none
auth-access = write
realm = minerva.bohemia.net
[sasl]
use-sasl = true
min-encryption = 128
max-encryption = 256
svn mkdir svn://minerva.bohemia.net/project-C/{trunk,tags,branches}
svn checkout svn://minerva.bohemia.net/project-C
Authentication realm: minerva.bohemia.net
Password for 'hanzer': **
Aproject-C/tags
Aproject-C/trunk
Aproject-C/branches
Checked out revision 1.
cd project-C/trunk
touch foo
svn add foo
svn commit
Authentication realm: minerva.bohemia.net
Password for 'hanzer': **
Adding foo
Transmitting file data .
Committed revision 2.
ls -la /var/svn/project-C/db
total 72
drwxr-sr-x 6 _svn _svn 512 Apr 10 17:51 ./
drwxr-xr-x 6 _svn _svn 512 Apr 10 17:48 ../
-rw-r--r-- 1 _svn _svn 2 Apr 10 17:51 current
-r--r--r-- 1 _svn _svn22 Apr 10 17:48 format
-rw-r--r-- 1 _svn _svn 5 Apr 10 17:48 fs-type
-rw-r--r-- 1 _svn _svn 6838 Apr 10 17:48 fsfs.conf
-rw-r--r-- 1 _svn _svn 2 Apr 10 17:48 min-unpacked-rev
-rw-r--r-- 1 _svn _svn 3072 Apr 10 17:51 rep-cache.db
drwxr-xr-x 3 _svn _svn 512 Apr 10 17:48 revprops/
drwxr-xr-x 3 _svn _svn 512 Apr 10 17:48 revs/
drwxr-xr-x 2 _svn _svn 512 Apr 10 17:51 transactions/
-rw-r--r-- 1 _svn _svn 2 Apr 10 17:51 txn-current
-rw-r--r-- 1 _svn _svn 0 Apr 10 17:48 txn-current-lock
drwxr-xr-x 2 _svn _svn 512 Apr 10 17:51 txn-protorevs/
-rw-r--r-- 1 _svn _svn37 Apr 10 17:48 uuid
-rw-r--r-- 1 _svn _svn 0 Apr 10 17:48 write-lock
All is good. Thanks!
BTW - doas is a very simple replacement for sudo.
https://news.ycombinator.com/item?id=9914693
A couple thousand mp3 files (this is not spam I swear )
Hi,
I am considering a use of Subversion as a means to avoid accidentally
deleting some important files that I will be working with on a regular
basis. I am very interested to get comments on my plan or suggestions
for alternative methods.
Here's the situation: I have ~1500 mp3 files (not pirated music), and
the collection is growing. The sizes range from ~100kB to ~300MB. The
content of these files will never change. The directory structure will
change, files will be moved, and new (additional) [mp3] files will be added.
So basically, I am considering the use of Subversion as a live backup of
sorts and a discipline/safety-net to prevent accidental deletion of any
part of a continuously growing data-set while I explore different data
organization and analysis strategies.
My primary concerns are related to any potential file corruption, any
data duplication, and/or any excessive network or disk I/O (other than
the expected load of direct data communication).
Again, any comments on [or analysis of] this plan, or suggestions for
alternatives will be much appreciated!
I sent this text (^above^) to users-subscr...@subversion.apache.org
earlier today assuming that one need not be subscribed to post. This is
a post-subscribe re-post.
{https://subversion.apache.org/mailing-lists.html}::("you don't need to
be subscribed to post")
Re: A couple thousand mp3 files (this is not spam I swear )
On 08/12/2016 08:56 PM, Adam Jensen wrote: > Here's the situation: I have ~1500 mp3 files (not pirated music), and > the collection is growing. The sizes range from ~100kB to ~300MB. The > content of these files will never change. The directory structure will > change, files will be moved, and new (additional) [mp3] files will be added. When a branch is created, are the files under revision control in the trunk copied to the branch (is there any duplication of files in the repository)?
Re: A couple thousand mp3 files (this is not spam I swear )
On 08/13/2016 02:21 PM, David Chapman wrote: > On 8/13/2016 11:07 AM, Adam Jensen wrote: >> When a branch is created, are the files under revision control in the >> trunk copied to the branch (is there any duplication of files in the >> repository)? > > No, the files are not copied; a rename is stored. These are "cheap > copies", and this is an advantage over simple backups - if you want to > save history using backups (per another suggestion), you need to retain > one backup per significant event. That can add up. Thanks! That's a critical issue for my case where there is a large & growing core data-set and where it might be useful to have hundreds of branches, each representing a particular configuration of a subset, slice, or view of the core data-set. > Subversion is most often used to store text files because it stores > intra-file deltas when content is modified. Your use case is unusual, > but as long as you don't make a lot of changes to the binary files, it > will be efficient. Thanks [again] for the [vindicating] confirmation. I am inspired to set up a test case and explore this approach further :) Since, in my case, the binary files should/must never change, is there a way to configure a read-only attribute on specific files in the repository such that any subsequent attempt to check-in a change to any of those files will be rejected and an alert raised? The directory structures should remain changeable.
Re: A couple thousand mp3 files (this is not spam I swear )
On 08/13/2016 05:31 PM, Nico Kadel-Garcia wrote: > Don't hurt yourself getting too clever. And don't forget that once > ingested, Subversion is designed to *never let go* of content. > Deleting any in the master simply won't ever clear the content from > the core repository and its history, *ever*. > > Why do I bring this up? Because if it's MP3's and you discover a > copyright violation, you cannot expunge the content without a *very* > painful dump, iflter, and reload operation on a quite large > repository. The mp3 files, in this case, are indeed audio recordings but they represent an aspect of an expanding instrumentation system that is part of a specific [controlled ownership] environment. I don't think I have overlooked any relevant copyright issues related to the storage of the data. An indelible record is the goal (for now). >> Since, in my case, the binary files should/must never change, is there a >> way to configure a read-only attribute on specific files in the >> repository such that any subsequent attempt to check-in a change to any >> of those files will be rejected and an alert raised? The directory >> structures should remain changeable. > > That's what user privileges in "svnserve.conf" that would provide > "write once" control are designed for. It would *not* prevent > operations on the local file system by an administrator, using > "file:///" based access. I assume that if an admin performs that kind > of access, they mean what they're doing and are aware they're avoiding > the filters. What would an "svnserve.conf" file with "write once" access control look like? The book[1] shows something like this: -- [general] password-db = userfile realm = example realm # anonymous users aren't allowed anon-access = none # authenticated users can both read and write auth-access = write -- [1]: http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.auth.general I intend to host this repository from a FreeBSD-10.3(x86) system where `svnserve --version` is: -- svnserve, version 1.9.4 (r1740329) compiled Jul 28 2016, 02:56:08 on i386-portbld-freebsd10.1 Copyright (C) 2016 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository back-end (FS) modules are available: * fs_fs : Module for working with a plain file (FSFS) repository. * fs_x : Module for working with an experimental (FSX) repository. -- The manual page on that system `man svnserve.conf` describes: auth-access = none|read|write
A couple thousand mp3 files
Hi, I am considering a use of Subversion as a means to avoid accidentally deleting some important files that I will be working with on a regular basis. I am very interested to get comments on my plan or suggestions for alternative methods. Here's the situation: I have ~1500 mp3 files (not pirated music), and the collection is growing. The sizes range from ~100kB to ~300MB. The content of these files will never change. The directory structure will change, files will be moved, and new (additional) [mp3] files will be added. So basically, I am considering the use of Subversion as a live backup of sorts and a discipline/safety-net to prevent accidental deletion of any part of a continuously growing data-set while I explore different data organization and analysis strategies. My primary concerns are related to any potential file corruption, any data duplication, and/or any excessive network or disk I/O (other than the expected load of direct data communication). Again, any comments on [or analysis of] this plan, or suggestions for alternatives will be much appreciated!
Re: A couple thousand mp3 files (this is not spam I swear )
On 08/13/2016 08:09 AM, Branko Čibej wrote:
> On 13.08.2016 02:56, Adam Jensen wrote:
>> I sent this text (^above^) to users-subscr...@subversion.apache.org
>> earlier today assuming that one need not be subscribed to post. This is
>> a post-subscribe re-post.
>>
>> {https://subversion.apache.org/mailing-lists.html}::("you don't need to
>> be subscribed to post")
>
>
> Indeed you don't need to be subscribed to post, but the users-subscribe@
> address doesn't post messages to the users@ list. :)
I think the original message was in fact sent to users@ and the mention
(^above^) of users-subscribe@ was an independent copy and paste error.
The original post just showed up on:
http://mail-archives.apache.org/mod_mbox/subversion-users/201608.mbox/browser
Specifically:
http://mail-archives.apache.org/mod_mbox/subversion-users/201608.mbox/%3C57AE4DA6.9020106%40riseup.net%3E
Re: A couple thousand mp3 files (this is not spam I swear )
On 08/13/2016 09:33 PM, Branko Čibej wrote: > There is (currently) no easy way to specify "write once" access for > files in the repository; whoever can create a file can modify or delete > it, too. You could achieve something like that by creating a custom > pre-commit hook that would examine the pending commit transaction and > reject the commit if it finds modifications or deletions of existing files Thanks. I have svnserve configured and ready for a few tests that should enable basic characterization of the system in this use-case. I suppose I could concurrently develop familiarity with the command and operation of this setup while I explore customization of its functioning. Tonight is for contemplation but I imagine testing and hook scripting will begin within the next few days. Does anyone have any comments on using Tcl as a hook scripting language? > But note that a rename is represented as an add+delete, so the hook > would have to be rather smarter than it would seem at first glance to > detect and allow renames without content modification. The literal file names are composed of a date and a sequence number, and like the contents of the files, the names should never change. The core data-set directory structure (trunk, maybe) will most likely be calendar-like (years->months->days->sequence->file). The analysis tools and meta-data will probably be kept in a separate fossil[1] repository. [1]: http://www.fossil-scm.org/ The near-term goal is to maintain an indelible record of the physical measurements of reality. Any analysis [of which, there will be plenty], annotations, and other meta-data generation must not alter the fundamental instrumentation data. Given that, by "rename" do you mean a change of the literal file name like what I tried to describe above, or are you referring to something more like the file references, links, or pointers within the repository [internal implementation], similar to David's use of the term "rename" (included below)? On 08/13/2016 02:21 PM, David Chapman wrote: > On 8/13/2016 11:07 AM, Adam Jensen wrote: >> When a branch is created, are the files under revision control in the >> trunk copied to the branch (is there any duplication of files in the >> repository)? > > No, the files are not copied; a rename is stored. These are "cheap > copies", and this is an advantage over simple backups - if you want to > save history using backups (per another suggestion), you need to retain > one backup per significant event. That can add up.
Re: A couple thousand mp3 files (this is not spam I swear )
On 08/16/2016 09:17 AM, Stefan Hett wrote: > Just to have this mentioned: Be aware that the working copy (aka: the > checked out data of the repository) will have a 2x storage requirement > on the data since it will keep a copy of the pristine version of the > file in addition to the "actual" file. The type of system that I am imagining might typically have several terabytes of instrumentation data in a repository[1]. Various client machines might need to check-out a few gigabytes or a few hundred gigabytes at a time to run data analysis (automated compute jobs) or to perform a study (scientist/human-interest). [1]: Version control isn't a requirement in this use-case/hypothetical-system. Sophisticated access control is much more of a concern. Mandatory audit trails and distributed contract based data handling are examples of more relevant architectural characteristics. I am currently looking at the possibility of using Subversion (in a non-traditional, off-label fashion) to bootstrap a [very] simplified demonstration-of-concept type of setup. My current data-set is only about 25GB and growing at a rate of about 1GB/week. A desktop server and laptop client shouldn't have any storage space problems (in this case as a small demonstration system). > If this is a concern for your use-case, you could export the files and > only use a working copy in cases where you need to commit or reorder files. By "export the files" do you mean something like an NFS share of the repository, thus bypassing svnserve and the check-in/check-out process? That seems like a clever possibility worth remembering, but for now the system I am currently building/imagining is headed in a different direction. > To clarify: This is purely a client side storage requirement. It does > not apply to the storage requirements on the server side. To reduce network load, are there any client-side caching options for Subversion? Does the svn program account for the files already in the working copy (on the local disk) and avoid transferring those files over the network during a subsequent check-out [that requires those files]? Is it possible to clone or mirror all or part of a Subversion repository? This probably isn't relevant to Subversion, but in the system I am imagining it might be reasonable for clients to check-out data-sets via torrent connections with other full/partial repositories.
Re: A couple thousand mp3 files (this is not spam I swear )
On 08/16/2016 09:17 AM, Stefan Hett wrote: > On 8/13/2016 2:56 AM, Adam Jensen wrote: >> My primary concerns are related to any potential file corruption, any >> data duplication, and/or any excessive network or disk I/O (other than >> the expected load of direct data communication). > > Just to have this mentioned: Be aware that the working copy (aka: the > checked out data of the repository) will have a 2x storage requirement > on the data since it will keep a copy of the pristine version of the > file in addition to the "actual" file. > If this is a concern for your use-case, you could export the files and > only use a working copy in cases where you need to commit or reorder files. > > To clarify: This is purely a client side storage requirement. It does > not apply to the storage requirements on the server side. > Wow, I totally misinterpreted that during the first reading. After some tinkering this morning (and reading Ryan's email) I think I see the light ;) svn checkout svn://minerva.bohemia.net/Project_Prometheus/trunk cotest du -sh cotest 104Mcotest svn export svn://minerva.bohemia.net/Project_Prometheus/trunk extest du -sh extest 52Mextest
Re: A couple thousand mp3 files (this is not spam I swear )
On 08/17/2016 12:55 AM, Ryan Schmidt wrote: [snip] > He means avoid the 2x disk use by using "svn export" instead of "svn > checkout". > [snip] > > Of course Subversion only transfers changes. > Situation summary for the many-large-files scenario. Something like: svn checkout svn://URL/ProjX/branches/profile1 ~/test cd ~/test svn switch ^/branches/profile2 the branch switch will work nicely with a many-large-files data-set, only transferring the files necessary to complete the new profile. But the storage requirements for the working copy (~/test) is twice (2x) the size of the checked-out data-set. Alternatively, using the export method: svn export svn://URL/ProjX/branches/profile1 ~/test will transfer all of the files of profile1 and the storage requirements for the working copy is only (1x) the size of the data-set. But switching between branches is not available in the export method. To switch branches (using the export method): svn export svn://URL/ProjX/branches/profile1 ~/test (transfers all files in profile1) rm -rf ~/test svn export svn://URL/ProjX/branches/profile2 ~/test (transfers all files in profile2) So basically, the checkout method will require twice (2x) the data-set size of storage space for a working copy but there would be significantly less network load during many of the branch switches. The export method pretty much has the opposite storage/network trade-off.
Re: A couple thousand mp3 files (this is not spam I swear )
On 08/17/2016 04:36 PM, Johan Corveleyn wrote: > On Wed, Aug 17, 2016 at 9:13 PM, Adam Jensen wrote: [snip] >> So basically, the checkout method will require twice (2x) the data-set >> size of storage space for a working copy but there would be >> significantly less network load during many of the branch switches. The >> export method pretty much has the opposite storage/network trade-off. > > I guess you'd need this (very old) feature request to be implemented: > > https://issues.apache.org/jira/browse/SVN-525 (allow working copies > without text-base/) Nice reference, thanks! Wow, that feature was requested during 2001. What I need (and what I think is generally needed) is a high-capacity, large-file repository with a focus on data integrity (mandatory audit trails), sophisticated access control (smart contracts (maybe blockchain based)), probably (almost certainly) an encrypted file-system, and distribution/replication (that is maybe torrent based). Files in this type of system might need to be deleted but they wouldn't be revised. This would not be a revision management system. I'm not sure how much of Subversion could be used/leveraged to build such a system. At a minimum, it seems like it would involve a project fork and serious gutting and refactoring of the code-base after rethinking the basic principles, specifying the new requirements, and devising the new architecture. (And definitely a name change ). It's not the Pyramid of Khufu big, or the Panama Canal big, but it would be a big project. For now, I still think I can use Subversion as the file repository in a limited capability, ad-hoc implementation of a small demonstration-of-concept instrumentation and analysis system.
Re: A subersion build environment on CentOS 7.2
On 08/21/2016 07:00 AM, Stefan Sperling wrote: [snip] > If your goal is setting up a production environment, I would recommend > using binary packages system from http://subversion.apache.org/packages.html My CentOS (el7.x86_64) machine only has subversion 1.7.14 available: % yum info subversion Installed Packages Name: subversion Arch: x86_64 Version : 1.7.14 Release : 10.el7 Size: 4.6 M Repo: installed >From repo : anaconda There doesn't seem to be an option for subversion 1.9.4. A brief scan of the offerings at: http://subversion.apache.org/packages.html#redhat isn't encouraging. CollabNet and WANdisco both require registration, SummerSoft is either out-of-date or incomprehensible, and: https://wiki.centos.org/AdditionalResources/Repositories/RPMForge says: "RPMForge/RepoForge is a dead project. It is not maintained. DO NOT USE." Given the situation, building from source might be a reasonable approach. I downloaded the 1.9.4 source a few days ago, to have a look at it, and I will probably need to build it on CentOS-7; so, any pointers Horst or others might post on this process will be appreciated (by me, at least).
Re: A subersion build environment on CentOS 7.2
On 08/21/2016 03:24 PM, Adam Jensen wrote: [snip] > My CentOS (el7.x86_64) machine only has subversion 1.7.14 available: [snip] I would still like to be set up to build from source, but for those on CentOS-7 that would like convenient installation of a recent version, I found this page: http://tecadmin.net/install-subversion-1-8-on-centos-rhel/ and adapted the instructions like this: sudo vi /etc/yum.repos.d/wandisco-svn.repo [WandiscoSVN] name=Wandisco SVN Repo baseurl=http://opensource.wandisco.com/centos/7/svn-1.9/RPMS/x86_64/ enabled=1 gpgcheck=0 Then: sudo yum remove subversion* sudo yum clean all sudo yum install subversion subversion-devel subversion-tools \ subversion-python subversion-perl subversion-gnome mod_dav_svn
Subversion 1.10.2 Checksum (SHA512)
>From the recommended release page: https://subversion.apache.org/download.cgi#recommended-release The Checksum (SHA512) file: https://www.apache.org/dist/subversion/subversion-1.10.2.tar.bz2.sha512 Contains: ccbe860ec93a198745e40620cb7e005a85797e344a99ddbc0e24c32ad846976eae35cf5b3d62ba5751b998f0d40bbebbba72f484d92c92693bbb2112c989b129 In order to check the hash of the file using a command like this: sha512sum --check subversion-1.10.2.tar.bz2.sha512 Shouldn't the format of that file (subversion-1.10.2.tar.bz2.sha512) be something like this: ccbe860ec93a198745e40620cb7e005a85797e344a99ddbc0e24c32ad846976eae35cf5b3d62ba5751b998f0d40bbebbba72f484d92c92693bbb2112c989b129 subversion-1.10.2.tar.bz2 That is, it should contain the hash AND the file name. Given the current situation, can anyone think of a shell script blurb to download the files then verify with the hash? Normally, I would do it with something like this: #!/usr/bin/env bash FILE=subversion-1.10.2.tar.bz2 if [ ! -f $FILE ]; then echo "Fetching $FILE" wget http://www-eu.apache.org/dist/subversion/subversion-1.10.2.tar.bz2 fi FILE=subversion-1.10.2.tar.bz2.sha512 if [ ! -f $FILE ]; then echo "Fetching $FILE" wget https://www.apache.org/dist/subversion/subversion-1.10.2.tar.bz2.sha512 fi sha512sum --check subversion-1.10.2.tar.bz2.sha512 || exit 1 # and the script continues...
Re: Subversion 1.10.2 Checksum (SHA512)
The script was patched with a line like this: echo " subversion-1.10.2.tar.bz2" >> subversion-1.10.2.tar.bz2.sha512 On 09/22/2018 09:39 AM, Adam Jensen wrote: >>From the recommended release page: > https://subversion.apache.org/download.cgi#recommended-release > > The Checksum (SHA512) file: > https://www.apache.org/dist/subversion/subversion-1.10.2.tar.bz2.sha512 > > Contains: > ccbe860ec93a198745e40620cb7e005a85797e344a99ddbc0e24c32ad846976eae35cf5b3d62ba5751b998f0d40bbebbba72f484d92c92693bbb2112c989b129 > > In order to check the hash of the file using a command like this: > sha512sum --check subversion-1.10.2.tar.bz2.sha512 > > Shouldn't the format of that file (subversion-1.10.2.tar.bz2.sha512) be > something like this: > ccbe860ec93a198745e40620cb7e005a85797e344a99ddbc0e24c32ad846976eae35cf5b3d62ba5751b998f0d40bbebbba72f484d92c92693bbb2112c989b129 > subversion-1.10.2.tar.bz2 > > That is, it should contain the hash AND the file name. > > Given the current situation, can anyone think of a shell script blurb to > download the files then verify with the hash? Normally, I would do it > with something like this: > > #!/usr/bin/env bash > FILE=subversion-1.10.2.tar.bz2 > if [ ! -f $FILE ]; then > echo "Fetching $FILE" > wget http://www-eu.apache.org/dist/subversion/subversion-1.10.2.tar.bz2 > fi > FILE=subversion-1.10.2.tar.bz2.sha512 > if [ ! -f $FILE ]; then > echo "Fetching $FILE" > wget > https://www.apache.org/dist/subversion/subversion-1.10.2.tar.bz2.sha512 > fi > sha512sum --check subversion-1.10.2.tar.bz2.sha512 || exit 1 > # and the script continues... > >
Re: Subversion 1.10.2 Checksum (SHA512)
On 09/22/2018 10:13 AM, Daniel Shahaf wrote:
> One reason for not creating the file in the form
> "${hash}${two_spaces}${filename}"
> is that not everyone uses sha512sum from GNU coreutils. If there were
> additional information in the file besides the hash value, people not on
> linux would have had to sed it out.
apr and apr-util each do it differently. Consequently, the
idiosyncrasies of each will need to explored and handled separately.
svnserve setup on RHEL-7.5
Hi,
I am attempting to set up an svn server on Scientific Linux 7.5 using
subversion from the wandisco repositry. This is my entire process
(below). The current result is:
svn list svn://moria.metadatalibrary.org/MAAPSS
svn: E170013: Unable to connect to a repository at URL
'svn://moria.metadatalibrary.org/MAAPSS'
svn: E13: Can't open file '/srv/svn/MAAPSS/format': Permission denied
Does anyone have any idea what have caused this problem?
--
cat /etc/yum.repos.d/wandisco-svn.repo
[WandiscoSVN]
name=Wandisco SVN Repo
baseurl=http://opensource.wandisco.com/centos/7/svn-1.10/RPMS/x86_64/
enabled=1
gpgcheck=0
rpm -q subversion
subversion-1.10.2-1.x86_64
svnserve --version
svnserve, version 1.10.2 (r1835932)
compiled Jul 24 2018, 15:08:17 on x86_64-redhat-linux-gnu
Copyright (C) 2018 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/
The following repository back-end (FS) modules are available:
* fs_fs : Module for working with a plain file (FSFS) repository.
* fs_x : Module for working with an experimental (FSX) repository.
* fs_base : Module for working with a Berkeley DB repository.
Cyrus SASL authentication is available.
groupadd -g 502 svn
useradd -c "SVN" -d /srv/svn -g 502 -u 502 -s /sbin/nologin -M svn
mkdir /srv/svn
chown -R svn:svn /srv/svn/
sudo -u svn svnadmin create /srv/svn/MAAPSS
sudo -u svn vi /srv/svn/MAAPSS/conf/svnserve.conf
vi /etc/sasl2/svn.conf
pwcheck_method: auxprop
auxprop_plugin: sasldb
sasldb_path: /etc/svn_sasldb
mech_list: DIGEST-MD5 CRAM-MD5
saslpasswd2 -c -f /etc/svn_sasldb -u moria.metadatalibrary.org hanzer
chown svn:svn /etc/svn_sasldb
vi /etc/systemd/system/svnserve.service
[Unit]
Description=Subversion protocol daemon
After=syslog.target network.target
[Service]
Type=forking
RuntimeDirectory=svnserve
PIDFile=/run/svnserve/svnserve.pid
EnvironmentFile=/etc/default/svnserve
ExecStart=/usr/bin/svnserve $DAEMON_ARGS
User=svn
Group=svn
KillMode=control-group
Restart=on-failure
[Install]
WantedBy=multi-user.target
Alias=svnserve.service
vi /etc/default/svnserve
# svnserve options
DAEMON_ARGS="--daemon --pid-file /run/svnserve/svnserve.pid --root
/srv/svn/ --listen-port=3690 --log-file /var/log/svnserve/svnserve.log"
mkdir /var/log/svnserve; chown svn /var/log/svnserve
vi /etc/logrotate.d/svnserve
/var/log/svnserve/*.log {
daily
missingok
rotate 14
compress
notifempty
create 660 svn root
sharedscripts
postrotate
if /usr/bin/systemctl status svnserve > /dev/null ; then \
/usr/bin/systemctl restart svnserve > /dev/null; \
fi;
endscript
}
systemctl start svnserve.service
systemctl status svnserve.service
● svnserve.service - Subversion protocol daemon
Loaded: loaded (/etc/systemd/system/svnserve.service; disabled;
vendor preset: disabled)
Active: active (running) since Mon 2018-10-01 23:06:29 EDT; 2s ago
Process: 4049 ExecStart=/usr/bin/svnserve $DAEMON_ARGS (code=exited,
status=0/SUCCESS)
Main PID: 4050 (svnserve)
CGroup: /system.slice/svnserve.service
└─4050 /usr/bin/svnserve --daemon --pid-file
/run/svnserve/svnserve.pid --root /srv/svn/ --listen-port=3690
--log-file /var/log/s...
Oct 01 23:06:29 moria.metadatalibrary.org systemd[1]: Starting
Subversion protocol daemon...
Oct 01 23:06:29 moria.metadatalibrary.org systemd[1]: Started Subversion
protocol daemon.
firewall-cmd --zone=internal --permanent --add-port=3690/tcp
firewall-cmd --reload
--
svn list svn://moria.metadatalibrary.org/MAAPSS
svn: E170013: Unable to connect to a repository at URL
'svn://moria.metadatalibrary.org/MAAPSS'
svn: E13: Can't open file '/srv/svn/MAAPSS/format': Permission denied
ls -l /srv/svn/MAAPSS
total 12
drwxr-xr-x. 2 svn svn 96 Oct 1 23:18 conf
drwxr-sr-x. 6 svn svn 4096 Oct 1 22:09 db
-r--r--r--. 1 svn svn2 Oct 1 22:09 format
drwxr-xr-x. 2 svn svn 271 Oct 1 22:09 hooks
drwxr-xr-x. 2 svn svn 53 Oct 1 22:09 locks
-rw-r--r--. 1 svn svn 246 Oct 1 22:09 README.txt
ps -aux | grep svn
svn 4388 0.0 0.0 181276 1232 ?Ss 23:18 0:00
/usr/bin/svnserve --daemon --pid-file /run/svnserve/svnserve.pid --root
/srv/svn/ --listen-port=3690 --log-file /var/log/svnserve/svnserve.log
Re: svnserve setup on RHEL-7.5
On 10/02/2018 02:52 AM, Ryan Schmidt wrote:
>
>
> On Oct 1, 2018, at 22:33, Adam Jensen wrote:
>
>> I am attempting to set up an svn server on Scientific Linux 7.5 using
>> subversion from the wandisco repositry. This is my entire process
>> (below). The current result is:
>>
>> svn list svn://moria.metadatalibrary.org/MAAPSS
>> svn: E170013: Unable to connect to a repository at URL
>> 'svn://moria.metadatalibrary.org/MAAPSS'
>> svn: E13: Can't open file '/srv/svn/MAAPSS/format': Permission denied
>>
>> Does anyone have any idea what have caused this problem?
>
> Might SELinux be enabled on the server, and if so, might you need to use the
> chcon command to grant the svn user access to that area of the filesystem?
>
>
Thanks, Ryan. I looked at SELinux last night as the potential source of
the problem but dismissed it somehow. Looking at it again earlier today
with fresh eyes, it certainly does seem to be the problem. This is my
solution:
chcon -Rv --user system_u /srv/svn
chcon -Rv --type svnserve_content_t /srv/svn
ls -Z /srv
drwxr-xr-x. svnsvnsystem_u:object_r:svnserve_content_t:s0 svn
# Test it:
svn list svn://moria.metadatalibrary.org/MAAPSS/
Authentication realm:
moria.metadatalibrary.org
Password for 'hanzer': *
# Make it permanent:
semanage fcontext -a -s system_u -t svnserve_content_t "/srv/svn(/.*)?"
restorecon -R -v /srv/svn
# Verify:
matchpathcon -V /srv/svn
/srv/svn verified.
And for posterity, here are my problem exploration notes:
---
less /var/log/messages # The relevant parts:
# SELinux is preventing svnserve from read access on the file format.
# If you want to allow svnserve to have read access on the format file
# Then you need to change the label on format
# semanage fcontext -a -t FILE_TYPE 'format'
# where FILE_TYPE is one of the following:
# svnserve_content_t, svnserve_exec_t, svnserve_log_t, svnserve_tmp_t,
svnserve_var_run_t
ps -efZ | grep svn
system_u:system_r:svnserve_t:s0 svn 4700 1 0 Oct01 ?
00:00:00 /usr/bin/svnserve --daemon --pid-file
/run/svnserve/svnserve.pid --root /srv/svn/ --listen-port=3690
--log-file /var/log/svnserve/svnserve.log
ls -Z /srv/
drwxr-xr-x. svnsvnunconfined_u:object_r:var_t:s0 svn
sesearch --allow --source svnserve_t --target var_t --class file
# empty output
sesearch --allow --source svnserve_t --target svnserve_content_t --class
file
Found 1 semantic av rules:
allow svnserve_t svnserve_content_t : file { ioctl read write create
getattr setattr lock append unlink link rename open } ;
sesearch --allow --source svnserve_t --target svnserve_exec_t --class
file
Found 1 semantic av rules:
allow svnserve_t svnserve_exec_t : file { ioctl read getattr lock
execute execute_no_trans entrypoint open } ;
sesearch --allow --source svnserve_t --target svnserve_log_t --class file
Found 2 semantic av rules:
allow svnserve_t svnserve_log_t : file { ioctl read write create
getattr setattr lock append unlink link rename open } ;
allow daemon logfile : file { ioctl getattr lock append } ;
sesearch --allow --source svnserve_t --target svnserve_tmp_t --class file
Found 2 semantic av rules:
allow svnserve_t svnserve_tmp_t : file { ioctl read write create
getattr setattr lock append unlink link rename open } ;
allow domain tmpfile : file { ioctl read getattr lock append open } ;
sesearch --allow --source svnserve_t --target svnserve_var_run_t --class
file
Found 1 semantic av rules:
allow svnserve_t svnserve_var_run_t : file { ioctl read write create
getattr setattr lock append unlink link rename open } ;
ls -Z /var/log
drwxr-xr-x. svn rootunconfined_u:object_r:var_log_t:s0 svnserve
ls -Z /var/log/svnserve/
-rw-r--r--. svn svn system_u:object_r:svnserve_log_t:s0 svnserve.log
ls -Z /run
drwxr-xr-x. svnsvn
system_u:object_r:svnserve_var_run_t:s0 svnserve
ls -Z /run/svnserve/
-rw-r--r--. svn svn system_u:object_r:svnserve_var_run_t:s0 svnserve.pid
ls -Z /usr/bin/svnserve
-rwxr-xr-x. root root system_u:object_r:svnserve_exec_t:s0 /usr/bin/svnserve
ls -Z /etc/sasl2/svn.conf
-rw-r--r--. root root unconfined_u:object_r:etc_t:s0 /etc/sasl2/svn.conf
ls -Z /etc/svn_sasldb
-rw-r-. svn svn unconfined_u:object_r:etc_t:s0 /etc/svn_sasldb
sesearch --allow --source svnserve_t --target etc_t --class file
Found 1 semantic av rules:
allow domain base_ro_file_type : file { ioctl read getattr lock open } ;
chcon -Rv --user system_u /srv/svn
chcon -Rv --type svnserve_content_t /srv/svn
ls -Z /srv
drwxr-xr-x. svnsvnsystem_u:object_r:svnserve_content_t:s0 svn
# Test it:
svn list svn://moria.metadatalibrary.org/MAAPSS/
Authentication realm:
moria.metadatalibrary.org
Password for 'hanzer': *
# Make it permanent:
Re: svnserve setup on RHEL-7.5
On 10/02/2018 02:35 PM, Adam Jensen wrote: > Curiously, on the local machine "moria" this works: > > svn list svn://moria.metadatalibrary.org/MAAPSS/ > Authentication realm: > moria.metadatalibrary.org > Password for 'hanzer': * > > > But from a machine on the LAN (also SL-7.5 with the same wandisco svn): > > svn list svn://moria.metadatalibrary.org/MAAPSS/ > svn: E170013: Unable to connect to a repository at URL > 'svn://moria.metadatalibrary.org/MAAPSS' > svn: E210007: Cannot negotiate authentication mechanism > > > Do you suppose this is a network configuration problem rather than an > svn configuration problem? It turns out the SL-7.5 client machine on the LAN needed the package: yum install cyrus-sasl-md5.x86_64 With that, 'svn list ...' seems to work just fine.
