Hostname aliases at user level

jgombos · 02-03-2009, 01:45 AM

The scenario is that an administrator creates hostnames that are lengthy and unpronouncable. How can users workaround this? Apparently the users ~/.rhosts file cannot be used to create aliases.

The best option I can think of is environment variables. Eg. export scooby='jaoiwja234'. What I don't like is having to type a $ sign every time I reference it.

anomie · 02-03-2009, 10:41 AM

Are DNS CNAME recs an option? This is not at the user level, but it may solve the problem.

e.g.

Code:

%host easy.your.domain
easy.your.domain is an alias for sfdhsdf3424234.your.domain.

jgombos · 02-03-2009, 02:39 PM

The problem is that the admins are not interested in user friendly hostnames, and do not intend to cooperate. So the mission is to create user friendly names with user priviledges. I know if there were admin support, there would probably be a dozen reasonable ways to do this.

It's a shame that the ~/.rhosts file cannot be used for this purpose.

anomie · 02-03-2009, 02:55 PM

My next suggestion, then, is adding /etc/hosts entries for each user. That is going to be a big hassle with lots of users.

e.g.

Code:

%grep easy /etc/hosts
# The following 'easy' entry is used to resolve
# 'easy' to sfdhsdf3424234.your.domain's IP. 
10.5.5.5         easy.local       easy

There may be a more elegant way to map a friendly name to an unfriendly (DNS rec in your case) name, but I'm not sure I know what that is.

jgombos · 02-04-2009, 12:21 AM

Quote:

Originally Posted by anomie

My next suggestion, then, is adding /etc/hosts entries for each user. That is going to be a big hassle with lots of users.

That requires admin rights, so it's not an option.

anomie · 02-04-2009, 12:51 PM

I don't think I need to tell you this, but the customer support relationship seems to be badly broken in your situation. If there is a strange technical requirement (i.e. long, bizarre hostnames) that is preventing users from doing their jobs, there should be appropriate remediation -- not some user-level hack job.

---

Anyway, another technical suggestion to fix this organizational problem: Give some more details about the services the users need to access. There may be application-level ways to work around the problem.

For shell users who ssh to a few different servers, for example, you could set up a script and alias to it.

Code:

$ cat ~/.my-scripts/ssh-resolver.sh 
#!/bin/sh

case "${1}" in

  'host1'  ) exec ssh sfdhsdf3424234.your.domain ;;
  'host2'  ) exec ssh xxbbxdf3424234.your.domain ;;
  'host3'  ) exec ssh yyyzzaf3424234.your.domain ;;
  *        ) echo "Usage: ${0} host[n]" ; exit 1 ;;

esac

exit 0

Code:

$ alias ssh='~/.my-scripts/ssh-resolver.sh'