ALT+[0-9] in xterm not directly passed to irssi

Occasionally, I seem to run into oldgrown bugs, which haven’t been resolved in years now. Since I started to use irssi within screen again, I ran into the infamous “ALT+[0-9] is not passed directly via xterm to irssi” problem again – I do remember having that some years back too when trying to switch channels in irssi.

Resolving that issue is rather simple, if you don’t care about possible side effects within xterm itsself.

$ vim ~/.Xresources

XTerm*eightBitInput: false
XTerm*metaSendsEscape: true

To activate it for the current X session, run

$ xrdb $HOME/.Xresources

and then start xterm again, connect to your box, attach the screen, try to switch between irssi channels with ATL+[0-9].
Works like a charm!

Update 2012-12-16: Putting those options directly into /etc/X11/app-detaults/XTerm(-color) makes them the default systemwide.

using x2go as remote desktop alternative

x2go is a remote desktop server and client package, partly based on the nx program, but not compatible. Yet there are package repositories for all valuable distributions.

Following this guide, add their debian repository.

# apt-key adv --recv-keys --keyserver keys.gnupg.net E1F958385BFE2B6E
# vim /etc/apt/sources.list.d/x2go.list

# X2Go Repository
deb http://packages.x2go.org/debian squeeze main
# X2Go Repository (sources)
deb-src http://packages.x2go.org/debian squeeze main
# apt-get update
# apt-get install x2go-keyring
# apt-get update

Install the server, plus the xsession package if you already got a desktop environment running (like me having KDE running).

# apt-get install x2goserver x2goserver-xsession

x2go uses the nxclient libs, which requires sort of a local proxy for ssh, listening on port 30001. This must be enabled in your firewall, otherwise you will get messages in syslog like this

sshd connect_to localhost port 30001: failed

Create an entry in your iptables filter and reload it.

# x2go
-A INPUT -p tcp -m tcp -s 127.0.0.1/32 --dport 30001 -j ACCEPT
-A INPUT -p tcp -m tcp -s 127.0.0.1/32 --dport 30002 -j ACCEPT
-A INPUT -p tcp -m tcp -s 127.0.0.1/32 --dport 30003 -j ACCEPT

Using ssh keys for authentication is rather tricky, and got a lot of session errors. So if you run into that, leave it – bug hell.

resize/extend logical volume

First, get an idea on the available space on the volume group.

# vgdisplay

Then check the logical volume which requires more space.

# lvdisplay

Once found the settings, do the actual resizing. Keep in mind that lowering the size of a lv might cause trouble!

# lvextend -L22G /dev/System/var
# resize2fs /dev/System/var

samba 3.6 changes security defaults using client ntlmv2 auth, incompatible to 3.4

Samba 3.6.x changed the security defaults, which affects the smbclient as well. The root cause is that a current ubuntu-like 3.6.3 revision cannot login onto a 3.4.x based samba server.

It always hits an error like this (pretty misleading, as the user exists, and the password is entered correctly).

$ smbclient //share.host/sharename -U youruser
Enter youruser's password:
session setup failed: NT_STATUS_LOGON_FAILURE

$ smbclient -V
Version 3.6.3

The source of that can be read on the Samba Changelog

Changed security defaults
-------------------------

Samba 3.6 has adopted a number of improved security defaults that will
impact on existing users of Samba.

 client ntlmv2 auth = yes
 client use spnego principal = no
 send spnego principal = no

The impact of 'client ntlmv2 auth = yes' is that by default we will not
use NTLM authentication as a client.  This applies to the Samba client
tools such as smbclient and winbind, but does not change the separately
released in-kernel CIFS client.  To re-enable the poorer NTLM encryption
set '--option=clientusentlmv2auth=no' on your smbclient command line, or
set 'client ntlmv2 auth = no' in your smb.conf

Fixing this for the smbclient is not using the commandline option (does not work for me), but generally within the smb.conf (not within any section like [global], but really global in the first place!)

$ sudo vim /etc/samba/smb.conf

client ntlmv2 auth = no

Then we are lucky again.

$ smbclient //share.host/sharename -U youruser
Enter youruser’s password:
Domain=[SHARE] OS=[Unix] Server=[Samba 3.4.x]
smb: >

Update 2012-08-06: You can also put the complete string “domainusername” in order to compete with the changed auth.