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.

Reply via email to