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

From SME Server
Jump to navigationJump to search
m (Added a remark on detecting 3rd party packages)
 
(6 intermediate revisions by 3 users not shown)
Line 1: Line 1:
==[[User:Mmccarn|Mmccarn]] 15:31, 22 November 2008 (UTC)==
+
:summary
===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.
+
If you are only using two priority levels why not look at protectbase.  It basically does the same thing and you only have to indicate which repos you want to protect <small>— [[User:Slords|Slords]] ([[User talk:Slords|talk]] • [[Special:Contributions/Slords|contribs]]).</small> 22:32, 24 November 2008 (UTC)
  
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.
+
Is there a technical reason to prefer 'protectbase' over 'priorities'?  If not, I'd prefer to stay with 'priorities' because, even though we're not advocating it for general use, it does have some more power for advanced users, or for future situations (I keep having ideas about this that turn out to be irrelevant when I start writing them down...)
* 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 independantly using the "--noplugins" option, then finish your update
 
 
 
===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>
+
I think 'priorities' is easier/safer since 'protectbase' defaults all non-specified repos to 'protected', while 'priorities' defaults non-specified repos to priority 99.  If we use 'protectbase' we have to make sure all users set all custom repos to unprotected or else they will be protected, while with 'priorities' all custom repos default to the "correct" behavior.
:<small>—&nbsp;[[User:Cactus|Cactus]] ([[User talk:Cactus|talk]]&nbsp;|&nbsp;[[Special:Contributions/Cactus|contribs]])&nbsp;</small> 15:43, 22 November 2008 (UTC)
 
  
===Installation===
+
I suppose this could be resolved by having the template expansion default repos to unprotected for any repo where "protect" is not set.
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...
 
  
==[[User:Snoble|Snoble]] 09:37, 22 November 2008 (UTC)==
+
[[User:Mmccarn|Mmccarn]] 14:43, 25 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
 
  
 
----
 
----
 +
I don't see how protectbase is any easier to configure, given that we need a template to default  non-specified repos to unprotected.
  
perl-DBIx-DBSchema is not installed by default, I don't have either of the below rpms installed
+
I suggest we add the template, db values and Requires to smeserver-yum
 
 
I tried to install with priority=10 and couldn't, same error as you
 
  
with priority=99 it would install
+
[[User:Snoble|Snoble]] 00:18, 26 November 2008 (UTC)
yum install --enablerepo=dag perl-DBIx-DBSchema
 
 
=============================================================================
 
  Package                Arch      Version          Repository        Size
 
=============================================================================
 
Installing:
 
  perl-DBIx-DBSchema      noarch    0.36-1.el4.rf    dag                70 k
 
Installing for dependencies:
 
  perl-DBD-Pg            i386      2.11.1-1.el4.rf  dag              286 k
 

Latest revision as of 01:18, 26 November 2008

summary
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

If you are only using two priority levels why not look at protectbase. It basically does the same thing and you only have to indicate which repos you want to protect Slords (talkcontribs). 22:32, 24 November 2008 (UTC)


Is there a technical reason to prefer 'protectbase' over 'priorities'? If not, I'd prefer to stay with 'priorities' because, even though we're not advocating it for general use, it does have some more power for advanced users, or for future situations (I keep having ideas about this that turn out to be irrelevant when I start writing them down...)

I think 'priorities' is easier/safer since 'protectbase' defaults all non-specified repos to 'protected', while 'priorities' defaults non-specified repos to priority 99. If we use 'protectbase' we have to make sure all users set all custom repos to unprotected or else they will be protected, while with 'priorities' all custom repos default to the "correct" behavior.

I suppose this could be resolved by having the template expansion default repos to unprotected for any repo where "protect" is not set.

Mmccarn 14:43, 25 November 2008 (UTC)


I don't see how protectbase is any easier to configure, given that we need a template to default non-specified repos to unprotected.

I suggest we add the template, db values and Requires to smeserver-yum

Snoble 00:18, 26 November 2008 (UTC)