running identd

[pmoreno]

Hello, I would like to know how can I know if my OS is running identd.. I looked up using ps auxc and didn't find it. My real problem is that I'm unable to do telnet to the server I have an account in my University. The admin told me that identd could be the problem, the server closes the connection before I can log in.. any ideas???

thanx
Pablo

[W3iRd0]

Use this command in the Terminal:
ps -ax | awk '/identd/ {print $1}'
It searches all processes that are running and returns a process id number if a process name matches the name between the /'s.
-------------
[localhost:~] addi% ps -ax | awk '/Omni/ {print $1}'
879
-------------

A nice alias for future use would be:
alias alias-name "ps -ax | awk '/\!*/ {print $1}'"
Usage:
alias-name name-to-search-for
-------------
[localhost:~] addi% az.ps Omni
879 ?? S 8:21.06 /Applications/OmniWeb.app/Contents/MacOS/OmniWeb -psn_0_7077889
-------------

[mervTormel]

pablo,

rather than using weirdo's new and improved ps (now more draconian!), you just want to _find_ the process in your process table.

try:

% ps aux | grep inetd
root   282   0.0  0.0     1288    116  ??  Ss     0:00.00 inetd
merv 18516   0.0  0.0     2332    304 std  R+     0:00.01 grep inetd

grep is the 'find x in y' command, so your piping the output of the ps command (y) into the input (y) of the grep command, looking for inetd (x)

this grep _may_ find the inetd process owned by root, but it _will_ find itself, that is, its own entry in the process table (grep inetd)

yeah, i know, it's draconian vs. euclidean-self-referencial-chromosome-husbandry, but the chance of a typo or blindness is less. let's give pablo a break.

anyhow, if your inetd isn't found, you've got bigger problems than resolving your telnet to your campus server.

let us know.

[pmccann]

Hey mT,

that'd be identd, not inetd (it's an authentication daemon as distinct from a forking bloody superdaemon!). And it *is* available in the standard osx install (unless someone snuck it onto my machine behind my back...).

% locate identd

/usr/libexec/identd
/usr/share/man/man8/identd.8

(From the man page: )
------------------------------------
DESCRIPTION
identd is a server which implements the TCP/IP proposed
standard IDENT user identification protocol as specified
in the RFC 1413 document.

identd operates by looking up specific TCP/IP connections
and returning the user name of the process owning the con-
nection.
------------------------------------

Just a quick "watch out" : using ps -aux to find processes is fine, but it has a distinct tendency to miss things when you grep for them due to the fact that the final field is truncated. You can bet I'm running Internet Explorer to post this (warts and all...: IE's warts, of course, I'm a wart free zone!), yet entering:

ps -aux| grep -i explorer

returns a big zippo. Here are two ways around this: use ps -ax as given above (ie don't bother with the extended info provided by the u flag, giving more room for the command at the end of the line), or --my choice-- use

% ps -wwaux

instead. That spews as much garbage as needed across your terminal window. If you're satisfied with 132 columns of output you can just use a single "w" in there. The output is ugly if you're just cruising through it all, but if you're greppin' you want to be greppin' on the full text (aside: "grepping" is clearly wrong: it just sounds ugly... the word just has to be "greppin'").

I must admit to trying to find a case where -wwaux would work but -ax would shorten the full path so as not to grep the application name, but short of cheating (by rearranging my /Applications directory significantly) I couldn't manage it. Ah well....

Cheers,
Paul

[Novajo]

Look for a line that starts with ident:

ident stream tcp wait root /usr/libexec/tcpd identd -w -t120

If there is a # in front, it is disabled. If there isn't, it gets started by inetd automatically when required. ident will actually run only a short amount of time. The ps tricks above will not help you unless you are doing it while getting an ident request, which is highly unlikely.

In the stock configuration of OS X, it is disabled:

# The following are not known to be useful, and should not be enabled unless
# you have a specific need for it and are aware of the possible implemications.
#
#exec stream tcp nowait root /usr/libexec/tcpd rexecd
#ident stream tcp wait root /usr/libexec/tcpd identd -w -t120

I doubt this is your problem. ident is not required for connection.

[mervTormel]

Quote: that'd be identd, not inetd

paul, thanks for the knuckle-whack. will you be my dyslexia goggles?

all, sorry for the noise.

i grok the double wide ps, yer right, greppin' for a process oughta get the whole text of the line.

--
"Awk, I should probably get a grep on UNIX two," he sed.

[pmccann]

Damn, just pressed "go" for the previousl message and thought "hmm, didn't the original poster actually ask about running identd Paul?". So how you do dat? And now I just got an email message telling me navajo has trumped my post! With good advice, no less, and a comment re telnet that made me reread the original post: identd is not going to be your problem unless the setup is the wackiest I've heard of. Are you sure that it wasn't "inetd" that was mentioned? Even then, that's only relevant if the problem is *listening to incoming connections* and will have zero influence on connecting to your university host machine.

Oh well, bombs away re identd, for future reference. I'll stir in a few other bits and pieces for someone's amusement. I should warn anyone starting this journey that it's a long rambling road, and the end is far from pretty.

First guess (because I certainly don't run identd): turn it on via /etc/inetd.conf and check it's in /etc/services (done: it's there, port # is 113)

So I look in /etc/inetd.conf to see if it's already available (but commented out, like everything else) and yep, there she is: makes "interesting" reading... (never heard of implemications until now, but see later on in this post, perhaps them implemications are *real bad*!)

# The following are not known to be useful, and should not be enabled unless
# you have a specific need for it and are aware of the possible implemications.
#
#ident stream tcp wait root /usr/libexec/tcpd identd -w -t120

Ouch! Over to the original poster... If you do decide that this is where you want to head I initially thought that it's a simple matter of uncommenting the final line above in /etc/inetd.conf, and checking that you're allowing the hosts concerned to access this service. Have a look at

man 5 hosts_access

for the gory details of that side of things. In fact the details are quite fun, but also quite involved. The good news --given that this is ostensibly a newcomers forum(!)-- is that the default access permissions on osx are "anyone from anywhere can access this service once it's turned on", subject to the usual firewall provisos of course.

In any case, I thought that the final thing you'd need to do is to kick inetd oh-so-gently in the guts: let's pretend that's true for a couple of minutes. First find it...

% ps -ax|grep inetd|grep -v grep
215 ?? Ss 0:00.00 inetd

The leading number (here 215, yours will almost certainly differ!) of the output is the process ID (PID) of inetd. We need to send it a "hangup" signal in order to get it to reread its configuration file:

% sudo kill -HUP 215 ####<<----- enter your number here, not 215!!
password: ****(enter your user password)

That can undoubtedly be done in one line, and that grep -v grep is *really ugly* (it just takes any process that contains the word "grep" out of the results found; the -v flag means "anything but entries containing the following pattern"). For what it's worth you can replace it with something a little more cryptic, but still a bit ugly: a passable party trick!

% ps -ax|grep "[ ]inetd"
215 ?? Ss 0:00.01 inetd # LOOK MA, NO "grep -v grep"!

To get just the first bit of the output here (ie the PID, here 215) we can use the "cut" function, in particular cutting characters 1-5 via:

% ps -ax|grep "[ ]inetd"|cut -c 1-5
215

So a one line version of sending inetd a HUP signal would be:

% sudo kill -HUP `ps -ax | grep "[ ]inetd" | cut -c1-5`
password: ******

[[LOOK AGAIN MA, NO PROCESS ID REQUIRED]]

Update: interesting and enlightening though the above construction is, inetd is there ahead of us. There's a little file /var/run/inetd.pid that contains the current PID. So the machinations above in this case reduce to some variation of the piddling

sudo kill -HUP `cat /var/run/inetd.pid`

That would be "HUPping for wimps" then?

Moving along, around and underneath...: the identd daemon *should* now crank into action when required: it won't be running all the time, but it shouldn't need to be. That's what inetd is for; it listens for incoming connections, logs them (if requested, via tcp wrappers), and passes off the connection to the appropriate daemon, starting it if required. Hence it's a "superdaemon", or maybe "metadaemon". If the identd daemon so started is idle for 2 minutes (cf the 120 in the line from /etc/inetd.conf above) it'll wave goodbye to a cruel and fickle world.

Enough for now! [[Or so I hoped. But foolishly I thought I should try and put my words into practice, and get the daemon running. That shouldn't be hard!

So I followed my advice, and then tried to see whether anything had worked. identd should come up and say hello from a telnet to port 113: that is,

telnet 127.0.0.1 113

But all I got was "connection refused", as if authorization to connect was lacking, or maybe inetd wasn't kickstarting identd. Hmm. Lots of head-scratching and I had what I thought was an aha moment: it doesn't know where the executable lies. "identd" is not enough. So, feeling a bit smug, I modified my /etc/inetd.conf to include the full path to identd: /usr/libexec/inetd Harumph: no dice again. In fact, I think it *should* be able to find identd "in the buff". But it didn't. And dressing it up in its Sunday best, full path glory didn't help either.

Given this further stumbling block I tried starting the daemon from the command line via

# /usr/libexec/inetd.conf -b -t 120 &

as the man page notes, and there she was: for an instant. Connection successful, but before I could find what information to request from him the daemon died with a bus error. Ow! Damn, seems you can't have any space between the -t and the 120? Yes! Now he works, but working out what numbers to feed the beast was proving, errr, tricky! I *did* get it to tell me that the auth daemon to which I was connected was started by root. Hmm, not much help! For some strange reason a telnet connection to the auth daemon is not being listed by "netstat -a".

So I think I'm about to pull the plug on this project. Bright ideas welcomed and entertained. Not to mention "needed". I have a strong suspicion that there's something "fistinctly ducked" here.]]

Moral of this post: know your daemons, and feed your superdaemon with the respect it deserves! One day he might even behave.

Hope there's something of interest for someone in the above mess in any case.

Sincere apologies to any newcomers reading this post. It's totally inappropriate for this forum. If you've got any questions I'm very happy to do my penance.

Cheers,
Paul (who just heard that horrible clicking of his hard drive that tells me it must be 3.15am, and /etc/daily is running. "Praying for sleep and it never comes: it never works that..... way". Free perl-based answer to your favourite unix data transformation problem for first respondent who correctly identifies the source of the quote in the previous sentence. Damn: google makes it easy! And it's NOT bloody "Paradise by the Dashboard Light"!!!)

[mervTormel]

lambchop, let's go bowling, sorry, but i'm a lambchop fan.

did you know that "soaky in the pooper" is a euphemism for suicide? well, it is now!

[pmccann]

OK, you get half a solution as your prize! The band is right, but you're hooked on the wrong album! Back to "How I Quit Smoking" with you, and more particularly "Life's little tragedy". But colour me impressed: you didn't even (have to) cheat. No surprise re "Soaky...";

http://www.geocities.com/Nashville/O...opelyrics.html

Cheers,
Paul, totally off-topic and blaming the hour (if not the sunshine, the moonlight, the good times, or the boogie. Ah... "Thriller" (slightly sic, but without the chunky bits))

On topic for unix newcomers: this is a perfect illustration of what happens when you stay up too late trying to conquer something that you really had not interest in running in the first place; brain and mush are indistinguishable. Another victory for the unix gods, who are obviously Greek, and out hunting hubris tonight. Long may they feast.

[mervTormel]

arg! wouldn't you know it! my ganked mp3 tags are wrong! back to allmusic.com to patch 'em up by hand since cddb sites flat out refuse to offer anything resembling useful.

that geocities/nashville/opry link is ker-broken. i wonder what that was?

anyhow, this thread has deteriorated completely, but that's okay. thanks for your beautiful/ugly post, paul. i'll tuck that away for a rainy day.

combat naps for both of us.

[level9]

Am I missing something? It seemed like all he wanted to know is how to enable identd, but I kinda got lost in all the code 'n stuff.
If so:

# The following are not known to be useful, and should not be enabled unless
# you have a specific need for it and are aware of the possible implemications.
#
#exec stream tcp nowait root /usr/libexec/tcpd rexecd
auth stream tcp wait root /usr/libexec/tcpd identd -w -t120

Change "ident" (the first word of the last line) to "auth" and you're good to go.

[pmccann]

You're not missing much, but he only "sorta" wanted to open up identd. That is, only if it would fix his telnet connection to university.

But you are still my hero! The service name has to match: I still would swear blind that I traversed the entire set of permutations of service names the other night in the midst of battle, but given that I just tried again --albeit on my old work machine, from which I am typing-- the time to concede defeat through a glorious victory has arrived. [Hmm, still a bit puzzled: it's entirely possible something's fishy on my home machine, given that I did try what should be an equivalent operation without any success: I changed the name for port 113 tcp in /etc/services to "ident". More later if there's anything even vaguely interesting to add.]

For anyone thinking of trying this: don't forget to HUP inetd afterward, as explained above.

In short, thanks level9.

Paul

[pmccann]

This thread caused me a lot of grief, so I thought it'd be worth exhuming now that I know what was going wrong. A thread on darwin-dev gave the game up: someone mentioned that the new development version includes some warning lines in /etc/services, indicating that it's not used by OSX in normal operations (or something to that effect). The same sort of thing that you get when you look in /etc/passwd.

So my changing /etc/services so that the service name matched the name in /etc/inetd.conf was *not* equivalent to level9's very level suggestion of changing the entry in /etc/inetd.conf As is so often the case in OSX the keyword here is "netinfo": it stores its own copy of the services, so to make the changes I made to /etc/services active I'd have to load them into the netinfo database for my machine. Which would require something akin to

# niload services . < /etc/services

(Note that little hash at the start of the line, indicating rootly powers are present: of course you could simply preface the line with a "sudo".)

So I guess this message is purely intended to make myself feel like less of an idiot (having reread the above!!), and to prevent anyone else from running into the same level of frustration that I experienced while trying to track down what was going wrong. ((Answer: documentation shortfalling!))

OK, we need some pertinent lyrical insertion here: from an oldie but a goodie...

"Wandered up a cul de sac,
and now you've come back"

Cheers,
Paul