You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@vcl.apache.org by Peter Dimitrios <pe...@gmail.com> on 2011/10/07 02:33:54 UTC
After capturing a Fedora 15 image, ext_sshd stop kills all SSH access
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.
Re: After capturing a Fedora 15 image, ext_sshd stop kills all SSH access
Posted by Aaron Peeler <aa...@ncsu.edu>.
Sounds good. I'll created a jira issue and I'll make the first pass on
the exclude file list for the Linux OS.
https://issues.apache.org/jira/browse/VCL-528
Feel free to add to the jira issue.
Aaron
On Fri, Oct 7, 2011 at 11:53 AM, Peter Dimitrios <pe...@gmail.com> wrote:
> I'm thinking that initially we could have some sort of "exclude_list"
> file, but as I ponder the more general issue of all this "one off"
> image customization, do we trust image creators enough to have more
> than just a simple list of filenames or boolean go/no-go indicators in
> the image? Initially, having a 'vcl-capture-exclude-files' control
> to enable/disable parts of the capture process would be relatively
> safe, but I think eventually we could include more extensive
> user-exits that might override or extend default VCL functions like
> capture, preload, and image startup/shutdown, without having to modify
> VCL itself.
>
> We could hide these image exits in /opt/vcl/ or whatever, but I'm
> thinking we might treat these per-image configuration extensions as
> files in a hidden directory like /root/.vcloptions or c:\vcloptions .
> The hidden / dot-file convention makes it like other image
> personalization configuration files, and makes it easier to hold onto
> changes if you create a new edition of an image and need to tweak
> things again. Most image customizers wouldn't touch any of this, but
> this mechanism could be very handy for handling edge-cases or
> bleeding-edge software.
>
> I think I like more comprehensive user-exits, it can also make
> adopting a new or strange Linux (or other OS) easier for end-users,
> rather than having them promote their code into VCL itself. Over
> time, VCL can adopt some of the better ideas into new base VCL modules
> so that the per-image customizations can be reduced.
>
> One additional feature might be to put some flag in the ImageProfile
> to indicate "disallow vcl user exits" so that if someone truly screws
> something up maybe we can recover without delving into raw VMware /
> KVM.
>
--
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.
Re: After capturing a Fedora 15 image, ext_sshd stop kills all SSH access
Posted by Peter Dimitrios <pe...@gmail.com>.
I'm thinking that initially we could have some sort of "exclude_list"
file, but as I ponder the more general issue of all this "one off"
image customization, do we trust image creators enough to have more
than just a simple list of filenames or boolean go/no-go indicators in
the image? Initially, having a 'vcl-capture-exclude-files' control
to enable/disable parts of the capture process would be relatively
safe, but I think eventually we could include more extensive
user-exits that might override or extend default VCL functions like
capture, preload, and image startup/shutdown, without having to modify
VCL itself.
We could hide these image exits in /opt/vcl/ or whatever, but I'm
thinking we might treat these per-image configuration extensions as
files in a hidden directory like /root/.vcloptions or c:\vcloptions .
The hidden / dot-file convention makes it like other image
personalization configuration files, and makes it easier to hold onto
changes if you create a new edition of an image and need to tweak
things again. Most image customizers wouldn't touch any of this, but
this mechanism could be very handy for handling edge-cases or
bleeding-edge software.
I think I like more comprehensive user-exits, it can also make
adopting a new or strange Linux (or other OS) easier for end-users,
rather than having them promote their code into VCL itself. Over
time, VCL can adopt some of the better ideas into new base VCL modules
so that the per-image customizations can be reduced.
One additional feature might be to put some flag in the ImageProfile
to indicate "disallow vcl user exits" so that if someone truly screws
something up maybe we can recover without delving into raw VMware /
KVM.
Re: After capturing a Fedora 15 image, ext_sshd stop kills all SSH access
Posted by Aaron Peeler <fa...@ncsu.edu>.
What do you think about an exclude list located somewhere on the image?
/opt/vcl/exclude_list for linux and C:\exclude_list on windows?
If a file is in this exclude_list, the pre_capture routine would skip
making any modifications to that file.
This would give a generic solution at the image level and be a simple
addition to the vcl code base.
In image capture process, we want make sure the image starts up
correctly. Hence having to modify/generate files for rc.local,
ext_sshd_config, ext_sshd, 70-persistent-net.rules, etc.
The latest issue I've hit on rhel6 is we have deal with udev rule
70-persistent-net.rules. In general cases just removing this file it
in pre_capture routine works, and the captured rhel6 image loads fine.
But a special case image that's dedicated to a 2U box with 7 nics,
this udev rule is important to define the correct nics for
public/private networks. I think the exclude_list would work well in
this case and the one you've mentioned.
Thoughts?
Aaron
On Fri, Oct 7, 2011 at 7:57 AM, Aaron Peeler <fa...@ncsu.edu> wrote:
> 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 <pe...@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.
>
--
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.
Re: After capturing a Fedora 15 image, ext_sshd stop kills all SSH access
Posted by Aaron Peeler <fa...@ncsu.edu>.
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 <pe...@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.