Hide Forgot
Description of problem: I cannot seem to get user@domain formatted user names to work on IPA clients where there is an AD Trust. I'm trying to log in to a console for a VM using virt-manager opened console using an AD user. I'm able to use different formats for user name but, expect the user@domain format to work. Version-Release number of selected component (if applicable): mingetty-1.08-5.el6.x86_64 How reproducible: always? Steps to Reproduce: 1. Setup IPA Server and client with trust to AD domain 2. open console to IPA client 3. log in using user@domain Actual results: Pressing @ sends kill or delete to remove everything before the @ (which is username portion). Expected results: Even if it requires additional config, I expect to be able to type in a user@domain formated username to cover cross domain trusted users. Additional info:
There is no such code in mingetty which could erase the input. It reads per character from line-buffered file descriptor 0. That means any line editing is handled by your terminal. Could you explain what's `console to IPA client'? I cannot reproduce your bug on linux virtual terminal running in qemu virtual machine with guest kernel 2.6.32-328.el6.x86_64 (Fedora 17 host running: qemu-kvm -hda /home/petr/virtual/rhel-6.4.disk -boot c -net nic,macaddr=00:50:54:00:0a:64 -net tap,ifname=taprhel6_4x86,script=no -vga std -m 1024 -smp 2). I believe the issue you observe is some funky escaping of your terminal used to access the console line of your RHEL machine.
Interesting. I guess I just assumed it was related to the same thing we see in agetty. My IPA client is a KVM guest running on an F16 host with these versions: $ uname -a Linux spoore-desktop 3.3.8-1.fc16.x86_64 #1 SMP Mon Jun 4 20:49:02 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux $ rpm -qa|grep -i virt libvirt-client-0.9.6.1-1.fc16.x86_64 libvirt-python-0.9.6.1-1.fc16.x86_64 virt-manager-0.9.1-3.fc16.noarch python-virtkey-0.50-9.fc15.x86_64 virt-viewer-0.4.1-3.fc16.x86_64 virt-manager-common-0.9.1-3.fc16.noarch python-virtinst-0.600.1-1.fc16.noarch libvirt-0.9.6.1-1.fc16.x86_64 Now, I just checked on a RHEL6 KVM host and I do not see the same behavior. So, I tried a blanket yum update and reboot with no luck. I've now got: $ uname -a Linux spoore-desktop 3.6.2-1.fc16.x86_64 #1 SMP Wed Oct 17 05:30:01 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux $ rpm -qa|grep -i virt virt-manager-0.9.4-1.fc16.noarch libvirt-python-0.9.6.3-1.fc16.x86_64 libvirt-client-0.9.6.3-1.fc16.x86_64 python-virtkey-0.50-9.fc15.x86_64 virt-viewer-0.4.1-3.fc16.x86_64 libvirt-0.9.6.3-1.fc16.x86_64 virt-manager-common-0.9.4-1.fc16.noarch python-virtinst-0.600.3-1.fc16.noarch If it makes a difference, here's how my VM is running: # ps -ef|grep kvm|grep rhel6-3 qemu 4349 1 7 09:59 ? 00:00:29 /usr/bin/qemu-kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name rhel6-3 -uuid a6f0c9a0-e225-9e3d-0372-1d75c66116fa -nographic -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/rhel6-3.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -drive file=/data/VirtualMachines/rhel6-3.img,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=29 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:50:b4:06,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -usb -device usb-tablet,id=input0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 Note, that I also saw the same behavior when I tried with virsh console before the upgrade/reboot. Is there anything set in the environment that could help indicate what's causing @ to behave like that?
I'm not expert in qemu, but I can see two device you defined: (1) charmonitor which connects host's unix socket with guest's monitor, (2) charserial0 which connects host's pty with guest's serial line. Which one do you use for agetty session? How do you control the host's device? With `screen' tool? With 'cu' tool? With other tool? This can answer where the `@' character translation occurs. These tools usually have some escape sequences which can mangle your input. Also qemu itself puts a control layer (see `-chardev' option in qemu manual). Also it can happen that settings of guest's serial line discipline and hosts's line discipline can mismatch resulting in misinterpretation. And finally the `@' can translate any layer on your host. E.g. X11, or toolkik like GTK+ etc. I did not used any of the two devices. I used SDL window interpreting VGA memory of the guest (`-vga std' qemu option) accessing Linux virtual terminals. Because you confirmed this issue does not depend on guest system and thus not on mingetty running in the guest, I reassign this report to qemu component.
That is seemingly just the resulting default setup when using virt-install? I've got no other problems using @ in terminal windows from my desktop environment. Now, I believe you're onto something about the options possibly being the cause of my problems. I was able to boot using this and had no issues there: [root@spoore-desktop ~]# qemu-kvm -boot c -vga std -m 1024 -smp 1 -drive file=/data/VirtualMachines/rhel6-3.img,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 So, QEMU team, any suggestions on how I can fix this for my default guest setup?
Moving to libvirt because virsh console is handled there (comment 3).
(In reply to comment #6) > Moving to libvirt because virsh console is handled there (comment 3). Scott, are you using virsh console with a serial console on a headless VM or a virt-manager graphical console? It sounds from the bug description like the latter.
Dave, I tested both with virt-manager graphical console and with virsh console against the same VM. Is there a way to modify/re-configure how libvirt starts guests and sets up their serial device? Thanks, Scott
(In reply to comment #8) > I tested both with virt-manager graphical console and with virsh console > against the same VM. That's an important datapoint--those methods use different means to transmit data to the VM, which makes me strongly suspect the problem lies elsewhere than in the virtualization stack. Have you talked to the IPA folks about what you're seeing?
Yes, it was actually a discussion between the IPA Devs about agetty's handling of special characters (@ being one of them) that led me here. The issue occurs before enter is ever pressed to enter the username. The moment I press @ everything to that point is erased. It should also be noted that I was able to use qemu-kvm to directly log in using that type of username@domain convention. I had to leave out a lot of options compared to what I see normally. This is what I did that worked (and seems to indicate not a problem with authentication): yum install tunctl tunctl -u `whoami` -t vnet2 ip link set vnet2 up brctl addif virbr0 vnet2 qemu-kvm -boot c -vga std -m 1024 -smp 1 -drive file=/data/VirtualMachines/rhel6-3.img,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -net nic,macaddr=52:54:00:50:b4:06 -net tap,ifname=vnet2,script=no Also, it may be unrelated but, after upgrading my box to the latest rpms, my consoles are all garbage. Any way to reset/fix that since I can't test right now?
Created attachment 638729 [details] example python console script See if connecting to the serial console using the attached script makes any difference.
Trying the consolecallback.py script, I just realized I'm not logging in on a virtual console that's using mingetty. I'm logging in directly to serial console using agetty. That is known behavior. So, I guess I need to move the component here to agetty.
FYI: Last login: Sun Nov 4 09:43:02 from 192.168.122.1 [root@rhel6-1 ~]# w 11:25:56 up 1 day, 19:33, 2 users, load average: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root ttyS0 - 11:25 0.00s 0.08s 0.05s w root pts/0 192.168.122.1 Sun09 28.00s 0.31s 0.31s -bash [root@rhel6-1 ~]# ps -ef|grep tty root 1363 1 0 Nov03 tty1 00:00:00 /sbin/mingetty /dev/tty1 root 1365 1 0 Nov03 tty2 00:00:00 /sbin/mingetty /dev/tty2 root 1368 1 0 Nov03 tty3 00:00:00 /sbin/mingetty /dev/tty3 root 1370 1 0 Nov03 tty4 00:00:00 /sbin/mingetty /dev/tty4 root 1372 1 0 Nov03 tty5 00:00:00 /sbin/mingetty /dev/tty5 root 1374 1 0 Nov03 tty6 00:00:00 /sbin/mingetty /dev/tty6 root 6993 1446 0 11:25 ttyS0 00:00:00 -bash root 7012 6993 0 11:26 ttyS0 00:00:00 ps -ef root 7013 6993 0 11:26 ttyS0 00:00:00 grep tty But, agetty isn't running right now because I logged in and it turned control over to bash? So,I log out and confirm from another window: [root@rhel6-1 log]# ps -ef|grep get root 1363 1 0 Nov03 tty1 00:00:00 /sbin/mingetty /dev/tty1 root 1365 1 0 Nov03 tty2 00:00:00 /sbin/mingetty /dev/tty2 root 1368 1 0 Nov03 tty3 00:00:00 /sbin/mingetty /dev/tty3 root 1370 1 0 Nov03 tty4 00:00:00 /sbin/mingetty /dev/tty4 root 1372 1 0 Nov03 tty5 00:00:00 /sbin/mingetty /dev/tty5 root 1374 1 0 Nov03 tty6 00:00:00 /sbin/mingetty /dev/tty6 root 7052 1 0 11:27 ttyS0 00:00:00 /sbin/agetty /dev/ttyS0 115200 vt100-nav root 7055 4581 0 11:27 pts/0 00:00:00 grep get There it is...so, not a mingetty or libvirt issue but, I'm seeing the known behavior for agetty. Thanks everyone for help here so far and sorry for the wild goose chase.
Ok, so, I had built the guest with virt-install using --nographics. So virt-manager was forced to use console display to serial when I tried opening a window there. I added a VNC device to the guest and restarted and switch to the graphical console. Using that I am able to switch from tty1 to 2 to 3 and so on. So that would be using the mingetty's. And on those I am able to use user@domain and it does NOT delete user the moment I hit @. So it works as expected there too. So, with serial console using agetty and agetting known to treat @ as a special character, I think this goes back to RHEL and component changed to util-linux-ng. Version:: [root@rhel6-3 ~]# rpm -q util-linux-ng util-linux-ng-2.17.2-12.8.el6.x86_64 Is it possible to get a configurable parameter for agetty to disable special treatment of @? Thanks again everyone that helped here.
(In reply to comment #14) > Is it possible to get a configurable parameter for agetty to disable special > treatment of @? Well, it's pretty unexpected Linux username... Posix: 3.429 User Name A string that is used to identify a user; see also User Database . To be portable across systems conforming to POSIX.1-2008, the value is composed of characters from the portable filename character set. The <hyphen> character should not be used as the first character of a portable user name. 3.276 Portable Filename Character Set The set of characters from which portable filenames are constructed. A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 . _ - I can add option like agetty --disable-spec-chars "#@", but agetty is only one component of the system. Are you sure that the rest of the system will be happy with the user@domain?
Karel, This is to support users like Windows Active Directory users logging in when a server is setup in an IPA environment where a cross realm/domain trust exists with the AD domain. In that case, users have to log into the linux systems (IPA clients) with adusername.name. Is there a config that can have an option? I'm just wondering how the agetty run for the serial console will be configured to use that option you listed. Thanks, Scott
(In reply to comment #17) > Is there a config that can have an option? I'm just wondering how the > agetty run for the serial console will be configured to use that option you > listed. /etc/initttab (or getty@.service stored somewhere within the systemd universe on RHEL7)
That would work. I don't suppose we could request that as a default for Fedora/RHEL too? Or would we just have to deal with that separately for cases where IPA/SSSD need to allow user@domain users? Thanks, Scott
Well, for RHEL6 it would be better to not change any default behaviour. For Fedora/RHEL7 we can disable the chars by default. We (I and Suse) have discussion about it at upstream mailing list, I'm going to inform you about the final decision.
The upstream commit cb872ac99d66247496af14bf30605536d279a759 add new command line options --erase-chars and --kill-chars to specify (or disable) additional chars. This patch could be backported to RHEL6, then agetty --kill-chars '' in the inittab file will disable '@' (the current default) as kill char. This change is backwardly compatible. For RHEL7/Fedora we can also apply upstream commit 5676f36563cb1e7d46067631f08bc1456bbf6736 to disable the old defaults at all. So the new command line options don't have to be specified. This change is not backwardly compatible.
Karel, Do you know yet when this might make it into RHEL? Thanks, Scott
> Do you know yet when this might make it into RHEL? RHEL6.5 and RHEL7. It's too late for RHEL6.4.
Understood. Thanks!
Since this made it into F19, does that mean it'll make it into RHEL7 only or is it still targeted for 6.5 as well? Thanks, Scott
The new command line options are also expected in RHEL6.5 (but without the change in the default behaviour -- see comment #20 and comment #21).
Great. Thanks.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1648.html