[sles-beta] php disappeared in beta6?

Sun May 18 17:27:56 MDT 2014

Lars and beta Team

I have stood out of this discussion so far but feel I need to make a
contribution.

With the SLES deployment I have done for clients, approx zero were setup
with immediate internet access as all clients have stick protocols
regarding server builds and access to internet for servers.

Even when we have SMT/Zenworks servers available, it's NEVER been
considered good form to have patches installed at build time (how do you
get to a "know good" build state if you are changing packages "on the
fly"?).

The installation media should be all that's needed for a complete server OS
install. If there are "critical" issue with the installation media, it
should be reissued with the fixes integrated.

I'm not saying that server should not be fully patched, that is also a
critical requirement for all of my customers, although what qualifies as
"fully patched" does also need to meet vendor support requisitions of the
mission critical third party apps. There are some critical application
pieces from large companies (I will call out Oracle specifically here)
where the "vendor support matrix" is almost NEVER the current patch level.

If the build process REQUIRES on-line registration and patching, then the
build process is wrong.

Regards
Darren

On 18 May 2014 21:10, Lars Marowsky-Bree <lmb at suse.com> wrote:

> On 2014-05-17T09:40:34, Joe Doupnik <jrd at netlab1.net> wrote:
>
> Dear Joe,
>
> >     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.
>
> I can empathize with this approach to a point. Yet, as you state, I'd
> imagine that security patches would be deployed immediately. And if
> certain changes are considered risky (I obviously would disagree, given
> the quality of our development processes and QA ;-), one certainly
> would want to deploy them early and test them at built time of a server,
> right? Catch things early, and not in production?
>
> And I'd assume that the probability of someone wanting/needing a
> specific (non-security) fix to make their scenario work is greater than
> zero too; if noone needed it, we'dn't have patched it. Hence, again, a
> mechanism for deploying updates (at install time or later) must exist,
> or the deployment process is broken.
>
> > 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.
>
> I didn't say anything about automatic updates. Just that *some* way of
> applying post-GA/FCS packages to any meaningful server must exists, and
> that this same mechanism can be used to include the additional module
> packages.
>
> >     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.
>
> For installing a server that you don't want to register (which seems to
> be the concern here), this isn't strictly necessary. Just grab the RPMs
> and deploy. Sure, you need to identify the packages once, or at least
> register one server for convenience - but "zypper in --download-only"
> isn't really a huge effort?
>
> I obviously trust that you would still have sufficient subscriptions for
> all servers deployed ;-)
>
> >     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.
>
> The initial build is, for all intents and purposes, not the single means
> by which to deploy a production server within latest one to three months
> after release. There'll always be at least one security bug in that
> time frame. Realistically speaking, despite all the QA and effort we put
> into development, and our esteemed beta testers, there are also going to
> be additional important fixes people will want very quickly.
>
> Hence, there *must* be a way to include post-initial-build packages in
> your process, certainly?
>
> And, uhm, not to put too fine a point to it, but where did you get DVD1
> or a supposed DVD2? Did you, by chance, download it? ;-) So there must
> be *some* system with network connectivity that you can access and
> download packages too! ;-)
>
> > 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.
>
> I can see the desire for convenience here. I won't, can't, and do not
> want to speak for PM, but perhaps this could be considered.
>
> Yet again, the packages on DVD2 will be outdated very soon after the
> initial build was shipped. It is my sincere hope that someone deploying,
> say, PHP, has a process by which they can ship updates to their servers.
>
> It is true that this new model emphasizes this and having a process that
> is not just effective but reasonably efficient at distributing packages
> will be a big boost. And clearly it'll work better for servers that do
> have access to SCC or an internal SMT/Manager instance; just like for
> deploying updates in general. But this is still a far cry from "hostage
> taking."
>
> SMT is even free of charge.
>
> I agree this change comes late in the beta cycle. That is unfortunate
> and I can understand that this may cause some irritation among our
> testers, since this is something you legitimately would have wanted to
> test early. I doubt anyone from SUSE would disagree with that. That was
> not intentional.
>
> But if you look beyond this temporary hurdle of a slight change (some
> might call it improvement ;-) to your deployment and update processes,
> what is your opinion on the basic idea behind modules and the value they
> are supposed to provide? Additional supported updates and features for
> the faster moving parts of the software eco system?
>
> To me, that sounds like a very good thing.
>
>
> Regards,
>     Lars
>
> --
> Architect Storage/HA
> SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix
> Imendörffer, HRB 21284 (AG Nürnberg)
> "Experience is the name everyone gives to their mistakes." -- Oscar Wilde
>
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta
>

-- 

Darren Thompson

Professional Services Engineer / Consultant

 *[image: cid:image001.jpg at 01CB7C0C.6C6A2AE0]*

Level 3, 60 City Road

Southgate, VIC 3006

Mb: 0400 640 414

Mail: darrent at akurit.com.au <steve at akurit.com.au>
Web: www.akurit.com.au
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.suse.com/mailman/private/sles-beta/attachments/20140519/7cb26b3b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 3692 bytes
Desc: not available
URL: <http://lists.suse.com/mailman/private/sles-beta/attachments/20140519/7cb26b3b/attachment.jpg>