Questions[teamcity](server)

I'm trying to run a TeamCity (default) build agent with 32-bit java on ubuntu 64-bit, I have created a [TeamCity]/bin/setenv.sh what contains:

JAVA_HOME=/usr/lib/jvm/ia32-java-6-sun

That works fine running the server with 32-bit jre, but not for the agent: I've tried these lines in [buildAgent]/conf/buildAgent.properties

JAVA_HOME=/usr/lib/jvm/ia32-java-6-sun
JRE_HOME=/usr/lib/jvm/ia32-java-6-sun/jre

and also a '[buildAgent]/jre' link

[buildAgent]/jre -> /usr/lib/jvm/ia32-java-6-sun/jre/

when I do a '[TeamCity]/bin/runAll.sh start' I get this:

Using CATALINA_BASE:   /srv/TeamCity
Using CATALINA_HOME:   /srv/TeamCity
Using CATALINA_TMPDIR: /srv/TeamCity/temp
Using JRE_HOME:        /usr/lib/jvm/ia32-java-6-sun
Using CLASSPATH:       /srv/TeamCity/bin/bootstrap.jar:/srv/TeamCity/bin/tomcat-juli.jar
Starting TeamCity build agent...
Java executable is found in '/usr/bin/..'.
Starting TeamCity Build Agent Launcher...
Agent home directory is /srv/TeamCity/buildAgent
Current Java runtime version is 1.6
Lock file: /srv/TeamCity/buildAgent/logs/buildAgent.properties.lock
Using no lock
Done [16436], see log at ../logs/teamcity-agent.log

As you can see from the output, the server is using 32-bit jdk, but the build agent is running the java found in '/usr/bin' (which is 64-bit in my case).

Closer inspection of the '[buildAgent]/bin/findJava.sh', it looks like the script runs a 'which java' and finds the default system java before it even tries any of the supplied args/folders. I think it should find '[buildAgent]/jre' before the system java.

Whats the correct way to specify the java version to use for a build agent, which may be a different version than the server?

Should I just modify findJava.sh to check its arguments before checking the system path for java?

I've successfully installed TeamCity ib CentOS 6.2 Minimal. I'm stuck on trying to run a script automatically on system startup:

/opt/TeamCity/bin/teamcity-server.sh start

I've googled around and tried various methods all of which seems to fail. Most of the methods points to adding the startup script to one of the rc.local files:

/etc/rc.d/rc.local
/etc/rc.local

And the contents of rc.local contains the line:

/opt/TeamCity/bin/teamcity-server.sh start

None of which will start the teamcity server

There are no problems if i run the script manually.

Seems simple but how do i get a shell script to auto run?

My team uses TeamCity for continuous integration. It will build, test and deploy web applications via Web Deploy to dev and qa web servers. The tricky part is deploying to a production web server - our policy dictates that developers cannot deploy to production, only a system administrator can.

Our current approach is to have TeamCity build a web deployment package, which the administrator can download and install on the production web server. However, we'd like to allow them to simply click "Run" on a build configuration, but we're not sure how to secure that button.

We could create a TeamCity project that only administrators have access to, but we also have to address Web Deploy security. The Web Deploy service needs to be authenticated with a local admin account on the production server. We don't want developers having access to the username/password in a build script, nor do we want every build agent running as this account since developers could create a build that uses it to deploy to production.

I've haven't had much luck finding resources on TeamCity security/deployment best practices, but I can't imagine we're the only company in this situation. How do others manage automated deployment security?

We have an IIS 7 webserver configured and would like to create a reverse proxy for a TeamCity installation using Tomcat on the same machine.

The IIS server site is https://somesite and I would like the TeamCity to appear as https://somesite/teamcity redirecting to http://localhost:portnumber.

I have installed the IIS URL Rewrite extension and the Application Request Routing to try and setup a reverse proxy but can't get it working.

The closest answer I found is an old StackOverflow question: https://stackoverflow.com/questions/331755/how-do-i-setup-teamcity-for-public-access-over-https
which unfortunately doesn't have any working example.

I've searched a quite a bit but can't seem to find a relevant example.

Any help is appreciated!

After two full days of "research" (read: banging my head against my keyboard) and cursing at TeamCity/MSDN/Tomcat documentation as well as phantom IIS bindings, I've come up with an answer to a very perplexing issue: How can I change TeamCity's IP address and port number on a multi-homed server running Windows Server 2008 as well as IIS 7 which is serving a necessary purpose?.

First, a bit of background. Our build server is running Windows Server 2008 with two IP addresses (192.168.1.30 and 192.168.1.31) on one NIC. I've configured IIS to explicitly bind its one and only site to 192.168.1.30 on port 80. At this point I'm thinking that 192.168.1.31 is wide open and ready to be used for TeamCity... not quite.

First annoyance: when installing TeamCity, it completely disregards the fact that there are multiple IP addresses associated with this server asking only which port it should bind to. For server-grade software, this is pretty surprising.

Second annoyance: TeamCity defaults to port 8080 (wha??). Due to the first annoyance, the port selection is somewhat ambiguous: is TeamCity going to bind to port 8080 on both IP addresses? Changing the port selection to 80 yields a warning that another service is already bound to port 80. Hmm, IIS should only be bound to port 80 on 192.168.1.30; nothing should be bound on 192.168.1.31. Obviously TeamCity is competing with IIS on 192.168.1.30.

Finishing TeamCity's installation, after choosing port 80 and ignoring the binding warning, I open up "C:\TeamCity\server.xml". Sidenote: "C:\TeamCity\" is the default installation directory for TeamCity while "C:\Users\.BuildServer" is the default data directory. Anyway, "server.xml" is the configuration file where you can set things like the port and IP address of TeamCity's web interface. After a bit of research I come up with the configuration for binding the IP address 192.168.1.31 on port 80:

Look for either

<Connector
    port="8080"
    protocol="HTTP/1.1"
    connectionTimeout="20000"
    redirectPort="8443" />

or

<Connector
    port="80"
    protocol="HTTP/1.1"
    connectionTimeout="20000"
    redirectPort="8443" />

depending on the port you chose during installation. Change either to (note: change the IP address!)

<Connector
    port="80"
    protocol="HTTP/1.1"
    connectionTimeout="20000"
    redirectPort="8443"
    address="192.168.1.31" />

Should be as easy as that, right... right? Well, restarting TeamCity's Web Server (via Windows' Services Manager) yields nothing on 192.168.1.31. Ugh.

It turns out that even though IIS's one and only site has been explicitly bound to 192.168.1.30 on port 80, IIS still listens on all IP addresses. This, of course, throws off TeamCity's Web Server (Tomcat) which halts before even coming online. After manually starting Tomcat from the command-line to dissect its stdout error and even more research, I happen upon this little gem from StackOverflow: How can I control which IP address IIS7 uses?

So, from an Administrative command line I run (note: again, change the IP address! This time to the IP address that you want IIS to be bound)

netsh http add iplisten ipaddress=192.168.1.30

Now I restart TeamCity's Web Server and voila, it works!! I can browse to 192.168.1.31 without having to specify a port number and TeamCity's web interface comes up. A quick sanity check shows that IIS is still correctly bound to 192.168.1.30. All is well.

Sorry for the long post for such a simple fix. I hope this helps someone else as it sure would have saved me hours of aggravation.

Edit: After using TeamCity for a while, I noticed that the Build Agent which had been installed with TeamCity was not being recognized correctly. To fix this, I had to point the Build Agent to the new URL for TeamCity. This configuration change is done in "C:\TeamCity\buildAgent\conf\buildAgent.properties". Again, this is the path for a default install of TeamCity and might be different depending on how you customize your installation of TeamCity.

Inside "buildAgent.properties" make sure "serverUrl" points to the new TeamCity URL. In my case, I updated it to:

serverUrl=http\://192.168.1.31

After making this change, restart both TeamCity Web Server and TeamCity Build Agent.