Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My situation: I set up an Ant build process on a suse server, and multiple developers have access to the server. There is only one user defined for the build process, so all the devs use that build user - things get a little messy when the automated emails come out to everyone but nobody knows who the build messages are for.

I'd like to capture the username (or the workstation name) of the remote user that was used to trigger the build process. I'm looking at the "last" command but there's one drawback: it seems to log "" as the remote login if someone uses VNC to connect to the graphical login, so I'm sort of stuck on this part.

Can anyone recommend something for this situation?

share|improve this question

The key to successfully resolving this issue is to use proper security. It will cost your users very little and will save you from pulling out your hair. Each user should have their own login or if ant has the capability, the build jobs should be submitted remotely with a user id of some sort attached.

I would also disable VNC for all uses except administration. This is a server after all. If the users need GUI access, they should do it through X which will allow multiple users to have access and offload the GUI onto their end.

However, if your VNC server logs, or can be made to log, the source of its connections, then you can grep that and try to match things up.

share|improve this answer
Could explain on how you might 'use proper security'? – Joseph Holsten Nov 10 '09 at 15:41
Each user should have their own login. That is one of the Ten Commandments of computer security. – Dennis Williamson Nov 10 '09 at 19:16

Two thoughts:

First, I'm mostly with Dennis Williamson on this one. This problem could be avoided by either setting up unique logins for everyone & having the logins source a common / shared environment, or by having the developers check the code out & build locally. Maybe that second part isn't feasible due to hardware or whatnot.

You might consider a remote build tool. Remote Ant (rant) has the advantage of being open source and super easy to setup or modify if you need to. I like simple. Downside, little support, so if you're waiting for the developer to upgrade it - well don't hold your breath. There is a remoteant in the server tasks portion of ant-contrib also.

It would be pretty easy to pass the local to the suse server through the remote ant task.

share|improve this answer

You must log in to answer this question.