Why is subversion using system-name as username when running as system user? - maven

This has got me the whole day digging for answers. The bottom line is that when I run svn as system user it seems to use the system-name to authenticate against the SVN server regardless of what credentials are passed. Following is the long explanation that made arrive at that conclusion.
When running from a Windows 7 Professional, if I run svn from the console under any normal user, the application works as expected: if credentials have been cached in %AppData%/Roaming/Subversion it will use them, if not it will prompt for username and password unless I use the options --username and --password. If I enter credentials using the options then the commit works with no problem. All good so far.
But when I try to run svn as the system user (nt authority\system) in the same computer, it behaves differently. To begin with, %AppData%/Roaming/Subversion points to C:\Windows\System32\config\systemprofile\AppData\Roaming\Subversion, and I make sure there is no auth folder there, so no credentials cached. Then I run svn without any parameters and it doesn't prompt for username/password, instead it executes the action and receives an error from subversion:
svn: E175013: Commit failed (details follow):
svn: E175013: MKACTIVITY of '/svn/Development/!svn/act/f20db493-48f1-9c43-a957-541584be555e': 403 Forbidden (http://<ip-address>)
If I run it indicating --username and --password, it gets the same error. But then I check the error logs from subversion and find this:
[Fri Aug 08 17:32:18 2014] [error] [client <client IP>] Access denied: '<clienthostname>$' MKACTIVITY Development:
[Fri Aug 08 17:32:18 2014] [error] [client <client IP>] Access denied: '<clienthostname>$' DELETE Development:
Where <clienthostname> is the hostname of the computer where I'm trying to commit from (note the '$' at the end of the subversion log, that's not part of the hostname but it does appear in the log as part of the username).
So that's the question: why is svn behaving differently when running as system user? Why does it use the hostname as username when authenticating against the SVN server? And why do other users work correctly?
Note: I believe my problem is different from the following questions in stackoverflow:
Subversion ignoring “--password” and “--username” options: I don't get any prompts to enter username and password, regardless of whether I indicate the options --username and --password or I don't
SVN Error when commiting Access denied: 'foobar' MKACTIVITY MYREPO: I saw this question and I tried double checking the case of all the items in the URL, no luck.
svn: MKACTIVITY 403 Forbidden: I have checked that no credentials are cached in %AppData%/Roaming/Subversion
For those who are wondering why I'm trying to run svn as system user, the answer is that I am trying to make a commit from TeamCity, which means it is the Build Agent the one executing the svn command. The Build Agent is a Windows Service and runs as system user, and the svn command fails in the way explained above.

Use the "--no-auth-cache" in your svn commands and you won't see this issues. You might however run into other set of issues.
If you do not use the no-auth-cache it tries to figure out default username and password anyways
A better way would be to create a .subversion folder and store the authentication in that folder. So for the system account, you can specify a differrent userid and password for the login.

Related

Why can't I use a diffrent user for SVN checkout

I trying to make SVN work on a Windows 2016 Server. I am using SVN over commandline. SVN is always using the user which is logged in. Let's say the logged in user is USER. The user needed for SVN is called SVNUSER. We are using a VisualSVN Server. Both Servers are inside a company network and they use the same AD for authentication.
I tried following stuff:
svn checkout --username SVNUSER http://svn01.de/svn/Application/trunk/FSW
or
svn checkout --username e102365 --password pass http://svn01.w3.de/svn/Application/trunk/FSW
didn't work. I get following error:
svn: E175013: Unable to connect to a repository at URL 'http://svn01.de/svn/Application/trunk/FSW'
svn: E175013: Access to '/svn/Application/trunk/FSW' forbidden
The serverlog says i tried to connect with USER.
The only way I was able to make the checkout work is using run as with the SVNUSER but I need it for automation and run as is interactive so it does not help.
The folder C:\Users\USER\AppData\Roaming\Subversion\auth is empty. When using tortoise SVN it says there is no saved authentication.
I assume that your VisualSVN Server installation is configured for Integrated Windows Authentication (Active Directory Single Sign-On) (see KB182 for details).
Since it's Single Sign-On, you have to run your scripts as the user account that has permissions to access the repository. Specifying credentials in the command-line won't work - it will always authenticate as the user account who started the svn.exe client. You can try running your script from Windows Task Scheduler, custom Windows Service, etc.
Or you can enable Basic Windows authentication on the server in addition to Integrated Windows Authentication. And force your svn client to always prefer Basic auth (i.e., disable Integrated Windows Authentication on the client side). You can append the following option to your svn.exe commands:
--config-option servers:global:http-auth-types=basic
Or modify the %APPDATA%\Subversion\servers file. Add the http-auth-types=basic string under [Global].

Could not add identity "": agent refused operation on windows server 2012

Im using Open SSH and trying to use ssh-add on windows server 2012 but keep receiving the following error
Could not add identity "C:\Users\SERVICE_ACCOUNT/.ssh/id_rsa": agent refused operation
I have made sure all my permissions are intact with all files within C:\Users\SERVICE_ACCOUNT.ssh
Icacls C:\Users\SERVICE_ACCOUNT\
C:\Users\SERVICE_ACCOUNT\ NT AUTHORITY\SYSTEM:(OI)(CI)(F)
CP\SERVICE_ACCOUNT:(OI)(CI)(F)
Icacls C:\Users\SERVICE_ACCOUNT\.ssh
C:\Users\SERVICE_ACCOUNT\.ssh CP\SERVICE_ACCOUNT:(OI)(CI)(F)
I have tried ssh-add using a different user on my windows and im able to successfully do so without any issues, i have also made sure that the permissions for the other user match my service account as well

Linux: Agent Side Checkout fails - Perforce password (P4PASSWD) invalid or unset

Using Team City 2017.1
I am unable to use Agent Side checkout with my Ubuntu 14.04 build agent due to the following error:
[2017-06-22 13:41:12,779] INFO - jetbrains.buildServer.VCS.P4 - Running p4 login for user myUserId in [P4Port: redacted-server-address:1666; P4User: myUserId; perforce client mapping with 1 rules, VCSRoot: "ETG" {internal id=170}]
[2017-06-22 14:07:38,029] INFO - jetbrains.buildServer.VCS.P4 - Creating P4 workspace TC_p4_LinuxBuildAgent1_964e0a7b4154cd8c_85d77afe3e61a99a
[2017-06-22 14:07:38,225] INFO - jetbrains.buildServer.VCS.P4 - Creating/updating Perforce client specification:
Client: TC_p4_LinuxBuildAgent1_964e0a7b4154cd8c_85d77afe3e61a99a
Owner: myUserId
Description:
Created by TeamCity for user myUserId.
Root: /home/someuser/BuildAgent/work/964e0a7b4154cd8c
Options: noallwrite clobber nocompress unlocked nomodtime rmdir
Host: ubuntu
SubmitOptions: revertunchanged
LineEnd: local
View:
//ETS/GE_DEV/Build/... //TC_p4_LinuxBuildAgent1_964e0a7b4154cd8c_85d77afe3e61a99a/...
[2017-06-22 14:07:38,436] INFO - jetbrains.buildServer.VCS.P4 - Running p4 login for user myUserId in [P4Port: redacted-server-address:1666; P4User: myUserId; perforce client mapping with 1 rules, VCSRoot: "ETG" {internal id=170}]
[2017-06-22 14:07:39,016] WARN - l.patch.AbstractSourcesUpdater - Error while checkout on agent: Perforce password (P4PASSWD) invalid or unset. - while running 'p4 -c TC_p4_LinuxBuildAgent1_964e0a7b4154cd8c_85d77afe3e61a99a -u myUserId -p
redacted-server-address:1666 -H ubuntu client -i'
jetbrains.buildServer.vcs.VcsException: Perforce password (P4PASSWD) invalid or unset. - while running 'p4 -c TC_p4_LinuxBuildAgent1_964e0a7b4154cd8c_85d77afe3e61a99a -u myUserId -p redacted-server-address:1666 -H ubuntu client -i'
at jetbrains.buildServer.vcs.perforce.PerforceConnection.runCommand(PerforceConnection.java:271)
at jetbrains.buildServer.vcs.perforce.PerforceConnection.runCommand(PerforceConnection.java:257)
at jetbrains.buildServer.vcs.perforce.PerforceWorkspacesImpl.createOrUpdateWorkspace(PerforceWorkspacesImpl.java:80)
at jetbrains.buildServer.vcs.perforce.PerforceAgentSourceUpdater.createOrUpdateLocalWorkspace(PerforceAgentSourceUpdater.java:99)
at jetbrains.buildServer.vcs.perforce.PerforceAgentSourceUpdater.updateSources(PerforceAgentSourceUpdater.java:68)
at jetbrains.buildServer.vcs.perforce.PerforceAgentSourceUpdater.updatePerforceSources(PerforceAgentSourceUpdater.java:55)
at jetbrains.buildServer.vcs.perforce.PerforceSourceUpdatePolicy.updateSources(PerforceSourceUpdatePolicy.java:66)
at jetbrains.buildServer.agent.impl.vcs.AgentVcsManagerExImpl$CheckoutSupportImpl.updateSources(AgentVcsManagerExImpl.java:108)
at jetbrains.buildServer.agent.impl.patch.ProjectSourcesOnAgent$1.run(ProjectSourcesOnAgent.java:186)
at java.lang.Thread.run(Thread.java:745)
I am fairly certain our Perforce server uses ticket based auth. At the build machine, I can run p4 login (which prompts for password). This is successful and allows me to run p4 client which returns a User specification that includes an "AuthMethod: perforce" (the user specification does not include a "Password:" line).
I have tried a couple of different workarounds including:
Creating a .p4enviro file which includes the P4PASSWD
Setting an environment variable for P4PASSWD (in /etc/environment)
However, these have no effect...
The logs seems strange to me because the login appears to succeed (at least, no errors are logged). But, the checkout fails with the P4PASSWD error.
Also, the VCS root is using a Client mapping (but I have tried it with Client as well - same error is present).
Any help would be very appreciated!
This is resolved thanks to those who added comments above.
This issue was self-inflicted and caused by an entry in rc.local that was issuing the start command to agent.sh (thus causing the build agent to run as root).
If I would have just RTFM, I wouldn't have encountered this issue :)

Cannot connect to local svn server

I am using VisualSVN Server 3.0.1 and TortoiseSVN 1.8. Using VisualSVN Server Manager, I made a repository called "lottery" in my C:\ drive. I started all the VisualSVN Server's services on the machine. I checked VisualSVN Server's HTTP service is running and VDFS service is running. I also made two users harry and sally with password 1234 using VisualSVN Server Manager. I made a directory C:\workdirs. In that, there are two folders harry and sally for my users. When I navigate into harry's folder and run my svn command, I get an error. Please help me to resolve it.
C:\workdirs\harry>svn co --username harry --password 1234 https://james/svn/lottery/
That url is copy pasted exactly from VisualSVN Server Manager. I get the error -
C:\workdirs\harry>svn co --username harry --password 1234 https://james/svn/lottery/
svn: E731001: Unable to connect to a repository at URL 'https://james/svn/lottery'
svn: E731001: No such host is known.
Solutions I tried -
Tortoise won't connect to subversion server
Apparently, you can’t go straight to the SVN folder you need to
include a repository file name in the path.
So, I tried to use the url with port and the repo folder name to see if it helps svn co --username harry --password 1234 https://james:443/svn/lottery/ Btw, james is the name of the svn server i saw in the visual svn server properties.
The resulting error is -
svn: E731004: Unable to connect to a repository at URL
'https://james/svn/lottery'
svn: E731004: The requested name is valid, but no data
of the requested type was found.
Next, I tried to use http instead of https and got the same error.
Next, I tried to use the url like this https://localhost/james:443/svn/lottery/
I got the error -
Error validating server certificate for 'https://localhost:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
- The certificate hostname does not match.
Certificate information:
- Hostname: steam
- Valid: from sometime in 2014 GMT until sometime in 2020 GMT
- Issuer:
- Fingerprint: 6a:7b:8c:....
(R)eject, accept (t)emporarily or accept (p)ermanently? p
svn: E175013: Unable to connect to a repository at URL
'https://localhost/james:443/svn/lottery'
svn: E175013: Access to '/james:443/svn/lottery' forbidden
Finally, I thought of using my computer's IP address as mentioned in the link I gave. I don't know what the IP is, but I tried using localhost instead and it worked !!!
C:\workdirs\harry>svn co --username
harry --password 1234 https://localhost/svn/lottery/
Checked out revision 0.
This worked for me -
svn co --username harry --password 1234 https://localhost/svn/lottery/
I did not have to add a port number after localhost. It works, but I don't know what happened. Btw, make sure that your Visual SVN windows services are running before you run this command.
Your local DNS is unaware about that "james" hostname represents your computer therefore you get the No such host is known error. If you work with VisualSVN Server alone, you could add a reference that "james" is your computer's name to your hosts file.
Otherwise, contact your network administrator and ask about what is your computer's hostname on your LAN.
Go to your project folder Right Click go to your tortiseSvn --> Relocate --> change your svn repository url

TeamCity forgotten admin password - where to look?

I need to recover/reset the admin password for JetBrain's TeamCity.
I have full RDP access to the server so no problems there. It's just been 2 months since we used it so now I have forgotten my login - my usual ones don't work.
It is setup without a database at the moment, so was hoping the usernames would just be in a file somewhere, but no luck finding it so far.
From TeamCity 8 you can log in as a super user and change the password that way. You just need to use an empty username and last occurrence of the "super user authentication token" found in the logs\teamcity-server.log file as your password.
Please see the following for more information:
TeamCity 8 - http://confluence.jetbrains.com/display/TCD8/Super+User
TeamCity 9 - http://confluence.jetbrains.com/display/TCD9/Super+User
TeamCity 10 - https://confluence.jetbrains.com/display/TCD10/Super+User
In case none of those works, see http://sebastienlachance.com/post/Resetting-TeamCity-Password.aspx.
Open a command prompt and go to \webapps\ROOT\WEB-INF\lib folder. Now type the following :
..\..\..\..\jre\bin\java.exe -cp server.jar;common-api.jar;commons-codec-1.3.jar;util.jar;hsqldb.jar ChangePassword username newpassword
For TeamCity 6.5.4
From a command prompt in the [TeamCity install folder]\webapps\ROOT\WEB-INF\lib:
..\..\..\..\jre\bin\java -cp server.jar;common-api.jar;commons-codec-1.3.jar;util.jar;hsqldb.jar ChangePassword admin NewPassword
My username was 'admin' in my case (I think I set it during installation but I can't be sure).
I ommitted the path to TeamCity argument, it's smart enough to use the correct path (mine was c:\users\administrator.BuildServer)
When I provided the (wrong) path to TeamCity as an argument I received this message:
Using TeamCity configuration directory path: c:/TeamCity/.BuildServer
Exception in thread "main" java.sql.SQLException: Table not found in statement [UPDATE users SET PASSWORD = ? WHERE USERNAME = ? AND REALM IS NULL]
at org.hsqldb.jdbc.Util.throwError(Util.java:58)
at org.hsqldb.jdbc.jdbcPreparedStatement.<init>(jdbcPreparedStatement.java:1833)
at org.hsqldb.jdbc.jdbcConnection.prepareStatement(jdbcConnection.java:580)
at ChangePassword.main(ChangePassword.java:14)
In case this confuses other people too.
Super user direct URL :
http://servername:port/login.html?super=1
Open TeamCity log folder (Example C: drive: C:\TeamCity\logs) : teamcity-server.log, find the key: “Super user authentication”
[2019-03-04 12:14:30,770] INFO - jetbrains.buildServer.SERVER - Super user authentication token: `8347518935696887114` (use empty username with the token as the password to access the server)
You could try to reset the installation of TeamCity, by removing TeamCity data directory ($/.BuildServer directory by default)
Try the following:
First stop the TeamCity service (would also stop the build agent if installed).
Next open up a console, go to your java directory and run the following command from there:
java.exe -cp server.jar; hsqldb.jar ChangePassword USERNAME PASSWORD "PATH_TO_YOUR_TEAMCITY_INSTALLATION".BuildServer
I've just had to go through this pain with v5 EAP.
I managed to reset the password successfully by running:
C:\TeamCity\webapps\ROOT\WEB-INF\lib>..\..\..\..\jre\bin\java -cp server.jar;common-api.jar;commons-codec-1.3.jar;util.jar;hsqldb.jar ChangePassword admin password c:\TeamCity\.BuildServer
Although you'll need to substitute C:\TeamCity with wherever your installation is located.
In case this helps someone else, whoever installed TeamCity on my server placed the build directory under the Administrator's Profile, not in C:\TeamCity.
Specifically for TeamCity running on Tomcat on Windows it will be C:\ProgramData\JetBrains\TeamCity
The directory specified as the last parameter needs to be your Data Directory (find in /logs/teamcity-server.log)
You'll get the 'Table not found' error if you don't have this correct.
You'll get a 'The database is already in use' error if you've got TeamCity running.
you can also search you /logs/teamcity-server.log to see whether you created admin, administrator, or some other admin user name.
For everyone that may arrive at this article years after the original answer like I just did, there's a built-in super user account, and the password is regenerated every time team city is started, and the password is in the log. You can use this super user to login and reset any passwords. It's super easy.
https://confluence.jetbrains.com/display/TCD9/Super+User
TeamCity always uses a database - if you haven't explicitly configured one, it uses a HSQLDB database to store data internally.
When using an external database, user information is stored within that database, so it seems pretty likely that the user information in your case will be stored within the HSQLDB system.
You might be able to gain access to the system by futzing around with the database - but I'd suggest taking a backup first.
Second suggestion - drop the support guys at JetBrains an email. Even before my workplace splashed out on a TeamCity Enterprise license, their support was superb - fast, accurate and helpful.
With TeamCity 5 using MySQL (probably other versions and RDBMs as well, but untested), it's possible to update the password directly via SQL:
mysql> update users set password = md5("mypass123") where username = "bob";
Nevertheless, I'd stick with the CLI versions already mentioned by others if there isn't a good reason not to do so.
First point is if you logout the login screen has the username 'TCAdmin' already filled in, when it should be 'administrator'. TCAdmin is the full name of (I think) the default version 5 admin user. Changing that to administrator and then using the password I thought it was solved my issue.
For resetting...
In case it helps someone else on Windows XP on version 5 of TeamCity, my .BuildServer config info was also under my current logged in user's documents and settings folder. Also I was tripped up by a space in the list of jar files in Sebastien's good answer above.
So I changed to this directory in a command prompt:
c:\teamcity\webapps\ROOT\WEB-INF\lib
and then this command line (to set password: Password1) worked for me:
C:\TeamCity\webapps\ROOT\WEB-INF\lib>..\..\..\..\jre\bin\java.exe -cp server.jar;commonapi.jar;commons-codec-1.3.jar;util.jar;hsqldb.jar ChangePassword administrator Password1
Which gave output:
Using TeamCity configuration directory path: C:/Documents and Settings/tamw/.BuildServer
Password changed successfuly
Stop teamcity
You should pass path to your buildserver
e.g. if you installed build server to dir "c:\.BuildServer"
........\jre\bin\java.exe -cp server.jar;common-api.jar;commons-codec-1.3.jar;util.jar;hsqldb.jar ChangePassword username newpassword c:\.BuildServer
To change user password:
Shutdown server
Switch to the /webapps/ROOT/WEB-INF/lib directory
Invoke the following command:
Windows platform:
java -cp server.jar;common-api.jar;commons-codec-1.3.jar;util.jar;hsqldb.jar ChangePassword
Unix platform:
java -cp server.jar:common-api.jar:commons-codec-1.3.jar:util.jar:hsqldb.jar ChangePassword
You can skip the option, if you are using default path for TeamCity data files: /.BuildServer
[Ref: http://confluence.jetbrains.com/display/TCD7/Changing+user+password+with+default+authentication+scheme]
Here's what worked for me.
Shut down server services
> cd c:\TeamCity\webapps\ROOT\WEB-INF\lib>
then
> ..\..\..\..\jre\bin\java.exe -cp server.jar ;common-api.jar;commons-codec-1.3.jar;util.jar;hsqldb.jar ChangePassword admin password1 C:\ProgramData\JetBrains\TeamCity\
Without the path at the end, it would fail with:
Exception in thread "main" java.sql.SQLException: Table not found in statement [
UPDATE users SET PASSWORD = ? WHERE USERNAME = ? AND REALM IS NULL]
at org.hsqldb.jdbc.Util.throwError(Util.java:58)
at org.hsqldb.jdbc.jdbcPreparedStatement.<init>(jdbcPreparedStatement.ja
va:1833)
at org.hsqldb.jdbc.jdbcConnection.prepareStatement(jdbcConnection.java:5
80)
at ChangePassword.main(ChangePassword.java:14)
We are using Teamcity 7 with MS SQL Server as the RDBMS.
To reset your password you can use the following query:
UPDATE users SET password = LOWER(SUBSTRING(sys.fn_sqlvarbasetostr(HASHBYTES('md5','your_new_password')),3,32))
where username = "your_user_name";
Alternatively, You could use the TeamCity Server Log and retrieve the Super User token.
Using the token, go to the URL : http://(server):(port)/login.html?super=1
ie: http://localhost:92/login.html?super=1
Once you logged in, you could always create a new user or reset the password for the account in question.
I passed in the same situation and did login with super user, follow steps below:
1 - Get Token in the "teamcity-server.log" in the path "XX:\TeamCity\logs";
2 - Access and login using token at url: "/login.html?super=1";
More about it:
https://confluence.jetbrains.com/display/TCD18/Super+User

Resources