Here a short checklist if your Condor Windows does not work as expected:

• Download the Windows MSI installer from the Condor homepage: http://www.cs.wisc.edu/condor
• Define a HOME environment variable pointing to your home directory (system settings -> system -> extended -> environment variables)
• Set HOSTALLOW_READ and HOSTALLOW_WRITE in condor_config
• Make sure that your account has a password (not always the case for home PC’s)
• Run condor_store_cred add and let Condor save your password (every good Windows developer knows a way to avoid this)
• Restart condor_master (system settings -> services)
• Try condor_status

On one of our systems, chkrootkit says the following:

Checking `lkm'... You have 1 process hidden for ps command
Warning: Possible LKM Trojan installed


I learned from the Debian developers that this might be a false positive, reasoned by some Linux 2.6 kernel patch issue. We are currently working with the OpenVZ-patched original 2.6 kernel , and the error happens inside a guest system. The detailled check shows:

mymachine:~# chkrootkit -x lkm
ROOTDIR is `/'
###
### Output of: ./chkproc -v -v -p 3
###
PID 15536(/proc/15536): not in readdir output
PID 15536: not in ps output
CWD 15536: /
EXE 15536: /sbin/init
...

Let’ check who it is:

mymachine:~# cat /proc/15536/status |grep Name
Name:   init

It seems like OpenVZ is hiding either the guest system or the host system init process. “pstree -p” in the guest system only knows one init process, with PID 1 as expected. The host system does not know a process with PID 15536, even though it shows the init process of the guest system in pstree -p. A second fresh guest system installation showed the same thing with a different PID, so Martin and me are sure that this is a false positive reasoned by an OpenVZ bug.

Since Postfix 2.3 offers support for the (sendmail) milter plugin interface, you can now avoid the complicated SMTP forwarding integration of external tools in Postfix. Milter plugins run as own daemon, drop a socket file somewhere, and the MTA communicates with this tool for every mail. Easy, cool. For me, the use case was clamav-milter under Debian Etch.

Since Debian’s Postfix 2.3 runs the smtpd in a chroot environment (/var/spool/postfix), the daemon is not able to access the socket file in it’s original place (var/run/clamav/clamav-milter). I changed /etc/default/clamav-milter, so that the socket file is created below the Postfix chroot directory. In addition, I needed to patch the clamav-milter startup script, since the socket file has only access permissions for user clamav. The script now starts the daemon, checks for the socket file, and changes permissions accordingly. Postfix usually starts up afterwards, and can access the file. Works.

It would be better if milter plugins and postfix could share a group in debian, such as milter. I will contact the author regarding this issue.

Please note that you do not need the clamd package. Please run dpkg-reconfigure clamav-base and enable the mail filter option of the clamav library. Also perform a dpkg-reconfigure clamav-freshclam and disable the database update notification, since the milter filter cannot handle this.

BTW, I also tried to integrate spamass-milter the same way, but it did not work accordingly. Even changing the milter version did not change sme strange protocol errors:

Oct 10 22:47:38 sam postfix/smtpd[20077]: warning: milter unix:/spamassassin/sa.sock: can't read SMFIC_OPTNEG reply packet header: Success
Oct 10 22:47:38 sam postfix/smtpd[20077]: warning: milter unix:/spamassassin/sa.sock: read error in initial handshake

I am currently working on some Debian@Debian installations with OpenVZ. In general, it works nice and the OpenVZ Wiki is the most useful information source for all questions regarding installation and configuration. I decided not to use the prepared debian kernels with OpenVZ available, since they configured an i386 build. We simply want to use all the nice new commands introduced since the invention of the Pentium …

We experienced strange problems when resizing a terminal (PuTTY in our case) with a shell at one of the guest Debian systems. In the host Debian system, it works without any problem. We first blamed the program for not handling SIGWINCH the right way. This was not the case, even VIM made it wrong

I started to play with the TERM environment variable setting, but it didn’t got better. I learned several things (from Martin, as usual): The TERM environment variable really is intended to match to the connected terminal client. “linux” terminals are a physically connected monitor and keyboard – keys like Strg+F10 are available. “vt100″ terminals are pretty old hardware, and usually not connected to a Linux box. And both of them are usually not resizable …

Therefore, a really useful default with SSH is the xterm terminal type. When I use PuTTY, this is the exactly the value of TERM after the SSH login. I learned that changing TERM in your .bashrc file is stupid in this case, since the SSH client itself already requests the right terminal type. The protocol sends (SSH_MSG_CHANNEL_REQUEST, "pty-req") for requesting the pseudo terminal, with parameters for terminal type and initial size. Therefore, the client and the server automatically agree on the same terminal type, and this cannot be the problem. Also the resize activity is covered by a SSH protocol message (SSH_MSG_CHANNEL_REQUEST, "window-change"). This leads to ioctl(TIOCSWINSZ) by SSHD for the pseudo terminal process, and this leads to SIGWINCH for everybody in the process group. In short, if the application is resizable in general, and your SSH tool demands the right terminal type, it should work.

After some reading and Google, I found the right answer. Until now, we entered the guest systems by connecting with SSH to the host system, and entering the guest systems with vzctl enter XXX. And page 100 from the OpenVZ user manual says:

vzctl enter is similar to vzctl exec /bin/bash. The difference between the two is that vzctl enter makes the shell interpreter believe that it is connected to a terminal. As such, you receive a shell prompt and are able to execute multiple commands as if you were logged in to the Virtual Private Server.

Some of the environment variables from the host system (like SSH_TTY) are not inherited to the guest system. We looked at the source code of vzctl, and found src/enter.c which contains the activities on vzctl enter. The function forks, creates a new pseudo terminal (pty_alloc), moves this new process to the intended VZ with an ioctl() to the vzctl file descriptor (/dev/vzctl), starts a new shell in the pseudo terminal, and waits for the ending while connecting host-system-stdin with guest-system-stdout and vice versa. Only some environment variables (like PATH) are configured manually, nothing is inherited. There is also no signal handler for SIGWINCH, which leads to the fact that the vzctl process receives the signal from SSHD, but does not forward it to the shell in the guest system.

We could now patch vzctl, or live with it. The manual anyway says:

However, be aware that vzctl enter is a potentially dangerous command if you have untrusted users inside the Virtual Private Server. Your shell will have its file descriptors accessible for the VPS root in the /proc filesystem and a malicious user could run ioctl calls on it. Never use vzctl enter for Virtual Private Servers you do not trust. That is why, vzctl enter is only supposed to be an off-duty way of connecting to VPSs, not a complete replacement of ssh.

Im sum, vzctl enter is an emergency solution. Install SSH in your guest systems.