[sles-beta] php disappeared in beta6?

[Joe Doupnik]

Lars,
     Your comments are very understandable. Yesterday I had a 
conversation with one of your colleagues about this and his view was 
also influenced by having available a range of helpful network 
facilities. I approach matters differently.
     There are a variety of views on putting together servers. Yours of 
patch immediately is one. Mine is build, test, polish, from the 
distribution DVD without network access, and then consider patching. Add 
variations in between.
     One asks what patching brings, whether security fixes or "improved" 
files, or what, and the answer is often all of this. Security we watch 
carefully, but the rest we keep at arm's length until we can deal with 
consequences.
     Servers are not always built with nice Internet connectivity, nor 
with customer center credentials handy, not with a list of sundry patch 
channels before our eyes. Insert DVD1, build, look, often isolated from 
worldly contact at this stage.
    The point is installation and initial building must not be dependent 
upon any network connectivity, nor upon presence of our black book with 
access codes. Further, we (at least myself) do not fully trust those 
"improved" additions until shown otherwise, so no automatic additions of 
them to a system.
     The second point in the discussion was complexity from additional 
channels. Finding the right channels is not easy, and then we must 
enable access to them, and so on through a bunch of detailed data entry. 
The existing channels illustrate this point.
     The third point is the initial build (DVD1) ought to be as complete 
as has been say SLES11. Provide the full release suite, not a hobbled 
one. Options, versions of this and that, can be on a second DVD, but 
spreading beyond that soon becomes impractical. If the size of Options 
is not large then put them on DVD1 as well.
     In fewer words, avoid external preconditions and try to minimise 
complexity and disruptive changes.
     I think those are the major worry points thus far. 
Corrections/modifications are most welcomed.
     Thanks,
     Joe D.

On 16/05/2014 22:52, Lars Marowsky-Bree wrote:
> On 2014-05-16T16:56:42, Simon Flood <S.M.Flood at ucs.cam.ac.uk> wrote:
>
> Hi all,
>
>> Now at this point I can see Matthias going "a-ha, that's modular". Well yes
>> it is in the sense that (for example) Apache would only be installed if
>> Ansible is building a web server but there wouldn't necessarily be any
>> external network access during the build process plus registration is
>> unlikely to change from now where we use internal YUM repos as opposed to
>> NCC/SCC or SMT.
> Okay, I'm going to out myself as probably a total dork here and that I'm
> completely misunderstanding the problem, but:
>
> I'm assuming that *any* SLES server that is deployed will be supplied
> with updates already, and that - in reality - noone will leave an
> unpatched GA/First-Customer-Shipment version running.
>
> *Especially* I can't believe that someone would deploy a *web server*
> without patching it, since that by definition is exposed to some client.
>
> (And I have this impression that most *web servers* will also have a
> network connection of some form, but that is actually not relevant.) And
> I also think a fair number of you are running some extensions on top of
> SLES too (of which obviously the most important one is SLE HA ;-). So:
>
> It follows that there is already some way - SMT, SCC, NCC, rsync,
> internal YUM repos, NFS network share, a USB stick, building updated
> media locally that incorporate all of that, re-imaging from a cloned
> golden image, what have you - to provide additional RPMs beyond the raw
> media to the server, even if the server itself doesn't have network
> connectivity.
>
> Is it just me or could the same channel be used for distributing these
> module packages to the servers?
>
> Sure, that means they have to be collected from one or two more official
> repositories. Yet it seems that that isn't quite the same as "hostage
> taking".
>
> I'm really a bit at a loss here. Why is it so terrible to install a few
> more RPMs that come from an officially supported source? Am I missing
> something fundamental? I feel I must be. What did we do wrong?
>
>
> The idea behind the Modules is to allow certain parts of the SLES
> ecosystem that are more dynamic to evolve more quickly, and make this
> explicit in possibly different lifecycles. And to possibly provide more
> alternatives and newer versions for those who want them too. And,
> possibly, make code available for which 10+3 years of support is just
> unrealistic, but that our customers/partners still want supported for N
> years rather than not having it at all. Matthias will explain this in
> more detail.
>
>
> Regards,
>      Lars
>