Jean-Philippe PIALASSE
2018-02-15 21:44:44 UTC
Dear all,
Output from non dev, users, sysadmin are welcomed to 2 questions here below.
I have just made some advance on a group of rpm to configure extra
repositories easily on your SME : see
https://bugs.contribs.org/show_bug.cgi?id=10239
This will be a good change as you will be able to have it configured
without risking making a typo, and could also get updates in case the
mirror moves, also we could ease your migration from one version making
sure the path to the repo is right for the new version.
Speaking of mirrors, the current ongoing policy since SME8 is to keep
only the SME base, updates, addons and CentOS base, updates Visibles and
enabled to make an update installation.
Before SME8 only SME base, updates and addons were enabled to avoid
conflict from upstream. We got a huge improvement in security by
enabling upstream repositories, as you get the security updates fast. In
those years we saw a few issues with samba and clamav mostly, but not
that much compared to the advantage to get kernel and other security
patch as fast as possible.
There are currently more and more trustable repositories. We, however,
provide a configuration to add them to SME only as disabled and often
even as not Visible in the manager.
An example I have in mind is remi-safe
- :) provides php packages which need to be updated as fast as possible
in case of security vulnerability
- :) No packages are conflicting with base rpm (the repo is designed
this way)
- :( no an upstream vendor, but
- :) owner is a trustable member of the Fedora community.
- :) repository is available and stable for a few years
4 out of 4 elements make good reasons to have this repo enable and Visible
Another example Asterisk+ Digium repos
- :) provides asterisks packages which need to be updated as fast as
possible in case of security vulnerability
- :) No packages are conflicting with base rpm
- :) upstream vendor, but
- :) repository is available and stable for a few years
1/ What do you think about to update our policy in handling repositories
to make some enabled by default when they are installed? ( I do not mean
there to have them on a fresh install)
Continuing on the idea, we have smecontribs. This repo was originally
designed to host third party and members contribution. Another repo :
smeaddons, was designed to host contributions maintained by core
maintainers, and with content considered as much safer or verified.
What we see currently is that most of what is on smecontribs is
something maintained by regular contributors that are also implied in
the SME core development, or contributions that have been under a
verification process before importation.
2/ So is it still necessary to keep these repos as hidden and disabled
as default and giving the advice to keep it disabled ? This makes people
missing some potential important updates. Or should we simply start a
process to move a certain number of those contribs to the smeaddon repo ?
Jean-Philippe
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/ma
Output from non dev, users, sysadmin are welcomed to 2 questions here below.
I have just made some advance on a group of rpm to configure extra
repositories easily on your SME : see
https://bugs.contribs.org/show_bug.cgi?id=10239
This will be a good change as you will be able to have it configured
without risking making a typo, and could also get updates in case the
mirror moves, also we could ease your migration from one version making
sure the path to the repo is right for the new version.
Speaking of mirrors, the current ongoing policy since SME8 is to keep
only the SME base, updates, addons and CentOS base, updates Visibles and
enabled to make an update installation.
Before SME8 only SME base, updates and addons were enabled to avoid
conflict from upstream. We got a huge improvement in security by
enabling upstream repositories, as you get the security updates fast. In
those years we saw a few issues with samba and clamav mostly, but not
that much compared to the advantage to get kernel and other security
patch as fast as possible.
There are currently more and more trustable repositories. We, however,
provide a configuration to add them to SME only as disabled and often
even as not Visible in the manager.
An example I have in mind is remi-safe
- :) provides php packages which need to be updated as fast as possible
in case of security vulnerability
- :) No packages are conflicting with base rpm (the repo is designed
this way)
- :( no an upstream vendor, but
- :) owner is a trustable member of the Fedora community.
- :) repository is available and stable for a few years
4 out of 4 elements make good reasons to have this repo enable and Visible
Another example Asterisk+ Digium repos
- :) provides asterisks packages which need to be updated as fast as
possible in case of security vulnerability
- :) No packages are conflicting with base rpm
- :) upstream vendor, but
- :) repository is available and stable for a few years
1/ What do you think about to update our policy in handling repositories
to make some enabled by default when they are installed? ( I do not mean
there to have them on a fresh install)
Continuing on the idea, we have smecontribs. This repo was originally
designed to host third party and members contribution. Another repo :
smeaddons, was designed to host contributions maintained by core
maintainers, and with content considered as much safer or verified.
What we see currently is that most of what is on smecontribs is
something maintained by regular contributors that are also implied in
the SME core development, or contributions that have been under a
verification process before importation.
2/ So is it still necessary to keep these repos as hidden and disabled
as default and giving the advice to keep it disabled ? This makes people
missing some potential important updates. Or should we simply start a
process to move a certain number of those contribs to the smeaddon repo ?
Jean-Philippe
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/ma