Difference between revisions of "Talk:Yum-plugin-priorities"

From SME Server
Jump to navigationJump to search
Line 11: Line 11:
 
#** If you suspect that the blocked update resolves a security issue, you must decide for yourself whether to compromise the original sme/centos package and force the update of the non-sme/centos package by running ''yum --noplugins --enablerepo=* update <pkgname>
 
#** If you suspect that the blocked update resolves a security issue, you must decide for yourself whether to compromise the original sme/centos package and force the update of the non-sme/centos package by running ''yum --noplugins --enablerepo=* update <pkgname>
  
==[[User:Mmccarn|Mmccarn]] 15:31, 22 November 2008 (UTC)==
+
:ok, we can report back to the bug
===perl-DBIx-DBSchema===
+
:- on a clean system priorities isn't needed, but won't hurt
Yes - I finally figured out that perl-DBIx-DBSchema was installed when I tried to install 'Resource Tracker' - they have their own repository....
+
:- if you've modified, this will protect you, but you may need to work through rare blocked updates, which can be documented
 
+
:- the yum fragment has to be modified in the base or a template-custom used
Clearly, we could choose to ignore this issue -- but just as clearly if we configure yum-plugin-priorities it will become possible to install 3rd party apps that later break yum.
 
 
 
In this case, perl-DBIx-DBSchema, which is ''not'' included with SME requires perl-DBIx-SearchBuilder which ''is'' included with SME - so the low priority repo locates and wants to update perl-DBIx-DBSchema, but the priorities plugin then prevents the install of the correct perl-DBIx-SearchBuilder.
 
 
 
We need  
 
* a plugin, method, or option that blocks the update of packages from 3rd party repos if the new version requires a package that is included with SME / Centos that has not yet been updated.
 
* a way to notify users of the blocked updates so they can decide if the blocked update involves a security issue
 
* '''or''' documentation on how to work around this issue, along the lines of "observe the problem, identify the blocking package, update the blocking package independently using the "--noplugins" option, then finish your update
 
 
 
:sn
 
:yes this is a big problem
 
:want to search or ask at the yum mailinglist, this should be a known problem
 
 
 
===Side note on security===
 
A major reason that I use SME server is that I feel the developers are highly security conscious, and that if I keep a SME server relatively virgin it will remain secure.  I don't have the knowledge, time or experience to evaluate every package available in Linux for its security exposure level.
 
 
 
Is there any easy way to scan a SME server, identify any installed packages that are not considered secure by the SME developers, then modify /etc/motd and add a note to server-manager stating that "unevaluated packages are installed"?
 
 
 
:Perhaps you can use the following audittool in your detection logic as it should report all contribs from 3d party repositories:
 
 
 
:<pre>/sbin/e-smith/audittools/newrps</pre>
 
:<small>—&nbsp;[[User:Cactus|Cactus]] ([[User talk:Cactus|talk]]&nbsp;|&nbsp;[[Special:Contributions/Cactus|contribs]])&nbsp;</small> 15:43, 22 November 2008 (UTC)
 
  
 
===Installation===
 
===Installation===

Revision as of 21:47, 24 November 2008

Mmccarn 15:00, 24 November 2008 (UTC)

Odd - all problems went away after update to SME 7.4. Apparently perl-DBIx-SearchBuilder is not in the smeos repo any more (as far as I can tell), so the perl-DBIx-DBSchema requirement for perl-DBIx-SearchBuilder is met from dag with no problems.

I can't find any useful discussions about overall yum-based solutions for this type of error (low-priority repo has an update that includes a 'require' for a newer version of a file from a high-priority repo), which leads me to the following conclusions / recommendations:

  1. This error will only manifest itself to idiots people like me who install experimental stuff on their servers.
  2. yum-plugin-priorities should therefor be included by default, with all sme/centos repos set to priority 10
  3. Potential errors should be handled in documentation, along the lines of:
    • if you install any contribs or non-sme packages using any form of --enablerepo=<xxx>, update with yum --enablerepo=* update (or separate --enablerepo=<xxx> arguments for every repo you've ever included using --enablerepo=) to make sure you get any available updates for your extra packages
    • If you get a 'missing dependancy error' from yum,
      • re-run yum manually using "--exclude <pkgname>" on the command line, replacing <pkgname> with the package that is preventing your update
      • If you suspect that the blocked update resolves a security issue, you must decide for yourself whether to compromise the original sme/centos package and force the update of the non-sme/centos package by running yum --noplugins --enablerepo=* update <pkgname>
ok, we can report back to the bug
- on a clean system priorities isn't needed, but won't hurt
- if you've modified, this will protect you, but you may need to work through rare blocked updates, which can be documented
- the yum fragment has to be modified in the base or a template-custom used

Installation

My "script" for modifying /etc/yum.conf is just my notes on how to make these changes easily and temporarily; I hadn't gotten around to making a custom template fragment yet...

Snoble 09:37, 22 November 2008 (UTC)

You should be able to use my script on 7.3 to populate the db

only difference is there will be a different fragment to modify /etc/yum.conf/something