If you have forgotton the admin password of Stash

rajeshkumar created the topic: If you have forgotton the admin password of Stash
If you have forgotton the admin password of Stash.

1. Edit the \bin\setenv.sh file (or setenv.bat on Windows) and add the “-Datlassian.recovery.password=temporarypassword” argument to the JVM_SUPPORT_RECOMMENDED_ARGS property. The property value must be non-blank,Here we are using “temporarypassword”, but you can use your own value.

2. Start Stash.
3. Log in to Stash using the ‘recovery_admin’ username and the temporary password specified in Step 1.
4. Repair your Stash configuration.You may reset the admin password as well. We strongly recommend that you do not perform other actions while Stash is in recovery mode.
5. Confirm your ability to log in with your usual admin profile.
6. Shut down Stash, remove the atlassian.recovery.password argument from setenv.sh, and restart Stash as usual.

Reference- confluence.atlassian.com/display/STASH/Lockout+recovery+process
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

Tagged :

Git repository backup

vishal_vsh1 created the topic: Git repository backup
Git repository backup

Git is distributes system, the beauty of the git make is more robust and easy to recover from any last known good working copy.

However, You can not always rely on such copy and you will definitely need proper backup solution to deal with such situation.

There are many ways to take backup of git repositories.
I am listing few here.

You can directly take a tar of the git repo directory as it has the whole bare contents of the repo on server. There is a slight possibility that somebody may be working on repo while taking backup.
The following command will give you the bare clone of repo (just like it is in server), then you can take a tar of the location where you have cloned without any issue.
git clone –bare {your backup local repo} {new location where you want to clone}

Reference – www.scmtechblog.net/2015/07/git-repository-backup.html

rajeshkumar replied the topic: Git repository backup
Thanks for useful info.
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

Tagged :

Server sent unexpected return value (423 Locked) i

scmuser created the topic: Server sent unexpected return value (423 Locked) i
During checking of files i am getting following error. Any help?

“Server sent unexpected return value (423 Locked) in response to PUT request for”

scmuser replied the topic: Re:Server sent unexpected return value (423 Locked) i
i found the solution using Tortoise Svn. Steal lock and then update and it worked for me.


Tagged :

Error validating server certificate for

scmuser created the topic: Error validating server certificate for
I am getting error during checkout source code from Svn.

Error validating server certificate for https://XYZ:443:
– Unknown certificate issuer
Fingerprint: 81:bb:5d:da:c5:7d:fa:f3:f4:9f:06:55:c6:34:e3:b4:64:d0:47:bc
Distinguished name: www.digicert.com , DigiCert Inc, US

sgadmin replied the topic: Re:Error validating server certificate for
It seems your cache Security certification for SVN server has been expired to removed. please Click on “Accept Permanently” to get rid of this issues.


When speaking to Apache via https://, a Subversion client can receive two different types of information:

a server certificate
a demand for a client certificate

If the client receives a server certificate, it needs to verify that it trusts the certificate: is the server really who it claims to be? The OpenSSL library does this by examining the signer of the server certificate, or certifying authority (CA). If OpenSSL is unable to automatically trust the CA, or if some other problem occurs (such as an expired certificate or hostname mismatch), the Subversion commandline client will ask you whether you want to trust the server certificate anyway.

svn list host.example.com/repos/project

Error validating server certificate for ‘ home.example.com:443 ‘:
– The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
Certificate information:
– Hostname: host.example.com
– Valid: from Jan 30 19:23:56 2004 GMT until Jan 30 19:23:56 2006 GMT
– Issuer: CA, example.com, Sometown, California, US
– Fingerprint: 7d:e1:a9:34:33:39:ba:6a:e9:a5:c4:22:98:7b:76:5c:92:a0:9c:7b

(R)eject, accept (t)emporarily or accept (p)ermanently?

This dialogue should look familiar; it’s essentially the same question you’ve probably seen coming from your web browser (which is just another HTTP client like Subversion!). If you choose the (p)ermanent option, the server certificate will be cached in your private run-time auth/ area in just the same way your username and password are cached (see the section called “Client Credentials Caching”.) If cached, Subversion will automatically remember to trust this certificate in future negotiations.

Your run-time servers file also gives you the ability to make your Subversion client automatically trust specific CAs, either globally or on a per-host basis. Simply set the ssl-authority-files variable to a semicolon-separated list of PEM-encoded CA certificates:

ssl-authority-files = /path/to/CAcert1.pem;/path/to/CAcert2.pem

Many OpenSSL installations also have a pre-defined set of “default” CAs that are nearly universally trusted. To make the Subversion client automatically trust these standard authorities, set the ssl-trust-default-ca variable to true.

When talking to Apache, a Subversion client might also receive a challenge for a client certificate. Apache is asking the client to identify itself: is the client really who it says it is? If all goes correctly, the Subversion client sends back a private certificate signed by a CA that Apache trusts. A client certificate is usually stored on disk in encrypted format, protected by a local password. When Subversion receives this challenge, it will ask you for both a path to the certificate and the password which protects it:

$ svn list host.example.com/repos/project

Authentication realm: host.example.com:443
Client certificate filename: /path/to/my/cert.p12
Passphrase for ‘/path/to/my/cert.p12’: ********

Notice that the client certificate is a “p12” file. To use a client certificate with Subversion, it must be in PKCS#12 format, which is a portable standard. Most web browsers are already able to import and export certificates in that format. Another option is to use the OpenSSL commandline tools to convert existing certificates into PKCS#12.

Again, the runtime servers file allows you to automate this challenge on a per-host basis. Either or both pieces of information can be described in runtime variables:

examplehost = host.example.com

ssl-client-cert-file = /path/to/my/cert.p12
ssl-client-cert-password = somepassword

Once you’ve set the ssl-client-cert-file and ssl-client-cert-password variables, the Subversion client can automatically respond to a client certificate challenge without prompting you. [24]

Tagged :

Add User to SVN Server and Set Password

rajeshkumar created the topic: Add User to SVN Server and Set Password
Adding users to svn

Add a user to the file /etc/subversion/svn-authz, then give that user a password as described below.
A suitable command could be
sudo vim /etc/subversion/svn-authz
sudo emacs /etc/subversion/svn-authz.

Adding or changing password for a user
sudo htpasswd -m /etc/subversion/svn-auth-file sally
New password: *******
Re-type new password: *******
Adding password for user sally
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

Tagged :

Apache2 LDAP authorization for Subversion with OpenDS

rajeshkumar created the topic: Apache2 LDAP authorization for Subversion with OpenDS
Apache2 LDAP authorization for Subversion with OpenDS

There are several ways to enable user authentication for web based applications, like .htaccess files, plain tekst files, databases, LDAP, etc. They all have their pros and cons. In case a central, flexible solution is needed, either a database or LDAP solution can be used.

I chose for an LDAP solution since it can be reused by many web and application servers and the applications that run on them while many LDAP solutions provide excellent tooling and easy configuration. Since Yenlo strongly focuses on GlassFish and other Sun tools, I chose OpenDS to authenticate against.The idea is to create a bunch of users and put them into one or more groups. Each group gets access to one specific Subversion repository and every user that needs access to a certain subversion repositoy needs to be in the corresponding group.

This blog describes the basic steps I took to get Basic HTTP authentication for Subversion using Apache2 and OpenDS.
Setting up the server

The server is running on Debian Etch, for which most of the required software is available via the Debian package repository. The packages I installed are

Apart form these packages I downloaded and installed the OpenDS 2.2 zip file from the OpenDS homepage. For this purpose I created a user and a group called “opends” and the directory /usr/local/opends which I gave both ownership and group “opends”. Next I logged in as user opends and extracted the zip file into that directory. Finally, as root, I created a start and stop script and used the update-rc.d script to make sure OpenDS is automatically started and stopped when the server is started and stopped.

Setting up Subversion

Let’s suppose that our organisation has decided to create a Subversion repository for each development project that we do. This means that we would get a directory structure like this, with the leaves being the root directories of each repository:

The repositories were created as root using these commands in the /usr/share/subversion directory
# svnadmin create repository1
# svnadmin create repository2

That’s all the configuration that was done to the Subversion repositories.

Configuring OpenDS

First, a basic setup of OpenDS needed to be done using the command
$ /usr/local/opends/OpenDS-2.2.0/bin/setup

For more info about this, see Setting Up the Directory Server. Please note that if you are not running OpenDS as root user, it will listen on port 1389.

The next step was to configure OpenDS so it contains a few users and groups. The main configuration tool for OpenDS is called control-panel and, in my case, it can be started as user “opends” by issuing this command:
$ /usr/local/opends/OpenDS-2.2.0/bin/control-panel

With this tool, among other things, you can manage the entries in the directory. For my purpose I created the next layout
base dn (dc=yenlo,dc=nl)
organisation (o=yenlo)
organisational unit (ou=devel)
user (uid=wouter1, password = wouter1)
user (uid=wouter2, password = wouter2)
user (uid=wouter3, password = wouter3)
group (cn=group1, uniqueMember=wouter1,wouter2)
group (cn=group2, uniqueMember=wouter2,wouter3)

which is a very simple layout but sufficient for now. Note that I created two Subversion repositories and therefore two LDAP groups, one for each Subversion repository.

Setting up Apache2 to get access to the Subversion repositories

First I configured Apache2 so the two repositories were accessible to anyone using e.g. a web browser. After libapache2-svn is installed, the module should be enabled in the Apache2 configuration files automatically. To verify this, check the

directory and make sure these symbolic links exist
dav.load -> ../mods-available/dav.load
dav_svn.conf -> ../mods-available/dav_svn.conf
dav_svn.load -> ../mods-available/dav_svn.load

If the first link is missing, create it as root using
# a2enmod dav

If the second and third are missing, create it as root using
# a2enmod dav_svn

To make sure the modules are loaded by Apache2, restart the server as root using
# /etc/init.d/apache2 restart

Now some modifications need to be made to the dav_svn configuration file

The idea is that there are two Subversion repositories that need to be configured individually. So, these two entries need to be put in the above mentioned configuration file

DAV svn
SVNPath /usr/share/subversion/repository1
SVNListParentPath On
SVNAutoversioning On
SVNReposName “Repository1 Subversion Repository”

DAV svn
SVNPath /usr/share/subversion/repository2
SVNListParentPath On
SVNAutoversioning On
SVNReposName “Repository2 Subversion Repository”

Now, if you point your browser to either http:///svn/repository1 or http:///svn/repository2 you should see the root of your repository.

Adding LDAP support using OpenDS

In order to use LDAP atuentication with Apache2, these two entries should be present in /etc/apache2/mods-enabled:
authnz_ldap.load -> ../mods-available/authnz_ldap.load
ldap.load -> ../mods-available/ldap.load

If they aren’t present, you can enable them as root with these commands
# a2enmod authnz_ldap
# a2enmod ldap
# /etc/init.d/apache2 restart

Now, each entry in /etc/apache2/mods-available/dav_svn.conf should be extended with these lines in order to get LDAP authentication working with OpenDS. Please note that you should pay attention to the group you assign to each subversion repository location. I am only showing the configuration addition for repository1 and leave it as an excercise to you to setup the second repository configuration. Also please note you make sure the correct password for the Directory Manager is provided. For more info about these configuration settings, please consult the OpenDS WIKI page on Apache Web Server.
AuthType Basic
AuthName “Repository1 Subversion Repository”
AuthBasicProvider ldap
AuthzLDAPAuthoritative off
AuthLDAPURL ldap://localhost:1389/dc=yenlo,dc=nl?uid
AuthLDAPBindDN “cn=Directory Manager”
AuthLDAPBindPassword mypassword
AuthLDAPGroupAttribute uniqueMember
AuthLDAPGroupAttributeIsDN on
Require ldap-group cn=repository1,ou=devel,o=yenlo,dc=yenlo,dc=nl

Issue a final
# /etc/init.d/apache2 restart

and you should be prompted for a username and password when you try to access either repository. Using the correct uid and password combination should grant you access to the repository.

Next stepts

The authentication mechanism we chose, Basic autentication, posts usernames and passwords in plain text, which potentially could be harmful in case someone sniffes the connection. I would strongly recommend to setup SSL based connections. Moreover, this blog post only shows how to secure one repository layout using LDAP. Both Subversion and Apache are sufficiently flexible that other layouts are possible. Those layouts most likely require tweaking of the Apache2 configuration options. Finally, I am not an LDAP expert so the directory structure I chose in OpenDS most likely can be much improved. However, following the steps in this article should get you on your way to using OpenDS incombination with Apache2.

Reference: Referencehttp://www.yenlo.nl/woutervanreeven/2010/03/15/apache2-ldap-authorization-for-subversion-with-opends/
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

rajeshkumar replied the topic: Re:Apache2 LDAP authorization for Subversion with Opends
Subversion authorization through LDAP with OpenDS

If you building a centralized development environment for a team or large group of users, the question of centralizing user identities, authentication and authorization is always popping up and the answer is often to use an LDAP directory server. The developer section of the OpenDS documentation wiki has a set of tutorials for using the OpenDS LDAP directory server with various web servers and open source project like GlassFish, Apache Tomcat, SugarCRM… But not yet for Subversion. Thankfully, Wooter van Reeven, Senior Consultant at Yenlo has just published a long and detailed tutorial for setting up Subversion authentication and authorization through LDAP, with OpenDS and Apache2.

Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

Tagged :

How Can I Validate A SVN Server’s Back-up And Rest

rajeshkumar created the topic: HOW CAN I VALIDATE A SVN SERVER’s BACK-UP AND REST
Consider I have installed SVN in a server and created users for accessing the server, I have to take a daily back-up of it and i do it. How can I validate it that the back-up is done properly ? Is there any short-cut to find the status of it ?!
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

Tagged :

SVN Checkout URL – fresh install

rajeshkumar created the topic: SVN Checkout URL – fresh install
0 vote down star

I just setup SVN on a server that is running Ubuntu server as a fresh install. I’ve got it up and running but am having difficult determining how to connect to it.

I’m trying to do an import using the local IP address: http://IP/RepositoryName but it’s saying it can’t resolve the IP. I’m wondering if there’s something on the server I need to setup.

I have not modified dav_svn.conf because there is another server here that is running SVN (I’m migrating it to a new server) and it’s dav_svn.conf is not modified. The current working SVN has a subdomain associated with the IP location of the server but doesn’t do anything special with the ports as far as I can tell.

I’m getting this error via RapidSVN when I try to import…
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

Tagged :

Need document/links for SVN hooks & Properties

vijayakumar.cm created the topic: Need document/links for SVN hooks & Properties

I would like to learn in depth of SVN hook scripts and SVN properties.
Could anyone please help me?


scmuser replied the topic: Re:Need document/links for SVN hooks & Properties
try this

Tagged :