No announcement yet.

troubleshooting a "dead" svnserve daemon

  • Filter
  • Time
  • Show
Clear All
new posts

  • troubleshooting a "dead" svnserve daemon

    On suggestions w/r/t to HTTPS and SELinux, I took care of both of those would-be issues.

    ​I changed /etc/apache2 from acting upon my desire to use a large partion, /opt, over the standard /var area for my repository. I got it to work and added SSL made https the default. It will never be seen by the WAN anyway, only my LAN systems. Subversion is a different matter. The web is full of insights that never mention the versions of Subversion or Apache to which their file/folder/configs relate so that I have had to throw all of them out the window. However, I did find one wherein the step-wise content for apache2, SSL, and mod_dav all worked on the first test. Amazing! For reference, look up "Hitesh Jethva". He has verified (unlike so many others) his steps and clarified the [dependent] versions in:

    -"How To Set Up Webdav with Apache On Ubuntu";
    -"Setting Up Apache Server with SSL Support On Ubuntu";
    -"Setting Up IP and Port-Based Virtualhost In Apache";
    -"Setting Up Name-Based Virtualhost Apache".

    I got all working within a short day, except for snvserve, which he didn't cover.

    When every instruction set first says the word "easy" and then leaves out parts of command-lines, steps, or version info, I shudder at the thought of using software they create and then assert as "tested", "verified", or "working". Many people, excited by their fully-[un]documented success, tend to leave out on-the-fly fixes they had to make to get it running. Oh well. I learned much having to backtrack so many times. I appreciate the thought, even of steps that were errant, as they meant well, and did teach me about the nuances of commands, versions, and configurations based in both. Also, once again, about actually starting from zero, following your own steps, and verifying that they actually work... which rarely takes place any more....

    So, the Subversion books I acquired all are pretty much useless, stepping through outmoded files, locations, and methods... in terms of both apache and subversion. The latest attempt at gleaning "magical descriptions" was from "Subversion Version Control" (by William Nagel), and is from 2005. Most say that they cover numerous versions (on the cover) but do not distinguish within the cover, and thus, leaves me thinking it was all a book sales pitch. Doc and web how-tos, except for the latest-and-greatest SVN Book, deal with subversion within the configuration world of apache 1.x, or fail to mention which one (or combinations) they are dealing with, which, for me on apache2.x, would be useful if I can also use a list of all pertinent changes (w/r/t variables, files in /etc/apache2, in /var/svn on the server, and on a client in /home/myuser/.svn, etc.), with which to map-and-convert configuration settings. What would solve many issues is to have a look-and-see "running" ("live") client and server so that the environments are viewable and demonstably correct.

    That "living" site would be worth 1000 so-called "solutions" and could easily be used as a working template. The access would be as a registered user who could "view" but not "vi", click on a list of all pertinent configuration files/steps and actually see the permissions, contents, and integrated functioning parts, minimal as they would be. It's concrete rather than abstract, however, that's just a 30+ year QA Engineer's dreamworld. I'd help if anyone wants to make it so....

    I access apache2 (through the browser) now -- via either [url][/url] or [url][/url] -- and get an authentication page, which finds the /etc/apache2/.htpasswd file I use for both apache2 and subversion (instead of svn-auth-users, ad finitum) and returns "notwrepos: notwrepos - Revision 0:/".

    Method A) I can go to the server system (robin) and from there, run the svnadmin create" command to create the svn folder structure, with dummy .py files for each module's folder;

    Method B) I can add the structure and dummy files onto a client and then checkin that whole set from the client onto the server, using the "checkin" command.

    I have several questions.

    Q1) What line needs to be at the top of each dummy file, as with an RCS versioning line? How is it structured? Where is it documented?
    Q2) What are the commands that get used in the two methods listed above?
    Q3) Does svnserve need to be running for those commands to work?

    The reason I ask Q3 is because I would prefer using a Linux alias which calls a shell script which presents me with a checkbox (i.e., inclusive selections versus exclusive) of possible/recent (using a pipe of ls -alrt) checkouts that I may want to checkout. I am not a fan of GUI whichj passes my code through the code of someone else based more upon "faith" than knowledge of what it may or will do.

    I never had any selinux running.
    Permissions are correctly set for root and www-data on linux and subversion.

    I am never able to get through with svnserve.
    I originally started it with:
    $ sudo update-rc.d svnserve defaults
    $ sudo systemctl start svnserve

    Since, I've tried all of the following:
    $ sudo systemctl enable svnserve
    $ sudo --system daemon-reload
    $ sudo systemctl start svnserve

    $ service --status-all | grep "svnserve"
    [ - ] svnserve
    [ - ] svnserve-with-opt-svn-notwrepos
    [ - ] svnserve-with-var-www-svn-notwrepos

    I made the mistake of renaming them and keeping them in the directory.
    svnserve: svnserve -d -r /var/www/svn/notwrepos
    svnserve-with-opt-svn-notwrepos: svnserve -d -r /optrsvn/notwrepos
    svnserve-with-var-www-svn-notwrepos: svnserve -d -r /var/www/svn/notwrepos

    I moved both svnserve-with* backups to /home/robinadm/Desktop, and re-ran
    $ sudo --system daemon-reload

    I am uncertain whether all three are merely logged or running (in some zombie state) in some way....
    Unlike a 'ps' command so I can run a 'kill' on a pid, I'm uncertain (and haven't read any docs which explain) how to kill all three and restart the one.
    I would've expected these to have straightened out what's running, but I must be missing something and/or a sequence in how to succeed.
    $ sudo systemctl restart apache2
    $ sudo systemctl reload apache2

    On the client, I run:
    $ svnlook info [url][/url]
    [url][/url]' is a URL when it should be a path.

    I checked -- on the server, robin -- on the status of svnserve.
    $ systemctl status svnserve
    [white dot] svnserve.service
    Loaded: loaded (/etc/init.d/svnserve; generated)
    Active: inactive (dead)
    Docs: man: systemd-sysv-generator(8)[IMG2=JSON]{"data-align":"none","data-size":"full","src":"https:\/\/\/core\/image\/gif;base64,R0lGODlhAQABAPABAP\/\/\/wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw=="}[/IMG2]​

    My svnserve steps:

    robinadm@robin:/etc/init.d$ systemctl restart apache2
    robinadm@robin:/etc/init.d$ systemctl --system daemon-reload
    robinadm@robin:/etc/init.d$ systemctl status -l svnserve
    ‚ svnserve.service
    Loaded: loaded (/etc/init.d/svnserve; generated)
    Active: inactive (dead)
    Docs: man:systemd-sysv-generator(
    robinadm@robin:/etc/init.d$ systemctl enable svnserve
    svnserve.service is not a native service, redirecting to systemd-sysv-install.
    Executing: /lib/systemd/systemd-sysv-install enable svnserve
    update-rc.d: error: svnserve Default-Start contains no runlevels, aborting.

    sudo systemctl restart svnserve
    Job for svnserve.service failed because the control process exited with error code.
    See "systemctl status svnserve.service" and "journalctl -xe" for details.

    $ journalctl -xe

    -- Support: [url][/url]
    -- Unit svnserve.service has begun starting up.
    Feb 29 20:33:46 robin systemd[6011]: svnserve.service: Failed to execute command: Exec format error
    Feb 29 20:33:46 robin systemd[6011]: svnserve.service: Failed at step EXEC spawning /etc/init.d/svnserve: Exec format error
    -- Subject: Process /etc/init.d/svnserve could not be executed
    -- Defined-By: systemd
    -- Support: [url][/url]
    -- The process /etc/init.d/svnserve could not be executed and failed.
    -- The error number returned by this process is 8.
    Feb 29 20:33:46 robin systemd[1]: svnserve.service: Control process exited, code=exited status=203
    Feb 29 20:33:46 robin systemd[1]: svnserve.service: Failed with result 'exit-code'.
    Feb 29 20:33:46 robin systemd[1]: Failed to start svnserve.service.
    -- Subject: Unit svnserve.service has failed
    -- Defined-By: systemd
    -- Support: [url][/url]
    -- Unit svnserve.service has failed.
    -- The result is RESULT.
    Feb 29 20:33:46 robin sudo[6008]: pam_unix(sudo:session): session closed for user root
    lines 1413-1435/1435 (END)

    And so, that is where I am.I cannot connect with svnserve.

    I am very appreciative if you/anyone can spot the error(s) and/or omission(s), esp. if you have suggestions for resolving it/them.

    best wishes,

  • #2
    Q1) What line needs to be at the top of each dummy file, as with an RCS versioning line? How is it structured? Where is it documented?

    There are no required lines for any file that is versioned within the Subversion repository. That said, you can choose to use "RCS-like keywords" wherever valid.
    Documentation is here: [URL=""][/URL]

    Q2) What are the commands that get used in the two methods listed above?

    I'm going to assume you've setup Apache using "SVNParentPath" since it is FAR easier to create new repos with that setup than with "SVNPath".

    If you give the Apache account a shell (normally a security issue - but in reality a practical requirement when hosting repos), then login as the
    Apache account to the server. You can then do:[LIST=1][*]"svnadmin create" to create the repo.[*]"cd /tmp; svn checkout file:///path/to/repo" to get a working copy in /tmp[*]"cd repo; ..." to setup the initial structure.[*]"svn checkin" to get the initial structure up into the repository.[/LIST]After that you can just use Apache and/or svnserve

    Q3) Does svnserve need to be running for those commands to work?

    No, it does not need to be running. In fact, if it is running then anyone who has the ability to connect to that port
    will be able to do whatever the account that svnserve is running as can do - and every operation will be recorded
    as having been done by that account. If you don't care then, I guess, sure.

    Instead, you would use a URL such as: svn+ssh://apache@
    That URL assumes that the Apache account (in this case "apache" although on some systems it is "httpd") has an appropriate "authorized_keys" file that has entries of the form: [INDENT]command="/usr/bin/svnserve -t --tunnel-user=acct10001 -r /opt/repo",no-port-forwarding,no-pty,no-agent-forwarding,no-X11-forwarding public-key-for-account-acct10001[/INDENT]

    Note that the "-r /opt/repo" specifies the root of the search for repositories. That way the URL only needs the repo name.
    When SSH sees the request it will match the private key of the caller to the public key on that line (see the end of line).
    Then SSH will invoke that command - which identifies the specific account to which the operation should be registered
    (and authorized if you've turned on AuthZ).