Bug 329261 - Bad interaction of yum-cron and yum-merge-conf
Summary: Bad interaction of yum-cron and yum-merge-conf
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: yum-utils
Version: 7
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
Assignee: Seth Vidal
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-10-12 10:53 UTC by Neal Becker
Modified: 2008-03-13 14:12 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-03-13 14:12:55 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Neal Becker 2007-10-12 10:53:55 UTC
Description of problem:
I just got this mail:

A message that you sent was longer than the maximum size allowed on this
system. It was not delivered to any recipients.

------ This is a copy of your message, including all the headers.
------ No more than 100K characters of the body are included.

From: root (Cron Daemon)
From: root.org (Cron Daemon)
To: root
To: root.org
Subject: Cron <root@nbecker> run-parts /etc/cron.daily
Content-Type: text/plain; charset=UTF-8
Auto-Submitted: auto-generated
X-Cron-Env: <SHELL=/bin/bash>
X-Cron-Env: <PATH=/sbin:/bin:/usr/sbin:/usr/bin>
X-Cron-Env: <MAILTO=root>
X-Cron-Env: <HOME=/>
X-Cron-Env: <LOGNAME=root>
X-Cron-Env: <USER=root>
Message-Id: <E1IgGu0-00025m-EZ.org>
Date: Fri, 12 Oct 2007 05:33:52 -0400

/etc/cron.daily/yum.cron:


Package dovecot: merging configuration for file "/etc/dovecot.conf":
By default, RPM would keep your local version and rename the new one 
to /etc/dovecot.conf.rpmnew
What do you want to do ?
 - diff the two versions (d)
 - do the default RPM action (q)
 - install the package's version (i)
 - merge interactively with vim (v)
 - background this process and examine manually (z)
Your answer ? Unknown answer, please try again
By default, RPM would keep your local version and rename the new one 
to /etc/dovecot.conf.rpmnew
What do you want to do ?
 - diff the two versions (d)
 - do the default RPM action (q)
 - install the package's version (i)
 - merge interactively with vim (v)
 - background this process and examine manually (z)
Your answer ? Unknown answer, please try again
[... repeat forever...]

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Habig, Alec 2007-10-12 13:34:11 UTC
Ok, makes sense - interactive stuff doesn't play well with cron stuff.

What we need is the "--disableplugin=merge-conf" option to turn off the
merge-conf plugin in the cron jobs.  For a quick workaround, can you add that
option to the yum calls in /etc/cron.daily/yum.cron and /etc/cron.weekly/yum.cron ?

However, this option appears to be in F-7's yum but not FC-6's yum.  Will find
the version where the option was added, and simply put a conflict in between
yum-cron and yum-merge-conf for earlier versions of yum. 


Comment 2 Neal Becker 2007-10-12 13:40:28 UTC
Also, someone needs to fix merge-conf to not suffer infinite runtime on this 
error!

Comment 3 Habig, Alec 2007-10-12 16:15:21 UTC
The simplest thing would be for merge-conf to honor the "-y" flag.  "-y" means
"assume that the answer to any question which would be asked is yes", and so is
always going to be used if yum is in non-interactive mode.  

Looks like "-q" also might be something which merge-conf might want to trap.  In
either the case of "-y" or "-q", a user won't be around (or able) to answer the
questions posed by merge-conf, so the plugin might want to bail.

Will ping the maintainer of merge-conf to see what he thinks.


Comment 4 Habig, Alec 2007-10-18 22:12:21 UTC
Looked into this a bit more.

The merge-conf plugin claims to only function if one says "--merge-conf".
Which yum-cron does not, so regardless of any sane handling of -q or -y,
merge-conf should not be running when yum-cron calls yum without specifying
--merge-conf.

Looking at the plugin code, it appears to my untrained eye (ie, I have no clue
what the methods might be inheriting from elsewhere) that the plugin's command
line parser is not actually doing anything with the --merge-conf switch:

def config_hook(conduit):
    parser = conduit.getOptParser()
    if parser:
        parser.add_option('--merge-conf', action='store_true', 
                      help='Merge configuration changes after installation')

For comparson, the downloadonly plugin sets a variable and its default value,
then checks on that variable later before actually running:

def config_hook(conduit):
    parser = conduit.getOptParser()
    parser.add_option('', '--downloadonly', dest='dlonly', action='store_true',
           default=False, help="don't update, just download")

So, two things for the merge-conf plugin people to fix.  One, make it actually
obey its command line switch, and two, check to see if yum has been invoked with
either -y or -q, in which case assume that there won't be a human sitting there
to interact with the plugin's questions and not execute (or at least complain
gracefully).

So, I'm re-assigning this bug to the yum-utils package, from whence comes
yum-merge-conf.


Comment 5 Seth Vidal 2008-03-13 14:12:55 UTC
Okay, this is a mess.

I think I'm going to assume that if

yum -y is given on the command line then mergeconf is disabled. There are just
too many questions to reasonably answer. Also adding the author of the plugin to
the CC list

Aurelien, if you'd like to submit a new mergeconf to include in yum-utils, I'd
be happy to take a look.

I've modified merge-conf in upstream to behave as I've said above.



Note You need to log in before you can comment on or make changes to this bug.