| 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>— [[User:Cactus|Cactus]] ([[User talk:Cactus|talk]] | [[Special:Contributions/Cactus|contribs]]) </small> 15:43, 22 November 2008 (UTC)
| |
| | | | |
| | ===Installation=== | | ===Installation=== |
