Hi Pete, Thanks for the info. I'm in the process of adding Fedora15 now, so I'll shortly hit this issue.
I agree we'll need to adapt the pre_capture steps of Linux to account for such changes. Either as you mention below, touch|no touch options or to correctly account for the the issues with kilproc $SSHD. Aaron On Thu, Oct 6, 2011 at 8:33 PM, Peter Dimitrios <petedag...@gmail.com> wrote: > 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. > -- Aaron Peeler Program Manager Virtual Computing Lab NC State University All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.
