Clearly not a problem caused by puppet but something I can''t apparently
deploy with puppet unless someone has an idea.
Trying to automate a way to deploy mod_mono for apache
from CLI, the problem seems obvious...
apt-get install -y --assume-yes libapache2-mod-mono mono-apache-server
libmono-firebirdsql1.7-cil
a massive pile of packages installs and it finally arrives at the truth moment:
Configuration file `/etc/apache2/mods-available/mod_mono.conf''
==> File on system created by you or by a script.
==> File also in package provided by package maintainer.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer''s version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : background this process to examine the situation
The default action is to keep your current version.
*** mod_mono.conf (Y/I/N/O/D/Z) [default=N] ?
So it appears that the same target, mod_mono.conf is being created both by
script and a file in the package itself and it appears that all of the
''-y'' or ''--assume-yes'' logic in the command
itself will not allow an install to progress without an interactive answer to
the question - the answer to which is essentially meaningless because I can
control the file anyway with puppet.
Anyone have an idea how to defeat well intentioned but defective packager logic?
--
Craig White ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ craig.white@ttiltd.com
1.800.869.6908 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ www.ttiassessments.com
Need help communicating between generations at work to achieve your desired
success? Let us help!
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Isn''t there an adminfile option to the package resource that will let you pass responses as if it were an interactive session? Not sure if it''s supported for the apt provider, but worth looking into if you haven''t already. -- Nathan Clemons http://www.livemocha.com The worlds largest online language learning community On Fri, Aug 12, 2011 at 9:53 AM, Craig White <craig.white@ttiltd.com> wrote:> Clearly not a problem caused by puppet but something I can''t apparently > deploy with puppet unless someone has an idea. > > Trying to automate a way to deploy mod_mono for apache > > from CLI, the problem seems obvious... > > apt-get install -y --assume-yes libapache2-mod-mono mono-apache-server > libmono-firebirdsql1.7-cil > > a massive pile of packages installs and it finally arrives at the truth > moment: > > Configuration file `/etc/apache2/mods-available/mod_mono.conf'' > ==> File on system created by you or by a script. > ==> File also in package provided by package maintainer. > What would you like to do about it ? Your options are: > Y or I : install the package maintainer''s version > N or O : keep your currently-installed version > D : show the differences between the versions > Z : background this process to examine the situation > The default action is to keep your current version. > *** mod_mono.conf (Y/I/N/O/D/Z) [default=N] ? > > So it appears that the same target, mod_mono.conf is being created both by > script and a file in the package itself and it appears that all of the ''-y'' > or ''--assume-yes'' logic in the command itself will not allow an install to > progress without an interactive answer to the question - the answer to which > is essentially meaningless because I can control the file anyway with > puppet. > > Anyone have an idea how to defeat well intentioned but defective packager > logic? > > -- > Craig White ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ craig.white@ttiltd.com > 1.800.869.6908 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ www.ttiassessments.com > > Need help communicating between generations at work to achieve your desired > success? Let us help! > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Appear that ''adminfile'' option is a Solaris only thing. I found that ubuntu/debian has debconf-get-selections/debconf-set-selections packages which might actually get me there but it introduces new package dependencies and would take more time than it is reasonably worth as we will never have many servers with mod-mono anyway. I think I will just manually install on the servers that will need it. Thanks Craig On Aug 12, 2011, at 9:56 AM, Nathan Clemons wrote:> Isn''t there an adminfile option to the package resource that will let you pass responses as if it were an interactive session? Not sure if it''s supported for the apt provider, but worth looking into if you haven''t already. > > -- > Nathan Clemons > http://www.livemocha.com > The worlds largest online language learning community > > > > On Fri, Aug 12, 2011 at 9:53 AM, Craig White <craig.white@ttiltd.com> wrote: > Clearly not a problem caused by puppet but something I can''t apparently deploy with puppet unless someone has an idea. > > Trying to automate a way to deploy mod_mono for apache > > from CLI, the problem seems obvious... > > apt-get install -y --assume-yes libapache2-mod-mono mono-apache-server libmono-firebirdsql1.7-cil > > a massive pile of packages installs and it finally arrives at the truth moment: > > Configuration file `/etc/apache2/mods-available/mod_mono.conf'' > ==> File on system created by you or by a script. > ==> File also in package provided by package maintainer. > What would you like to do about it ? Your options are: > Y or I : install the package maintainer''s version > N or O : keep your currently-installed version > D : show the differences between the versions > Z : background this process to examine the situation > The default action is to keep your current version. > *** mod_mono.conf (Y/I/N/O/D/Z) [default=N] ? > > So it appears that the same target, mod_mono.conf is being created both by script and a file in the package itself and it appears that all of the ''-y'' or ''--assume-yes'' logic in the command itself will not allow an install to progress without an interactive answer to the question - the answer to which is essentially meaningless because I can control the file anyway with puppet. > > Anyone have an idea how to defeat well intentioned but defective packager logic?-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
You should file a bug report against the package with Debian; we set the "noninteractive", and the "force yes", bits that absolutely *should* make it work fine in these circumstances. I am sorry that it doesn''t work; if you find something we didn''t do, that makes the prompt go away, please let us know. :) Daniel On Fri, Aug 12, 2011 at 13:38, Craig White <craig.white@ttiltd.com> wrote:> Appear that ''adminfile'' option is a Solaris only thing. > > I found that ubuntu/debian has debconf-get-selections/debconf-set-selections packages which might actually get me there but it introduces new package dependencies and would take more time than it is reasonably worth as we will never have many servers with mod-mono anyway. > > I think I will just manually install on the servers that will need it. > > Thanks > > Craig > > On Aug 12, 2011, at 9:56 AM, Nathan Clemons wrote: > >> Isn''t there an adminfile option to the package resource that will let you pass responses as if it were an interactive session? Not sure if it''s supported for the apt provider, but worth looking into if you haven''t already. >> >> -- >> Nathan Clemons >> http://www.livemocha.com >> The worlds largest online language learning community >> >> >> >> On Fri, Aug 12, 2011 at 9:53 AM, Craig White <craig.white@ttiltd.com> wrote: >> Clearly not a problem caused by puppet but something I can''t apparently deploy with puppet unless someone has an idea. >> >> Trying to automate a way to deploy mod_mono for apache >> >> from CLI, the problem seems obvious... >> >> apt-get install -y --assume-yes libapache2-mod-mono mono-apache-server libmono-firebirdsql1.7-cil >> >> a massive pile of packages installs and it finally arrives at the truth moment: >> >> Configuration file `/etc/apache2/mods-available/mod_mono.conf'' >> ==> File on system created by you or by a script. >> ==> File also in package provided by package maintainer. >> What would you like to do about it ? Your options are: >> Y or I : install the package maintainer''s version >> N or O : keep your currently-installed version >> D : show the differences between the versions >> Z : background this process to examine the situation >> The default action is to keep your current version. >> *** mod_mono.conf (Y/I/N/O/D/Z) [default=N] ? >> >> So it appears that the same target, mod_mono.conf is being created both by script and a file in the package itself and it appears that all of the ''-y'' or ''--assume-yes'' logic in the command itself will not allow an install to progress without an interactive answer to the question - the answer to which is essentially meaningless because I can control the file anyway with puppet. >> >> Anyone have an idea how to defeat well intentioned but defective packager logic? > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. > >-- ⎋ Puppet Labs Developer – http://puppetlabs.com ♲ Made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Does env DEBIAN_FRONTEND=noninteractive aptitude install -o ''APT::Get::force-yes=true''--assume-yes libapache2-mod-mono mono-apache- server libmono-firebirdsql1.7-cil still prompts you? If not then it should work in puppet too. On Aug 12, 7:53 pm, Craig White <craig.wh...@ttiltd.com> wrote:> Clearly not a problem caused by puppet but something I can''t apparently deploy with puppet unless someone has an idea. > > Trying to automate a way to deploy mod_mono for apache > > from CLI, the problem seems obvious... > > apt-get install -y --assume-yes libapache2-mod-mono mono-apache-server libmono-firebirdsql1.7-cil > > a massive pile of packages installs and it finally arrives at the truth moment: > > Configuration file `/etc/apache2/mods-available/mod_mono.conf'' > ==> File on system created by you or by a script. > ==> File also in package provided by package maintainer. > What would you like to do about it ? Your options are: > Y or I : install the package maintainer''s version > N or O : keep your currently-installed version > D : show the differences between the versions > Z : background this process to examine the situation > The default action is to keep your current version. > *** mod_mono.conf (Y/I/N/O/D/Z) [default=N] ? > > So it appears that the same target, mod_mono.conf is being created both by script and a file in the package itself and it appears that all of the ''-y'' or ''--assume-yes'' logic in the command itself will not allow an install to progress without an interactive answer to the question - the answer to which is essentially meaningless because I can control the file anyway with puppet. > > Anyone have an idea how to defeat well intentioned but defective packager logic? > > -- > Craig White ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ craig.wh...@ttiltd.com > 1.800.869.6908 ~~~~~~~~~~~~~~~~~~~~~~~~~~~www.ttiassessments.com > > Need help communicating between generations at work to achieve your desired success? Let us help!-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Daniel, Is it safe to use "force yes" in debian package provider or is it better to just fail? So afaiu debian provider uses apt-get and not aptitude? On Aug 12, 9:22 pm, Daniel Pittman <dan...@puppetlabs.com> wrote:> You should file a bug report against the package with Debian; we set > the "noninteractive", and the "force yes", bits that absolutely > *should* make it work fine in these circumstances. > > I am sorry that it doesn''t work; if you find something we didn''t do, > that makes the prompt go away, please let us know. :) > > Daniel > > > > > > > > > > On Fri, Aug 12, 2011 at 13:38, Craig White <craig.wh...@ttiltd.com> wrote: > > Appear that ''adminfile'' option is a Solaris only thing. > > > I found that ubuntu/debian has debconf-get-selections/debconf-set-selections packages which might actually get me there but it introduces new package dependencies and would take more time than it is reasonably worth as we will never have many servers with mod-mono anyway. > > > I think I will just manually install on the servers that will need it. > > > Thanks > > > Craig > > > On Aug 12, 2011, at 9:56 AM, Nathan Clemons wrote: > > >> Isn''t there an adminfile option to the package resource that will let you pass responses as if it were an interactive session? Not sure if it''s supported for the apt provider, but worth looking into if you haven''t already. > > >> -- > >> Nathan Clemons > >>http://www.livemocha.com > >> The worlds largest online language learning community > > >> On Fri, Aug 12, 2011 at 9:53 AM, Craig White <craig.wh...@ttiltd.com> wrote: > >> Clearly not a problem caused by puppet but something I can''t apparently deploy with puppet unless someone has an idea. > > >> Trying to automate a way to deploy mod_mono for apache > > >> from CLI, the problem seems obvious... > > >> apt-get install -y --assume-yes libapache2-mod-mono mono-apache-server libmono-firebirdsql1.7-cil > > >> a massive pile of packages installs and it finally arrives at the truth moment: > > >> Configuration file `/etc/apache2/mods-available/mod_mono.conf'' > >> ==> File on system created by you or by a script. > >> ==> File also in package provided by package maintainer. > >> What would you like to do about it ? Your options are: > >> Y or I : install the package maintainer''s version > >> N or O : keep your currently-installed version > >> D : show the differences between the versions > >> Z : background this process to examine the situation > >> The default action is to keep your current version. > >> *** mod_mono.conf (Y/I/N/O/D/Z) [default=N] ? > > >> So it appears that the same target, mod_mono.conf is being created both by script and a file in the package itself and it appears that all of the ''-y'' or ''--assume-yes'' logic in the command itself will not allow an install to progress without an interactive answer to the question - the answer to which is essentially meaningless because I can control the file anyway with puppet. > > >> Anyone have an idea how to defeat well intentioned but defective packager logic? > > > -- > > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > > To post to this group, send email to puppet-users@googlegroups.com. > > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > > For more options, visit this group athttp://groups.google.com/group/puppet-users?hl=en. > > -- > ⎋ Puppet Labs Developer –http://puppetlabs.com > ♲ Made with 100 percent post-consumer electrons-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Aug 12, 2011, at 12:14 PM, piavlo wrote:> env DEBIAN_FRONTEND=noninteractive aptitude install -o > ''APT::Get::force-yes=true''--assume-yes libapache2-mod-mono mono-apache- > server libmono-firebirdsql1.7-cil---- don''t even get out of the box... Need to get 0B/55.7MB of archives. After unpacking 186MB will be used. Do you want to continue? [Y/n/?] n Abort. adding a ''-y'' into the mix got me to the very same gore point - issue is simply the packager trying to do users a favor by including his suggested copy of the config file which contends with a file by the same name that is apparently created by a post-install script. Thanks for the idea though Craig -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Relatively speaking, it is safe. Not perfect, but neither is the other decision. Generally speaking, ''force yes'' shows up any time that folks modify a configuration file as a critical option. Without that, replacement wouldn''t happen the same way. Daniel On Fri, Aug 12, 2011 at 15:17, piavlo <lolitushka@gmail.com> wrote:> Daniel, > > Is it safe to use "force yes" in debian package provider or is it > better to just fail? > So afaiu debian provider uses apt-get and not aptitude? > > > On Aug 12, 9:22 pm, Daniel Pittman <dan...@puppetlabs.com> wrote: >> You should file a bug report against the package with Debian; we set >> the "noninteractive", and the "force yes", bits that absolutely >> *should* make it work fine in these circumstances. >> >> I am sorry that it doesn''t work; if you find something we didn''t do, >> that makes the prompt go away, please let us know. :) >> >> Daniel >> >> >> >> >> >> >> >> >> >> On Fri, Aug 12, 2011 at 13:38, Craig White <craig.wh...@ttiltd.com> wrote: >> > Appear that ''adminfile'' option is a Solaris only thing. >> >> > I found that ubuntu/debian has debconf-get-selections/debconf-set-selections packages which might actually get me there but it introduces new package dependencies and would take more time than it is reasonably worth as we will never have many servers with mod-mono anyway. >> >> > I think I will just manually install on the servers that will need it. >> >> > Thanks >> >> > Craig >> >> > On Aug 12, 2011, at 9:56 AM, Nathan Clemons wrote: >> >> >> Isn''t there an adminfile option to the package resource that will let you pass responses as if it were an interactive session? Not sure if it''s supported for the apt provider, but worth looking into if you haven''t already. >> >> >> -- >> >> Nathan Clemons >> >>http://www.livemocha.com >> >> The worlds largest online language learning community >> >> >> On Fri, Aug 12, 2011 at 9:53 AM, Craig White <craig.wh...@ttiltd.com> wrote: >> >> Clearly not a problem caused by puppet but something I can''t apparently deploy with puppet unless someone has an idea. >> >> >> Trying to automate a way to deploy mod_mono for apache >> >> >> from CLI, the problem seems obvious... >> >> >> apt-get install -y --assume-yes libapache2-mod-mono mono-apache-server libmono-firebirdsql1.7-cil >> >> >> a massive pile of packages installs and it finally arrives at the truth moment: >> >> >> Configuration file `/etc/apache2/mods-available/mod_mono.conf'' >> >> ==> File on system created by you or by a script. >> >> ==> File also in package provided by package maintainer. >> >> What would you like to do about it ? Your options are: >> >> Y or I : install the package maintainer''s version >> >> N or O : keep your currently-installed version >> >> D : show the differences between the versions >> >> Z : background this process to examine the situation >> >> The default action is to keep your current version. >> >> *** mod_mono.conf (Y/I/N/O/D/Z) [default=N] ? >> >> >> So it appears that the same target, mod_mono.conf is being created both by script and a file in the package itself and it appears that all of the ''-y'' or ''--assume-yes'' logic in the command itself will not allow an install to progress without an interactive answer to the question - the answer to which is essentially meaningless because I can control the file anyway with puppet. >> >> >> Anyone have an idea how to defeat well intentioned but defective packager logic? >> >> > -- >> > You received this message because you are subscribed to the Google Groups "Puppet Users" group. >> > To post to this group, send email to puppet-users@googlegroups.com. >> > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. >> > For more options, visit this group athttp://groups.google.com/group/puppet-users?hl=en. >> >> -- >> ⎋ Puppet Labs Developer –http://puppetlabs.com >> ♲ Made with 100 percent post-consumer electrons > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. > >-- ⎋ Puppet Labs Developer – http://puppetlabs.com ♲ Made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Fri, Aug 12, 2011 at 9:53 AM, Craig White <craig.white@ttiltd.com> wrote:> Clearly not a problem caused by puppet but something I can''t apparently > deploy with puppet unless someone has an idea. > > Trying to automate a way to deploy mod_mono for apache > > from CLI, the problem seems obvious... > > apt-get install -y --assume-yes libapache2-mod-mono mono-apache-server > libmono-firebirdsql1.7-cil > > a massive pile of packages installs and it finally arrives at the truth > moment: > > Configuration file `/etc/apache2/mods-available/mod_mono.conf'' > ==> File on system created by you or by a script. > ==> File also in package provided by package maintainer. > What would you like to do about it ? Your options are: > Y or I : install the package maintainer''s version > N or O : keep your currently-installed version > D : show the differences between the versions > Z : background this process to examine the situation > The default action is to keep your current version. > *** mod_mono.conf (Y/I/N/O/D/Z) [default=N] ? > > So it appears that the same target, mod_mono.conf is being created both by > script and a file in the package itself and it appears that all of the ''-y'' > or ''--assume-yes'' logic in the command itself will not allow an install to > progress without an interactive answer to the question - the answer to which > is essentially meaningless because I can control the file anyway with > puppet. > > Anyone have an idea how to defeat well intentioned but defective packager > logic? > >In this case I would probably modify the package itself to work around decisions made upstream that negatively affect what I do. Relatively smoothly, this can be done by downloading the debian source package, modifying it to not be silly (by your defintions), rolling it into your own local apt repo, and telling puppet to go to town installing it. I already do lots of package modifications to remove maintainer scripts ("post install" etc) from many many upstream packages in Ubuntu in my local repo. Much better, in my experience, than trying to make exceptions in puppet to handle misaligned upstream assumptions. -Jordan --> Craig White ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ craig.white@ttiltd.com > 1.800.869.6908 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ www.ttiassessments.com > > Need help communicating between generations at work to achieve your desired > success? Let us help! > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.