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