aef's questions

I am trying to use Certbot to allow for semi-automated certificate updates. I don't want fully-automated updates to avoid automatic certificate replacements that could interrupt business and ensure that a sentient administrator is available when the update is actually done to handle potentially negative consequences. Therefore I need to be able to find out if a certificate is due for renewal in a separate step from issuing the actual renewal.

How can I find out, quickly and without side-effects, if a named certificate managed by Certbot is due for renewal without triggering the renewal itself?

When I issue the renew command, the actual renewal is instantly triggered.

When I use the renew command with the --dry-run flag, the renewal is not triggered, but my authentication plugin is triggered whether the certificate is due or not because it is simulating the authentication. As I use DNS for authentication, actual updates are issued through dynamic DNS and apart of once again tempering with a live system when there might be no administrator on call, this also takes quite a long time on each check because of the slow update propagation speed that is expected of DNS.

As another option I could imagine using the renew command with the -a and the --dry-run flag to select some kind of no-op authentication plugin that doesn't mess with DNS and doesn't take multiple minutes before I get an answer. Sadly Certbot comes with a no-op installer plugin but not with a no-op authentication plugin. Developing such a no-op authentication plugin seems not to be trivial because the interface for authentication plugins seems to require actual Challenge and ChallengeResponse objects to be returned by the plugin of which I currently have insufficient knowledge.

Are there other ways I missed that could solve my problem? Or is there maybe a no-op authentication plugin available somewhere?

I am managing an OpenStack mostly through the openstack CLI and the permissions to manage specific projects and their resources. Is there a command available to me that can tell me the release name or version number of the OpenStack release running remotely on the OpenStack I am managing?

The CLI version is 5.4.0.

Usually it is a good thing that when keepalived shuts down, it releases the virtual IP address (VIP) via VRRP and removes the address from the local interface so that other instances can take it over.

When the last instance of keepalived shuts down, one could argue that if another instance is started at some later point it can take over without causing a conflict.

If however there is only one instance remaining and it is shutdown purely for configuration changes or other maintenance reasons, one could also argue that the VIP should stay up so that connectivity of the services listening on this VIP is not disturbed.

I am looking for a way to shutdown keepalived in a way that doesn't release the VIP and doesn't remove it from the interface. I found a command line flag -V, –dont-release-vrrp which sounds like it could do that job. However, there is no command line utility that manages a running instance and it seems the described flag is supposed to be used on startup of the daemon. This is not what I would want because as described earlier, in most cases releasing the VIP is the intended behavior.

Is there a way to shutdown keepalived while not touching the currently configured VIP and assuming the daemon was not started with the -V, –dont-release-vrrp flag? I imagine a signal interpreted to provoke this behavior, but any idea on how to achieve this would be nice.

Certbot seems to manage X.509 certificates and private keys in its own directory structure in /etc/letsencrypt.

On Debian-based systems (including Ubuntu, Linux Mint and others) X.509 certificates are classically stored in /etc/ssl/certs and private keys in /etc/ssl/private. The certificates are normally world-readable and the private keys are restricted to the ssl-cert group and may also be readable by specific service users.

Is there an established way to make Certbot respect the classic Debian structure? Maintaining links to the classic directories would probably be enough in addition to manage file ownership and group assignment for services.

I could imagine configuration options to do this, but also imagine there might be any installer plugins around for that task, but I just couldn't find anything about this.

Sometimes I would like to use Ansible's lineinfile or blockinfile modules to write a password into some configuration file. If I do so, the whole line or block, password included, ends up in my syslog.

As I don't consider syslog to be a secure place to have my passwords stored in, how can I tell Ansible not to leak my password into syslog? I hope there is a way to do this, otherwise I would consider this to be a big security problem in Ansible.

You can reproduce it for example with this ad-hoc command:

ansible localhost -m blockinfile -a 'dest=/tmp/ansible_password_leak create=yes block="Password = {{password}}"' -e 'password=secret'

Here is what ends up in syslog:

ansible-blockinfile: Invoked with directory_mode=None force=None remote_src=None insertafter=None owner=None follow=False marker=# {mark} ANSIBLE MANAGED BLOCK group=None insertbefore=None create=True setype=None content=None serole=None state=present dest=/tmp/ansible_password_leak selevel=None regexp=None validate=None src=None seuser=None delimiter=None mode=None backup=False block=Password = secret

For the example I used Ansible 2.0.0.2 from the official Ansible Ubuntu PPA on a Debian "Jessie" 8 system.

I am using Check_MK to generate checks to make Icinga (a Nagios fork) monitor a bunch of machines. After starting up Icinga, after some time, Check_MK starts to collect data from the configured machines. The order and the amount of time in between the machines which are checked by Check_MK feels very random and sometimes it takes several minutes until the checks start and even more time until all the machines have been checked once. Also it seems that commanding Icinga to recheck all hosts doesn't start the Check_MK checks.

How can I force Check_MK to process the checks for a specific or all of the configured machines in a way so that Icinga becomes aware of the results instantly after this happens?

The machines run Debian 7 "Wheezy" with Icinga version 1.7 and Check_MK 1.2.2.

Quite a while ago I got an answer telling me how to add a port-forwarding on a running SSH ControlMaster process. To know that helps a lot, but I'm still missing a way to remove such a port forwarding after I don't need that anymore.

As far as I know, you can do that through the internal command key sequence on normal connections, this seems to be disabled for ControlMaster clients. Even if that would be possible I would need a solution which I can automatize with scripts, which is surely not so easy this way.

Is there a way to do it? And is it easily automatizable?

I'm running Debian Wheezy Beta 4 with KVM based guest systems which run the same operating system. I'm using LibVirt to manage the virtualisation.

What I would like to do is to attach an LVM based block device to a running guest system through Virtio. If I would configure it through virsh edit [MACHINE] it would look like this:

<disk type='block' device='disk'>
  <driver name='qemu' type='raw' cache='none' io='native'/>
  <source dev='/dev/volume_group/logical_volume'/>
  <target dev='vdb' bus='virtio'/>
</disk>

I tried to find out how to do this with virsh attach-disk. So far I figured the following:

virsh attach-disk guest /dev/volume_group/logical_volume vdb --driver qemu --type raw --cache none --persistent

How can I specify the target's bus and driver's io field? I really need these options to be exactly as specified in the XML.

I found out a performance problems with a Mumble server, which I described in a previous question are caused by an I/O latency problem of unknown origin. As I have no idea what is causing this and how to further debug it, I'm asking for your ideas on the topic.

I'm running a Hetzner EX4S root server as KVM hypervisor. The server is running Debian Wheezy Beta 4 and KVM virtualisation is utilized through LibVirt.

The server has two different 3TB hard drives as one of the hard drives was replaced after S.M.A.R.T. errors were reported. The first hard disk is a Seagate Barracuda XT ST33000651AS (512 bytes logical, 4096 bytes physical sector size), the other one a Seagate Barracuda 7200.14 (AF) ST3000DM001-9YN166 (512 bytes logical and physical sector size). There are two Linux software RAID1 devices. One for the unencrypted boot partition and one as container for the encrypted rest, using both hard drives.

Inside the latter RAID device lies an AES encrypted LUKS container. Inside the LUKS container there is a LVM physical volume. The hypervisor's VFS is split on three logical volumes on the described LVM physical volume: one for /, one for /home and one for swap.

Here is a diagram of the block device configuration stack:

sda (Physical HDD)
- md0 (RAID1)
- md1 (RAID1)

sdb (Physical HDD)
- md0 (RAID1)
- md1 (RAID1)

md0 (Boot RAID)
- ext4 (/boot)

md1 (Data RAID)
- LUKS container
  - LVM Physical volume
    - LVM volume hypervisor-root
    - LVM volume hypervisor-home
    - LVM volume hypervisor-swap
    - … (Virtual machine volumes)

The guest systems (virtual machines) are mostly running Debian Wheezy Beta 4 too. We have one additional Ubuntu Precise instance. They get their block devices from the LVM physical volume, too. The volumes are accessed through Virtio drivers in native writethrough mode. The IO scheduler (elevator) on both the hypervisor and the guest system is set to deadline instead of the default cfs as that happened to be the most performant setup according to our bonnie++ test series.

The I/O latency problem is experienced not only inside the guest systems but is also affecting services running on the hypervisor system itself. The setup seems complex, but I'm sure that not the basic structure causes the latency problems, as my previous server ran four years with almost the same basic setup, without any of the performance problems.

On the old setup the following things were different:

• Debian Lenny was the OS for both hypervisor and almost all guests
• Xen software virtualisation (therefore no Virtio, also)
• no LibVirt management
• Different hard drives, each 1.5TB in size (one of them was a Seagate Barracuda 7200.11 ST31500341AS, the other one I can't tell anymore)
• We had no IPv6 connectivity
• Neither in the hypervisor nor in guests we had noticable I/O latency problems

According the the datasheets, the current hard drives and the one of the old machine have an average latency of 4.12ms.

I'm running a PowerDNS 3.1 on a Debian Wheezy Beta 4 system. The zone data is accessed through a PostgreSQL database, the server answers to both IPv4 and IPv6 queries.

If the DNS-Server knows the A record for one of the name servers referenced by NS records on a zone, it automatically return these A records as additional information to the response on an NS query for that zone. Now even if it knows the AAAA record for one of the name servers of the NS records, it currently does never return an AAAA record as additional information.

How can I enable this? Or is there anything I could be doing wrong?

Output of dig @ns.mydomain.tld NS mydomain.tld:

;; QUESTION SECTION:
;mydomain.tld.                      IN      NS

;; ANSWER SECTION:
mydomain.tld.               86400   IN      NS      ns3.nsprovider.de.
mydomain.tld.               86400   IN      NS      ns2.nsprovider.de.
mydomain.tld.               86400   IN      NS      ns.mydomain.tld.
mydomain.tld.               86400   IN      NS      ns.nsprovider.de.

;; ADDITIONAL SECTION:
ns2.nsprovider.de.          86400   IN      A       1.2.3.1
ns.nsprovider.de.           86400   IN      A       1.2.3.2
ns.mydomain.tld.            600     IN      A       192.0.2.194
ns3.nsprovider.de.          86400   IN      A       1.2.3.3

Output of dig @ns.mydomain.tld A ns.mydomain.tld:

;; QUESTION SECTION:
;ns.mydomain.tld.           IN      A

;; ANSWER SECTION:
ns.mydomain.tld.    600     IN      A       192.0.2.194

Output of dig @ns.mydomain.tld AAAA ns.mydomain.tld:

;; QUESTION SECTION:
;ns.mydomain.tld.           IN      AAAA

;; ANSWER SECTION:
ns.mydomain.tld.    86400   IN      AAAA    2001:db8:100:3022:1::3

I'm running a Mumble server (Murmur) on a Debian Wheezy Beta 4 (x86_64) KVM guest which runs on a Debian Wheezy Beta 4 (x86_64) KVM hypervisor. The guest machines are attached to a bridge device on the hypervisor system through Virtio network interfaces. The Hypervisor is attached to a 100Mbit/s uplink and does IP-routing between the guest machines and the remaining Internet.

In this setup we're experiencing a clearly recognizable lag between double-clicking a channel in the client and the channel joining action happening. This happens with a lot of different clients between 1.2.3 and 1.2.4 on Linux and Windows systems.

Voice quality and latency seems to be completely unaffected by this. Most of the times the client's information dialog states a 16ms latency for both the voice and control channel. The deviation for the control channels mostly is a lot higher than the one of the voice channels. In some situations the control channel is displayed with a 100ms ping and about 1000 deviation. It seems the TCP performance is a problem here.

We had no problems on an earlier setup which was in principle quite like the new one. We used Debian Lenny based Xen hypervisor and a soft-virtualised guest machine instead and an earlier version of the Mumble 1.2.3 series.

The current murmurd --version says: 1.2.3-349-g315b5f5-2.1

Update: I found this discussion where there are people running Mumble on virtualised system which experience exactly the same problem as I do.

What I have tried so far (without any success at all):

• Installed and tried Mumble server on my hypervisor system
• Installed and tried it with the beta 1.2.4 Mumble server on the guest system
• Vacuumed my SQLite database from it's originally about 1MiB down to about 300 KiB
• Disabled IPv6 on the system to check if that could be a problem source.
• Installed a guest system with Debian Squeeze (stable) and tried Mumble there.

Update: Previously I stated that I had tested putting the Mumble database and log file in a tmpfs in-memory file system and it didn't solve the problem. I made an error there, so it wasn't actually stored inside the tmpfs. Now that I have actually done that, the performance problems are gone. But storing it in a tmpfs is not really a real solution to my problem.

Since OpenSSH 5.4 there is a new feature called natcat mode, which allows you to bind STDIN and STDOUT of local SSH client to a TCP port accessible through the remote SSH server. This mode is enabled by simply calling ssh -W [HOST]:[PORT]

Theoretically this should be ideal for use in the ProxyCommand setting in per-host SSH configurations, which was previously often used with the nc (netcat) command. ProxyCommand allows you to configure a machine as proxy between you local machine and the target SSH server, for example if the target SSH server is hidden behind a firewall.

The problem now is, that instead of working, it throws a cryptic error message in my face:

Bad packet length 1397966893.
Disconnecting: Packet corrupt

Here is an excerpt from my ~/.ssh/config:

Host *
  Protocol 2
  ControlMaster auto
  ControlPath ~/.ssh/cm_socket/%r@%h:%p
  ControlPersist 4h

Host proxy-host proxy-host.my-domain.tld
  HostName proxy-host.my-domain.tld
  ForwardAgent yes

Host target-server target-server.my-domain.tld
  HostName target-server.my-domain.tld
  ProxyCommand ssh -W %h:%p proxy-host
  ForwardAgent yes

As you can see here, I'm using the ControlMaster feature so I don't have to open more than one SSH connection per-host.

The client machine I tested this with is an Ubuntu 11.10 (x86_64) and both proxy-host and target-server are Debian Wheezy Beta 3 (x86_64) machines.

The error happens when I call ssh target-server. When I call it with the -vvv flag, here is what I get additionally:

OpenSSH_5.8p1 Debian-7ubuntu1, OpenSSL 1.0.0e 6 Sep 2011
debug1: Reading configuration data /home/aef/.ssh/config
debug1: Applying options for *
debug1: Applying options for target-server.my-domain.tld
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Applying options for target-server.my-domain.tld
debug1: auto-mux: Trying existing master
debug1: Control socket "/home/aef/.ssh/cm_socket/[email protected]:22" does not exist
debug2: ssh_connect: needpriv 0
debug1: Executing proxy command: exec ssh -W 192.0.2.195:22 gateway-host.my-domain.tld
debug1: identity file /home/aef/.ssh/id_rsa type -1
debug1: identity file /home/aef/.ssh/id_rsa-cert type -1
debug1: identity file /home/aef/.ssh/id_dsa type -1
debug1: identity file /home/aef/.ssh/id_dsa-cert type -1
debug1: identity file /home/aef/.ssh/id_ecdsa type -1
debug1: identity file /home/aef/.ssh/id_ecdsa-cert type -1
debug1: permanently_drop_suid: 1000
Host key fingerprint is 1a:2b:3c:4d:5e:6f:7a:8b:9c:ad:be:cf:de:ed:fe:ef
+--[ECDSA  521]---+
|                 |
|                 |
|                 |
|                 |
|                 |
|                 |
|                 |
|                 |
|                 |
+-----------------+

debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-3
debug1: match: OpenSSH_6.0p1 Debian-3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-7ubuntu1
debug2: fd 5 setting O_NONBLOCK
debug2: fd 4 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "192.0.2.195" from file "/home/aef/.ssh/known_hosts"
debug3: load_hostkeys: loaded 0 keys
debug3: load_hostkeys: loading entries for host "192.0.2.195" from file "/etc/ssh/ssh_known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /etc/ssh/ssh_known_hosts:49
debug3: load_hostkeys: found key type RSA in file /etc/ssh/ssh_known_hosts:50
debug3: load_hostkeys: loaded 2 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
Bad packet length 1397966893.
Disconnecting: Packet corrupt

Update: Now with -vvv instead of only -v output.

I know there is a parameter named ip which lets you configure IPv4 addresses on the Linux kernel through the boot loader. That looks like the following:

ip=192.0.2.1::192.0.2.62:255.255.255.192::eth0:none

I'm looking for an equal parameter for IPv6 configuration. I couldn't find anything about this in the kernel documentations.

Update: Because of a lot of you asked why I would need this: The idea to use a kernel configuration came up related to this problem. I suspect the regular boot-up interface configuration is not done, because the interfaces are already up. The reason for this could be that I'm using a pre-boot environment with a Dropbear SSH server to allow me to unlock my encrypted root partition. The IP addresses for this environment are configured through GRUB with the ip= parameter. There is no DHCP or Router Advertisement available on that Ethernet segment and as this is the uplink segment provided by a large hosting company, there is no way to change that fact.

With the command like these the following you can add neighbor proxies in Linux

ip -6 neigh add proxy 2001:db8:100:3022:1::4 dev eth0

Is there a way how to list which proxies have already been defined?

We recently set up a server on Debian Wheezy Beta 3 (x86_64) which has a native IPv6 connection.

We configured the eth0 interface to get the IPv6 configuration through some post-up hook commands in /etc/network/interfaces. The result is, that after the booting the system up, there is only IPv4 and an auto-configured link-local IPv6 address configured on the interface, as if the command has never been executed.

When we additionally place the commands after the call to ifup -a inside the /etc/init.d/networking init script, everything works as expected and we have a fully configured interface after booting up.

This is quite an ugly way to configure the interface. What are we doing wrong with the ifup post-up hooks? Or is this a bug?

Update: One additional fact is that I'm using a Dropbear SSH server to enable me to unlock my LUKS encrypted root file system. The Linux kernel is therefore given an IP address through the GRUB bootloader. That could mean that the IPv6 configuration is not done because eth0 is already up. I then tried to put an ifdown eth0 before ifup -a line in the /etc/init.d/networking script. It didn't change anything. Here an example of how it looked like:

ifdown eth0
if ifup -a $exclusions $verbose && ifup_hotplug $exclusions $verbose

Update: I set up a little script as post-up hook which configures the interface and writes the output to a log file. The result was that the log file was never written, which means the post-up hook wasn't called at all.

The section from /etc/network/interfaces looks like this (IP-addresses changed):

allow-hotplug eth0
iface eth0 inet static
        address 1.2.3.1
        netmask 255.255.255.192
        network 1.2.3.0
        broadcast 1.2.3.63
        gateway 1.2.3.62
        dns-nameservers 8.8.8.8
        dns-search mydomain.tld
        post-up ip -6 addr add 2001:db8:100:3022::2 dev eth0
        post-up ip -6 route add fe80::1 dev eth0
        post-up ip -6 route add default via fe80::1 dev eth0

I also tried it in this alternative way:

auto eth0
iface eth0 inet static
        address 1.2.3.1
        netmask 255.255.255.192
        network 1.2.3.0
        broadcast 1.2.3.63
        gateway 1.2.3.62
        dns-nameservers 8.8.8.8
        dns-search mydomain.tld

iface eth0 inet6 static
        address 2001:db8:100:3022::2
        netmask 64
        gateway fe80::1

What we added to /etc/init.d/networking:

…
case "$1" in
start)
        process_options
        check_ifstate

        if [ "$CONFIGURE_INTERFACES" = no ]
        then
            log_action_msg "Not configuring network interfaces, see /etc/default/networking"
            exit 0
        fi
        set -f
        exclusions=$(process_exclusions)
        log_action_begin_msg "Configuring network interfaces"
        if ifup -a $exclusions $verbose && ifup_hotplug $exclusions $verbose
        then
            # Our additions
            ip -6 addr add 2001:db8:100:3022::2 dev eth0
            ip -6 route add fe80::1 dev eth0
            ip -6 route add default via fe80::1 dev eth0

            log_action_end_msg $?
        else
            log_action_end_msg $?
        fi
        ;;
…

Update: The output of ip -6 address show eth0 after booting up is:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 fe80::abcd:abcd:abcd:abc/64 scope link 
       valid_lft forever preferred_lft forever

Lately I'm often using the SSH client's ControlMaster feature, which allows me to use a single SSH-TCP-connection for multiple shells and port forwardings to the same remote system. The most annoying thing about this is, that the first shell's process that is opened becomes automatically the ControlMaster. That means, if this process gets terminated, all other shells and port forwardings using the control master connection become unavailable.

I would really like when the first ssh command to a remote system would spawn an additional background process which holds the connection as long as there are still connections using the ControlMaster connection, so I could simply close the actual shells whithout having to risk to crash other connections. Ideally the background ControlMaster process would even be configurable to wait for an amount of time for new shells or port forwardings to use the ControlMaster before finally shutting down.

Is there a way to make the ssh client do such a thing? I know I could create such a connection manually before using ssh to create the first shell, but I explicitly want this to happen automatically because otherwise I would surely forget to do it every now and then.

Letting a wrapper script do it also wouldn't be so easy because I often use configured shorthands for remote server names in .ssh/config and the ControlMaster socket is created using USERNAME@NETWORK_NAME:NETWORK_PORT as name. So a wrapper would need to understand .config/ssh perfectly to work as intended.

I'm trying to create an x86 64 bit guest machine on an old Debian Lenny x86 64 bit hypervisor using HVM. The physical CPU is a first generation Intel i7 with VT-x support. Xen recognizes the VT-x support with the line (XEN) HVM: VMX enabled when running xm dmesg.

The Xen version according to xm info is 3.2.

I tried with newest installer ISO images of Debian Squeeze (6.0) and Ubuntu Oneiric Ocelot (11.10). The x86 64 bit version freezes the guest system shortly after starting, if I mount the x86 32 bit installer image, everything runs fine.

How can I fix this?

IRC user krt in ##xen on irc.freenode.net recommended setting acpi = 0 in the guest configuration file. This did not solve this problem.

Here is the guest configuration file I'm currently using:

arch = 'amd64'

device_model = '/usr/lib/xen-default/bin/qemu-dm'

#
#  Kernel + memory size
#
kernel      = '/usr/lib/xen-default/boot/hvmloader'

builder = 'hvm'
acpi = 0
#xen_platform_pci = 0

memory      = 1024
shadow_memory = 8

#
#  Disk device(s).
#
#root        = '/dev/sda2 ro'
disk        = [
                  'file:/var/lib/libvirt/images/ubuntu-11.10-desktop-amd64.iso,xvdc:cdrom,r',
                  'phy:/dev/system/fraumann-root,xvda,w',
              ]

# boot on floppy (a), hard disk (c) or CD-ROM (d)
# default: hard disk, cd-rom, floppy
boot = 'dc'

#
#  Hostname
#
name        = 'fraumann'

#
#  Networking
#
vif         = [ 'ip=1.2.3.4,mac=00:16:3E:9F:3C:31' ] # IP changed for the public

sdl = 0
vnc = 1
vnclisten = 'localhost'
vncconsole = 1
stdvga = 0
serial = 'pty'
usbdevice = 'tablet'

#
#  Behaviour
#
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

vcpus = 4
extra = 'xencons=tty1'

I just found out about the ControlMaster/ControlPath feature of OpenSSH, which allows you to use a single SSH connection to run multiple terminals.

As I often use SSH to use port forwarding to get encrypted and authenticated VNC sessions I instantly recognized that you can't add port forwardings to a remote server to which you already have an established connection. This sucks.

Sometimes later I found out that you can circumvent this limitation by typing ~C in a running SSH terminal session. This opens up a command-line which allows you to add or remove port forwardings.

My quesion now is: How can I add port forwardings on an existing SSH session which is using the ControlMaster/ControlPath feature, without the need to have access to a terminal session inside that SSH session. I need this to enable my script which starts a secure tunneled VNC connection for me to add and later remove its port forwardings.

(I know I could use a terminal multiplexer such as GNU Screen or tmux, actually I'm doing this already. But I like the idea of using just one SSH session for serveral reasons.)

I know that it is possible to forward the windows of an X-windows-system application to a client's desktop via SSH when you start the application in a SSH terminal session which has X-forwarding enabled.

But is there a way to forward the windows of an application which is already running on a remote system? Most impressive would be a way to keep a windowed application running on a headless server system, so that when I ever need that application I can forward its windows on-demand to my desktop system, without the need to ever stop this application or the application being closed down because my SSH connection times out.

I'm running Openfire 3.6.4 on a Debian Lenny (x86_64) system with about 40 concurrent users, which was installed via the .deb packet and ran fine for about a year. Then, some of my users complained about not being able to login (the TLS connection was established, but then, no further XMPP communication happened). TLS is required for clients on my server. Still, most of the users could use the server normally, the problem constantly affected only small group of users.

I tried to restart the server with the provided /etc/init.d/openfire script. With restart and stop nothing happened, even after some retries and waiting for something to happen. Because of that I looked up the Java process ID and used kill (without any arguments but the process ID) to stop the server. It worked instantly. Afterwards I used the script to start the server again. The users could now use the server again, the problem seemed to have vanised.

Some days later I tried to create a new user via the web interface. I noticed, that the Users/Groups, Sessions and Connection Managers tab was inaccessible because of some strange exceptions which I will list below.

I have no idea what caused this or how to fix this. If you have any idea, please help me. This post was also posted on the forums of the Ignite Realtime Community.

Users/Groups

HTTP ERROR: 500

Domain cannot be null

RequestURI=/user-summary.jsp
Caused by:

java.lang.NullPointerException: Domain cannot be null
    at org.xmpp.packet.JID.(JID.java:261)
    at org.jivesoftware.openfire.SessionManager.getActiveSessionCount(SessionManager.java:905)
    at org.jivesoftware.openfire.spi.PresenceManagerImpl.isAvailable(PresenceManagerImpl.java:84)
    at org.jivesoftware.openfire.admin.user_002dsummary_jsp._jspService(user_002dsummary_jsp.java:254)
    at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
    at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
    at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118)
    at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
    at org.jivesoftware.util.LocaleFilter.doFilter(LocaleFilter.java:66)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
    at org.jivesoftware.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:42)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
    at org.jivesoftware.admin.PluginFilter.doFilter(PluginFilter.java:70)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
    at org.jivesoftware.admin.AuthCheckFilter.doFilter(AuthCheckFilter.java:146)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
    at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
    at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
    at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
    at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
    at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
    at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
    at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
    at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
    at org.mortbay.jetty.Server.handle(Server.java:324)
    at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
    at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:829)
    at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514)
    at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
    at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
    at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
    at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488)

Powered by Jetty://

Sessions

java.lang.NullPointerException: Domain cannot be null
    at org.xmpp.packet.JID.(JID.java:261)
    at org.jivesoftware.openfire.SessionManager.isAnonymousRoute(SessionManager.java:659)
    at org.jivesoftware.openfire.admin.session_002dsummary_jsp._jspService(session_002dsummary_jsp.java:337)
    at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
    at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
    at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118)
    at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
    at org.jivesoftware.util.LocaleFilter.doFilter(LocaleFilter.java:66)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
    at org.jivesoftware.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:42)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
    at org.jivesoftware.admin.PluginFilter.doFilter(PluginFilter.java:70)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
    at org.jivesoftware.admin.AuthCheckFilter.doFilter(AuthCheckFilter.java:146)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
    at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
    at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
    at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
    at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
    at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
    at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
    at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
    at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
    at org.mortbay.jetty.Server.handle(Server.java:324)
    at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
    at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:829)
    at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514)
    at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
    at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
    at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
    at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488)

Server Settings -> Connection Managers

java.lang.NoClassDefFoundError: Could not initialize class org.jivesoftware.openfire.multiplex.ConnectionMultiplexerManager
    at org.jivesoftware.openfire.admin.connection_002dmanagers_002dsettings_jsp._jspService(connection_002dmanagers_002dsettings_jsp.java:149)
    at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
    at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
    at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118)
    at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
    at org.jivesoftware.util.LocaleFilter.doFilter(LocaleFilter.java:66)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
    at org.jivesoftware.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:42)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
    at org.jivesoftware.admin.PluginFilter.doFilter(PluginFilter.java:70)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
    at org.jivesoftware.admin.AuthCheckFilter.doFilter(AuthCheckFilter.java:146)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
    at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
    at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
    at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
    at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
    at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
    at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
    at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
    at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
    at org.mortbay.jetty.Server.handle(Server.java:324)
    at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
    at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:829)
    at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514)
    at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
    at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
    at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
    at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488)