Bug 140297
| Summary: | Remote logins from terminals trash utmp entries | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Sean Bruno <sbruno> | ||||
| Component: | gdm | Assignee: | Ray Strode [halfline] <rstrode> | ||||
| Status: | CLOSED UPSTREAM | QA Contact: | |||||
| Severity: | low | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 3 | CC: | beltrami, mattdm | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i686 | ||||||
| OS: | Linux | ||||||
| URL: | http://www.pastebin.com/122175 | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2006-10-31 05:04:31 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Update from today, you should be able to do this with any two machines running an X server. Just have them connect to the login manager(gdm in my tests) on the third, server macine. We resolved this issue by ensuring that the hostname of the terminals was less than 16 characters in length. There appears to be something "wonky" occuring when the hostname is a full name like "tek4066.metro1.com" instead of "tek4066" If you want to close this issue, go ahead. Hi, This bug is being closed because it has been in the NEEDINFO state for a long time now. Feel free to reopen the bug report if the problem still happens for you and you can provide any information that was requested. Created attachment 114311 [details]
Patches session scripts of gdm
(In reply to comment #3) > Hi, > > This bug is being closed because it has been in the NEEDINFO state for a long > time now. Feel free to reopen the bug report if the problem still happens for > you and you can provide any information that was requested. Hi Ray, Sean was right in the fact that the problem is caused by a DISPLAY name of more than 16 chars. I traced this problem down to the sessreg program call in the /etc/X11/gdm/PreSession/Default and /etc/X11/gdm/PostSession/Default scripts. Perhaps the more elegant solution were to patch the sessreg program, but I builded an rpm (attached in srpm format) that patches those scripts. Simply put, it sustitutes the "... -l \"$DISPLAY\" ..." command line parameter in the invocation of sessreg, by "... -l \"`echo $DISPLAY | cut -d. -f1`\" ..." Wishing that this were useful to bring a solution to this problem, thank you for reopen this bug. Best regards, José Luis Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you! I no longer have anyway to test this. I'm not sure why this is in a NEEDINFO state as I was pretty clear where the specific error is and I don't see any requests for Information in any of the comments. In addition, I see a 'me too' comment so I'm not sure that anyone has actually fixed this. And finally, since it's under FC3 and that is long since gone, my last comment would be to say that it probably impacts your RHEL4 customers and should be looked into. Well, Comment #6 put it in NEEDINFO attempting to ask whether or not the issue still shows up in a fully supported release of Fedora Core (FC5 or FC6). There are hundreds of open bugs originally filed against FC3, which is no longer supported except for security updates, that have no comment indicating whether they are still present in FC5 or FC6. Many have been fixed, whether upstream or not, without the bugs getting closed. It takes a rather long time to go through every bug individually and verify it, so some people, like Matt, go through and make mass updates to the FC3 bugs (and other old bugs) asking people to verify if the issue still exists. I'm sorry that "If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release" was not an obvious enough request for information. In the case of this bug, it appears fixed on FC6/ At least, there does not appear to be a sessreg call in /etc/gdm/PostSession/Default and /etc/gdm/PreSession/Default (though the comments still refer to it), nor is there a reference to $DISPLAY in there. I'm not sure *when* it was fixed, though. |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 Description of problem: I am experiencing a strange user login reporting issue and it seems to be way above my head. Let me describe the system first and then explain the problem. I have a dual-processor server(DELL PE 2650 in case you care) that is acting as an NFS/TFTP/DHCP/GDM server for a couple of hundred NCD Tek Terminals(Multiple Models and types). The users login to the terminals so that they can run a Java call center application and take phone calls. Initially, the terminals came up on the same IP network as the server itself and all was good. Recently, this design was changed slightly. Now there is a 2nd IP address assigned to the same physical adapter on the server. So there is a eth0 and an eth0:0 ... This IP address is on a seperate network specifically assigned for these terminals and is non-routeable. The issue I am seeing is a strange behaviour to wtmp/utmp wherein the users don't show up as being logged in via "w" or "who" The only user to show up, is the last user to login. Also, normal user logins who get desktops and other terminal applications that are different from the operator login show up just fine as well. Here is an example of a "good" server's output from "w": 14:10:08 up 105 days, 14:29, 11 users, load average: 0.08, 0.02, 0.01 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT eda01 tek01:0 tek01 Thu 2pm 0.00s 47:15 3.49s /usr/java/j2sdk1.5.0/bin/java eda31 tek31:0 tek31 12:02pm 0.00s 47:15 3.40s /usr/java/j2sdk1.5.0/bin/java eda05 tek05:0 tek05 7:42am 0.00s 47:15 3.30s /usr/java/j2sdk1.5.0/bin/java eda04 tek04:0 tek04 12Nov04 0.00s 47:15 2.12s /usr/java/j2sdk1.5.0/bin/java sean pts/4 oscar 2:09pm 0.00s 0.05s 0.01s w eda21 tek21:0 tek21 Sat 4pm 0.00s 47:15 3.18s /usr/java/j2sdk1.5.0/bin/java eda12 csr-12-p csr-12-pdx Fri10pm 0.00s 47:15 3.51s /usr/java/j2sdk1.5.0/bin/java As you can see, there are muliple users of the username "edaXX." These are the operators who are logged in and using the system. And here is the output of "w" from a "bad" machine, "bad" being a server that has the 2nd IP address assigned to the same physical network adaptor: 17:13:43 up 11 days, 17:01, 13 users, load average: 0.22, 0.26, 0.27 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT eda4181 tek4181. tek4181 4:54pm 0.00s 2:05m 4.15s /usr/java/j2sdk1.5.0/bin/java rtcdr2 pts/0 - Tue11am 3:40m 3.24s 3.24s ssh -t cdruser.33.3 /metr ssteele pts/2 - Sat10am 30:39m 34.86s 34.86s acd rtcdr2 pts/4 - Tue11am 5days 11.71s 11.71s acd nanc pts/6 - Mon 5pm 3days 10.88s 10.88s ssh -t cdruser.33.3 /metr sean pts/3 oscar 5:13pm 0.00s 0.05s 0.03s w ade pts/9 small Thu11pm 2days 0.03s 0.03s -bash rtcdr2 pts/5 - 12:26pm 4:47m 0.07s 0.07s ssh -t cdruser.33.3 /metr jyang pts/1 apollo Sat 3pm 25:30m 0.25s 0.25s -bash ssteele pts/7 - Sat10am 2:27m 3.69s 3.69s ssh -t cdruser.33.3 rtcdr2 pts/11 - Sat 4pm 24:42m 28.70s 28.70s acd cotti pts/12 quasi Fri 3pm 2days 0.02s 0.02s -bash rtcdr2 pts/13 - Sat 4pm 21:28m 5.49s 5.49s ssh -t cdruser.33.3 /metr Here there is only one "edaXX" user logged in and if another operator logs in, the user "eda4181" will dissappear from the "w" output and be replaced by a different operator. I am very confused here why the IP addressing scheme of the machine would have this type of effect on utmp/wtmp login reporting...Any clues folks? UPDATE: Well, even a more confusing piece of information...It appears that the "last" command functions exactly as it should, i.e. showing proper login/logout history...So where does this point to? UPDATE2: After some discussions on IRC, I need to clarify the fact that there are TWO seperate networks configured on the same physical network adapter. This is the key to the problem. If I configure two different physical network adapters, the issue goes away. If I run the entire thing off of one IP/Network adapter, the issue goes away. Version-Release number of selected component (if applicable): Unknown How reproducible: Always Steps to Reproduce: 1. Configure a system to serve up terminal services to NCD type Tek terms. 2. Configure a secondary network interface on the primary(and only) network adapter. 3. Log into two different terminals and check the output of "w" Actual Results: The last person to login successfully will be the only user to show up in the output of "w" Expected Results: All logins reported correctly Additional info: Not really a "high" priority issue here folks, it just caught me off-guard the other day when I was checking my operator logins on some machines and only one operator showed as logged in.