get IP address on login

[Brian K. White]

On 12/6/2011 10:45 AM, Robert T. Repko (R Squared Consultants) wrote:
> SCO Unix 5.0.7
> Is it possible to identify the IP address of someone when they log
> in?  I have remote users logging in and running filePro.  Their
> printer is setup during login.  Up to this point the same person
> always logged in from the same remote site.  I was just informed that
> a person would be logging in from 2 different locations.  Since they
> are coming in through a VPN their LAN IP address gets logged in to
> syslog.  I would like determine their LAN IP address during login and
> assign the printer based on their IP (ie: location).

1) Passthru printing makes this a non issue. The server side 
code/actions are always the same regardless if the user is local or remote.

but if you must...

2) I do this with a couple of scripts in /etc/profile, "amilocal" which 
uses "tellip" which uses "who".

in /etc/profile add at the bottom:
. /etc/profile.local

create /etc/profile.local containing:
---TOF---
PATH=${PATH}:/u/rr/bin
tty -s || return

amilocal && {
	# user is local
         PFPRINTER=foo
	export PFPRINTER
} || {
	# user is not local
         PFPT=on PFPRTC=hplaser
	export PFPT PFPRTC
}
---EOF---

/u/rr/amilocal:
---TOF---
#!/bin/ksh

# amilocal - "Am I Local?"
# Detects if the user is connecting from inside or outside the local LAN.
#
# Requires "tellip"
#
# Brian K. White - brian at aljex.com - Aljex Software

umask 0
LOGFILE=/var/log/amilocal
LANLIST=/etc/LAN
MYTTY=`tty`
LOGGING=false
VERBOSE=false

for ARG in $@ ; do
     case $ARG in
         -l) LOGGING=: ;;
         -v) VERBOSE=: ;;
     esac
done

$LOGGING && touch $LOGFILE
[ -e $LANLIST ] || grep -v "^#" /etc/hosts >$LANLIST

case "$MYTTY" in
     /dev/tty[1-9]|/dev/tty[012][0-9])
         $VERBOSE && echo "YES: TTY=$MYTTY"
         exit 0
         ;;
     *)
         IP=`tellip`
         grep -q "$IP" $LANLIST && {
             $VERBOSE && echo "YES: IP=$IP"
             exit 0
         } || {
             $LOGGING && print "`date`\t`id -un`\t$IP" >>$LOGFILE
             $VERBOSE && echo "NO: IP=$IP"
             exit 1
         }
         ;;
esac
---EOF---

/u/rr/bin/tellip:
---TOF---
#!/bin/ksh
#
# tellip - "Tell IP"
# prints the IP or Hostname that the user is connecting from.
# mostly used in other scripts to determine non-static addresses.
#
# can be run on SCO, Linux, FreeBSD
#
# Brian K White - brian at aljex.com - Aljex Software

# facetwin screws up "who" so try to use facetwin variable instead.
[ -n "${FACETWINIPADDR}" ] && { echo "${FACETWINIPADDR}" ; exit ; }

# "who" tries to show hostname but chops long names, try to use ssh 
variable.
[ -n "${SSH_CLIENT}" ] && { echo "${SSH_CLIENT}" |awk '{print $1}' ; 
exit ; }

case `uname -s` in
   Linux)  who -m |cut -d\( -f2 |cut -d\) -f1 ;;
   FreeBSD)  who |cut -d\( -f2 |cut -d\) -f1 ;;
   SCO_SV) who -umx | awk '{ print $6 }' ;;
esac
---EOF---

In /etc/LAN put a list of all possible LAN ip addresses.
The code above includes a crude auto create of this by just dumping a 
copy of /etc/hosts, but that assumes that /etc/hosts lists all lan IP's, 
which is one way to fix the 30 second delay during login while 
telnetd/ftpd tries to resolve the clients lan ip in dns, and fails since 
it's not there.

You could also:
ksh
n=1
while [ $n -lt 255 ] ;do echo "192.168.0.$n" ;n=$((n+1)) ;done >/etc/LAN

basically "amilocal" uses "tellip" to get the users IP, and see if that 
ip exists in /etc/LAN. If it does, the user is considered local and 
amilocal exits with 0/true, else amilocal exits with 1/false.

tellip checks a few different things to try to get the users ip as 
reliably as possible. It practically always works but it's not quite 
garanteed.

Daemons that provide login shells decide what ends up appearing in the 
output of "who". FacetWin for instance puts the users windows netbios 
computer name in there. USELESS. But luckily FacetWin also provides an 
environment variable similar to the way ssh does, so, check if the 
special facetwin variable exists, and if it does, use that in preference 
over anything else (exit immediately upon using).

Similarly, sshd provides the clients ip in an environment variable and 
that's more reliable than the output of who, so, if we didn't see a 
facetwin variable, try for the ssh variable and if it's there, use it 
and exit without trying anything else.

Finally, if neither facetwin or ssh variables were found, then the user 
is connecting by telnet or rlogin or something else, in that case try to 
parse the output of who. This is not 100% certain because it may come 
back with an ip address, or it may come back with a hostname derived 
from a reverse dns lookup, which may return a useless ptr record that 
doesn't match any a-record or cname record, or may return a very long 
hostname that "who" chops off in it's output so you don't actually get 
the full correct usable string, BUT, it generally does still work for 
the purpose of simply seeing if the users ip is found in /etc/LAN or 
not. If you needed the users IP to be correct, say for the purpose of 
aiming a print job back at their IP, It's possible in some cases for 
this to fail. But if all you need to do is see if their ip is a lan ip 
or not, that always works, because the local ip's will all resolve from 
/etc/hosts if you list them all in there, so in that way you can ensure 
what "who" looks like at least for all lan ip's even if you can't for 
any other ip's.

There are other ways to ensure the lan ip's always resolve and always 
resolve in a consistent way, like you could be running a local dns 
server either on the sco box or on a windows box on the lan, instead of 
populating /etc/hosts and /etc/LAN with all possible lan ip's. I'm 
assuming neither of those is true.

So the user connects, /etc/profile sources /etc/profile.local,
/etc/profile.local runs amilocal and based on amilocal either defines a 
PFPRINTER to some normal printer, or if amilocal exits false, then sets 
PFPT and PFPRTC to force local passthru printing using hplaser print 
codes, overriding whatever PFPRINTER is defined in fp config.
And of course you can stick other local vs not-local stuff you want in 
between those same sets of curly braces after amilocal.

Also amilocal always considers the console tty's as local and doesn't 
try to find the clients ip in that case since it's n/a.

Also remember to chmod 755 /u/rr/bin/*

-- 
bkw