[sles-beta] php disappeared in beta6?

Thu May 15 10:38:30 MDT 2014

     I think there are several aspects in play here.
     One is registration, which is another bureaucratic hoop to jump 
when making an initial server. I want a DVD which builds a proper server 
just from its contents, a reasonable one by today's standards and not 
necessarily at the bleeding edge. I never register for other items when 
building a new server. The vendor is presumed to have tested the DVD 
contents as a unit. Once the server has settled in with much local 
material then I look at updating things.
     Another is growth of the number of channels we must seek out and 
support. This part of things deserves a high level review to make 
finding things a lot easier than at present. We already have the SDK 
collection (lots) and leading edge material could go there. I don' t 
relish adding lots and lots of channels (SMT here) to get common 
material, nor to store a lot which I don't need. We do it because we 
must today, SUSE does a really good job of supplying it, but the count 
can become too large. Pretty soon we might rename SMT to be Debian, 
nearly all parts little whole.
     A third is the current PHP should be on DVD1, as per usual, and 
then other versions (including back ones!) could be elsewhere. Removing 
PHP is not a smart move, as we have discussed at length.
     Lastly, show me code which is provably secure. Our goal is to 
provide robust attractive service in an imperfect world, not chase CS 
perfection.
     Thanks,
     Joe D.

On 15/05/2014 17:13, Richard Brown wrote:
> Theoretically speaking (ie. May someone step in and correct me if I'm
> wrong), the scenarios you provided to explain what you're doing with
> updates should also work for Modules
>
> Selecting a Module when Registering your system adds additional
> repositories for those Modules that have been selected, in just the same
> way that the SLES Update Repository is configured
>
> If you're using tricks like mirroring Update repositories in order to
> provide disk-bound updates to systems, the same technique should work
> with Modules (even if I think it's inadvisable - PHP in particular is
> not a stack I'd want to leave running with known holes in..)
>
> On Thu, 2014-05-15 at 14:19 +0000, Pieter Hollants wrote:
>> Similar here. I had stupid discussions with so-called system managers that complained about RAID controllers requiring an admin intervention when a hard disk is plugged in, because they were expecting a JBOD mode that wasn't supported on that particular RAID controller (but on smaller models). When asked why in heaven's sake they would carry around hard disks, they said "well, to roll out updates". And added, external hard drives would be too slow, even with USB 3.0. When I asked how they tested USB 3.0 when no standard server from the big vendors supports USB 3.0 yet, the answer was "well we plugged in a USB 3.0 controller"... then again, I asked what sort of updates they distribute, that would need entire hard disks. The answer finally blew me: "Well, we dd the partitions over after we make changes. And no, we don't trust rsync."
>>
>> So while this example anecdote of concrete wall-style administration is off-topic, it illustrates that we really do need ISOs. And I could live with "just one ISO with all addons" just as well. The process that won't work is that I manually collect RPMs from whatever online source, that won't scale.
>>
>> And while in our case PHP is but a smaller culprit, it is imaginable that the decision affects eg. Python as well?
>>
>> -----Ursprüngliche Nachricht-----
>> Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Wendy Palm
>> Gesendet: Donnerstag, 15. Mai 2014 15:59
>> An: Richard Brown; sles-beta at lists.suse.com
>> Betreff: Re: [sles-beta] php disappeared in beta6?
>>
>> We have many sites that are not connected to the internet due to security concerns.
>> All our systems are delivered and supported without direct network access.
>>
>> I download all the security update rpms, package them together and provide them to our customers via a secure connection.
>> They load them onto a drive (or burn to cd/dvd) and transfer the files to the internal network to do the updates.
>>
>> Unfortunately, one of our offerings does use php5, so requiring this registration and online access will inhibit our systems considerably.
>>
>>
>>> -----Original Message-----
>>> From: sles-beta-bounces at lists.suse.com [mailto:sles-beta-
>>> bounces at lists.suse.com] On Behalf Of Richard Brown
>>> Sent: Thursday, May 15, 2014 8:38 AM
>>> To: sles-beta at lists.suse.com
>>> Subject: Re: [sles-beta] php disappeared in beta6?
>>>
>>> On Thu, 2014-05-15 at 12:23 +0000, Pieter Hollants wrote:
>>>> And as long as your next German flight's security is guaranteed by
>>>> months-taking software approval procedures, we need ISOs, not online
>>>> repos.
>>> Possibly a naive question, but with such a software approval procedure
>>> how do you handle the deployment of software patches?
>>>
>>> In high security environments, I totally understand the need to
>>> prevent servers from direct internet access, but surely you still need
>>> to apply patches to your servers? Isn't this even more important for
>>> web scripting languages like PHP, which are often a common vector for
>>> attack?
>>>
>>> SUSE don't supply patches via ISOs, but provide SMT and SUSE Manager
>>> to give ways of getting those patches to internet-disconnected
>>> machines. It looks to me that Modules would slot into these two
>>> products in the same way that Patch sources do.
>>>
>>> (as an aside, SLE 12 in my test environment is autodetecting nearby
>>> SMT and SUSE Manager servers and offering to register against them
>>> instead of SCC. I haven't tested this yet)
>>>
>>> I see some benefit of being able to install PHP via an ISO, but after
>>> anything longer than a few weeks I'd be deathly concerned about
>>> putting it in production, as it would be unpatched and therefore most
>>> likely vulnerable.
>>>
>>> Regards,
>>>
>>> --
>>> -------------------------------------------------------------------
>>>    Richard Brown, QA Engineer
>>>    Phone +4991174053-361,  Fax +4991174053-483
>>>    SUSE LINUX Products GmbH,  Maxfeldstr. 5,  D-90409 Nuernberg
>>>    Geschaeftsfuehrer: Jeff Hawn, Jennifer Guild, Felix Imendoerffer,
>>>    HRB 16746 (AG Nuernberg)
>>> -------------------------------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> sles-beta mailing list
>>> sles-beta at lists.suse.com
>>> http://lists.suse.com/mailman/listinfo/sles-beta
>> _______________________________________________
>> sles-beta mailing list
>> sles-beta at lists.suse.com
>> http://lists.suse.com/mailman/listinfo/sles-beta
>>
>> DFS Deutsche Flugsicherung GmbH
>> Am DFS-Campus
>> D - 63225 Langen
>>
>> Tel.: +49-(0)6103-707-0
>>
>> Sitz der Gesellschaft: Langen/Hessen
>> Zuständiges Registergericht: AG Offenbach am Main, HRB 34977
>> Vorsitzender des Aufsichtsrates: Michael Odenwald
>> Geschäftsführer: Prof. Klaus-Dieter Scheurle (Vors.), Robert Schickling, Dr. Michael Hann
>>
>> Internet: http://www.dfs.de
>> Public-Key der DFS: http://www.dfs.de/dfs/public_key.asc <http://www.dfs.de/dfs/public_key.asc>
>>
>