I've got a base Fedora 15 image which works fine within VCL after monkeying with the ext_sshd scripts. Now, when I go to create a new image based on it, the new image is captured correctly, but the problem with "ext_sshd stop" during the reservation process resurfaces.
I've manually edited the /etc/init.d/ext_sshd and /etc/init.d/sshd scripts to correctly use the $PID_FILE (see http://www.mail-archive.com/vcl-user@incubator.apache.org/msg00156.html), so the SSH servers can be independently started/stopped correctly. But, it seems that generate_ext_sshd_init in Linux.pm doesn't tweak the ext_sshd script in the same manner, so after the capture I need to tweak it again. I wonder if eventually we might want to enhance the capture script to respect some sort of flag in the image to tell the capture script to leave some things alone. One approach might be to source a file from the image itself (such as /root/vcl-custom-capture.pm) that can allow an image creator to customize or even override some of the operations performed during image capture. In fact, that might be a more general-purpose way of providing an "escape hatch" for one-off image customizations. As I look at Fedora 15 and its continuing migration towards using systemctl rather than sysv init, many of the techniques that Linux.pm and other VCL modules perform directly on files will become more fragile over time; so either more work may need to be poured into the internal VCL scripts. Some sort of "escape hatch" like sourcing a file from the image (if it exists) could be quite helpful. FWIW, the sshd stop script that kills the sshd process (rather than using the PID_FILE) was documented in 2005 ( http://www.redhat.com/archives/rhl-list/2005-November/msg04593.html ), which was solved there by additionally creating an ext_sshd copy or symlink for the sshd executable. Also, as another aside, the discussion from 2010 at http://www.linuxquestions.org/questions/linux-software-2/multiple-ssh-daemons-fc11-787230/ reveals that some issues with SELinux that may need to be addressed in some environments. I guess few people bother to create another SSH daemon, and we all work around it, so it hasn't been a priority for anyone to fix the killproc $SSHD issue in the base distro.
