I have the following setup on a linux box in user home directory:
./svn.simple/hash#1
./svn.simple/hash#2
==
hash#1 points to an old server: oldserver.com
hash#2 points to current server. currserver.com
I need to alter the default server location for specific user to a new server. Apologies if terminology is off. How do I go about this? I investigate --relocate, but that seems for a specific working copy. All commands are run at the command line.
A simple checkout from the new repository prompts if config is desired to be saved. If the response is 'yes' a new entry is added to ./svn.simple, saving all required config parameters.
Related
I'm trying to update Jenkins' root URL via the Groovy API, so I can script the deployment of a Jenkins master without manual input (aside: why is a tool as popular with the build/devops/automation community as Jenkins so resistant to automation?)
Based on this documentation, I believe I should be able to update the URL using the following script in the Script Console.
import jenkins.model.JenkinsLocationConfiguration
jlc = new jenkins.model.JenkinsLocationConfiguration()
jlc.setUrl("http://jenkins.my-org.com:8080/")
println(jlc.getUrl())
Briefly, this instantiates a JenkinsLocationConfiguration object; calls the setter setUrl with the desired value, http://jenkins.my-org.com:8080/; and prints out the new URL to confirm that it has changed.
The println statement prints what I expect it to, but following this, the value visible through the web interface at "Manage Jenkins" -> "Configure System" -> "Jenkins URL" has not updated as I expected.
I'm concerned that the value hasn't been update properly by Jenkins, which might lead to problems when communicating with external APIs.
Is this a valid way to fix the Jenkins root URL? If not, what is? Otherwise, why isn't the change being reflected in the config page?
You are creating a new JenkinsLocationConfiguration object, and updating the new one, not the existing one being used
use
jlc = JenkinsLocationConfiguration.get()
// ...
jlc.save()
to get the one from the global jenkins configuration, update it and save the config descriptor back.
see : https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/jenkins/model/JenkinsLocationConfiguration.java
I am moving from cvsserv1 to cvsserv2. I am running cvs1.11 on current server on RHEL. I am moving to cvsserv2 which is running ubuntu 12. This is my procedure to port cvs:
zip entire repository on cvsserv1
move zip to cvsserv2
extract zip to /home/users on cvsserv2.
setup cvs service on cvsserve2 in pserver mode.
initialize repository on /home/users/cvsroot by using "cvs -d /home/users/cvsroot init"
connect to cvsserv2 from eclipse using anonymous access to do a test checkout.
I am failing on step6 with the error message "no such repository". What am I doing wrong?
UPDATE
I tried to change the above method, by adopting this http://mazanatti.info/archives/67/ and I was partially successful.
At step 3 (as in that link), after initializing repo on cvsserv2, I copied my repository to /var/lib/cvsd/project1, overwriting CVSROOT folder. Now, after finishing all steps, I was able to connect successfully. However, when I try to check out, I don't see any branches. When I tried to Refresh Tags, I receive the following error:
What is going wrong?
Ok. I figured this one out. For those who might encounter this issue again, here's how I managed to identify and fix it:
Eclipse's cvs client sucks - it doesn't give you much information. (I could be wrong, may be it writes some debug info to eclipse log file - still, I think that error message should have been more descriptive). Anyway, I obtained TortoiseCVS and attempted a checkout and it failed with an error message on the lines of -"failed to obtain dir lock in repository `/home/cvsroot/foo'. This is not the exact message, but it was something like that.
So, all I had to do, was go into my cvs dump from cvsserv1, look for references to that directory (which is a valid path on cvsserv1 but not cvsserv2). I found a reference to it in config file under CVSROOT folder. It was assigned to a property called LockDir. This property was referring to a /home/cvsroot/foo on the older server as a lock directory. All I had to do was comment out this property and restart cvsd. Everything started working just fine after this!
Our SVN administrator is on holidays, and I need to add a new user to subversion.
We're using Collabnet Subversion on a RedHat box.
I've found the CollabNet_Subversion/conf/ directory with all the configuration files, including an auth file that I can see contains all our users and the groups that they belong to.
All our users need to log in with their LDAP credentials, so I don't need to change any of that.
It looks something like this:
company_auth_production
`[groups]
it-leads = jsmith, hsimpson, pgriffin
it-all = ajolie, rwitherspoon, #it-leads
[/]
* =
[prod:/]
#it-all = rw
`
So I added the new user and restarted subversion. But that doesn't seem to have done the trick. Am I missing something else ? Thanks
a. You have mention that there is "company_auth_production" file. Please check if there is some other authorization file, probably "authz". Can you please provide more information on this.
As per the structure in your file
[prod:/]
#it-all = rw
should have given the read write access to all the users of "it-all" till the path "prod".
b. If this is not working then please try using "VisualSVN Server". It has a very nice gui to add users and give them priviledges also.
Hope this helps.
In your apache Configuration is usually a require directive (eg "require group" or "require user"). Often there is a specific group which user has to belong to access svn (eg svnusers, etc...)
I am try to installing Drupal-6.2.4 on XAMP. I created db named drupal_6_2_4 and when installation process reaches at Database configuration step it does not create tables into supplied db and just reload the page.
The solution was to edit the settings.php file, putting in my database information manually. Just look for this line:
$db_url = mysql://username:password#localhost/databasename;
And change the username, password and databasename parts.
Then return to the Database Configuration screen, enter the information again and continue. The correct database information will be read from the settings file and the configuration will continue to the next step.
And one think more before try this first try to add the user permissions to the folder, /sites/default may be it solve the problem.
Happy hunting!
You can find the file in below path
sites/all/default/setting.php
There you can edit the below things manually
Host
Database name
Username
Password
I'm using git and Codebase for a project.
I just did a test and I'm able to commit to the git repository with a different email address and name set which causes it to tag the commit as being by a different user. I pushed this to the repository and it showed up as that user having committed even though it was me.
Is there a way to prevent users from committing or pushing with someone else's user details (effectively so they can't "forge" commits as being from a different user)?
Edit:
I assume this authentication would need to happen at the stage of pushing commits to the server since in the local working copy it's simply a repository which the user has full access to, to do whatever they want with. Is this therefore something I should ask Codebase about maybe?
Edit 2:
Git config as requested:
(repo/.git/config)
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git#codebasehq.com:<redacted company name>/<redacted project name>/test.git
[branch "master"]
remote = origin
merge = refs/heads/master
Ooops: While this is a valid technique, it assumes you have effectively full control over the server. If you're using a hosted solution all bets are off.
You can validate the author name and email in the repository's update hook. You can get both values like this:
#!/bin/sh
set -- refname sha1_old sha1_new
author_name=$(git log --pretty=format:%an $sha1_new)
author_email=$(git log --pretty=format:%ae $sha1_new)
The trick, of course, is figuring out whether or not these are valid. Here's one trick:
You can use the command="" option in your ssh configuration to make a wrapper around git-receive-pack that maps ssh keys to author information. For example, something like this:
#!/bin/sh
GV_AUTHOR_NAME="$1"
GV_AUTHOR_EMAIL="$2"
export GV_AUTHOR_EMAIL GV_AUTHOR_NAME
eval exec $SSH_ORIGINAL_COMMAND
And you would use an authorized_keys line something like this:
command="~/bin/gitvalidator 'Lars Kellogg-Stedman' 'lars#seas.harvard.edu'" ssh-rsa ...
The result of all this is that your update script would have the environment variables GV_AUTHOR_NAME and GV_AUTHOR_EMAIL available, and could check these against the commit and exit with an error if they didn't match.
Sorry my post got deleted before I submitted my latest update:
You can commit as someone else when you have their credentials.
Just to clarify, the scenario you are asking about is as follows:
Users Foo and Bar can commit to the repo. You want to prevent user Foo from committing to the repo as user Bar.
In this case, user Bar would have to protect their private SSH key, just like they would protect a password. As that is used to authenticate your commit.