From mahendral at millenniumit.com  Mon May 12 03:55:37 2014
From: mahendral at millenniumit.com (Laxman, Mahendra)
Date: Mon, 12 May 2014 09:55:37 +0000
Subject: [sles-beta] Tasks get stuck with RT priority
In-Reply-To: <1399614536.5200.35.camel@marge.simpson.net>
References: <7E0FF7E78901584F9F0EC5E69214670723B93DE7@LG-SPMB-MBX01.lseg.stockex.local>
	<20140506123618.GE21258@fm.suse.cz> 
	<049A43DFF32DB14DBA34752BE3659AED241ED5D6@LG-SPMB-MBX01.lseg.stockex.local>
	<1399614536.5200.35.camel@marge.simpson.net>
Message-ID: <049A43DFF32DB14DBA34752BE3659AED241EE942@LG-SPMB-MBX01.lseg.stockex.local>

Hi Mike, 

Thanks for the comments, which solved several of our problems. 
Happy to hear that there is an on-going  work to provide the near bare metal behaviour.
Can you please provide a pointer or resource with more information related to the on-going development of that feature. 

Regards,
Mahendra. 

-----Original Message-----
From: Mike Galbraith [mailto:mgalbraith at novell.com] 
Sent: 09 May 2014 11:19
To: Laxman, Mahendra
Cc: 'Libor Pechacek'; Indika Prasad Kumara; Michael Galbraith; sles-beta at lists.suse.com
Subject: RE: [sles-beta] Tasks get stuck with RT priority

On Fri, 2014-05-09 at 04:27 +0000, Laxman, Mahendra wrote:
> Hi Libor,
> 
> Thanks for the suggestions. We have tested them and still see the 
> kworker get stuck in the run queue. Afaik I think keeping kworker not 
> scheduled for a long time is not good. Further we found gpg is get 
> stuck when any one of the kworkes running in each core is get stuck.

Yes.  Starving your own kernel indefinitely is a bad idea.  As things stand, you simply cannot safely saturate any core.  No matter what you do, workqueues may need to run even on an isolated core, so taking a brief breath to let them run is a must.  That will change, but in the here and now, 100.0% saturation is dangerous.

One aspect of that you met, tasks on non-isolated cores may depend upon a workqueue running on the core you are monopolizing to make progress, so your rt hog can block other tasks all over the box indefinitely.

> By the way we had already tested several of the settings you have 
> suggested other than the 'echo -1
> > /proc/sys/kernel/sched_rt_runtime_us'.
> This looks promising that now stress will monopolize the given core.
> We see zero context switches of stress with this settings.

Yes, if you really want to saturate with rt tasks, turning the throttle off is a must.  You also want it turned off because it is a global throttle.  When the timer fires, the CPU running that timer will
traverse the entire box, perturbing all.   Should the timer happen to
run on your critical CPU, it will spend quite a few cycles doing that instead of doing your latency critical work.
> 
> The issue is when running gpg, It doesn't matter whether we isolated 
> the core, until the kworker is stuck, gpg will be stuck. See the stack 
> of the gpg below when it is stuck. Afaik I think flush_work is a work 
> which submitted to work queues (kworkers) of all cores by the gpg (on 
> behalf of gpg), since that work does not served in the stressed core, 
> gpg get stuck.
> 
> # cat /proc/`pidof gpg`/stack
> [<ffffffff8107c102>] flush_work+0x22/0x30 [<ffffffff8107c223>] 
> schedule_on_each_cpu+0xb3/0xf0 [<ffffffff81123055>] 
> sys_mlock+0x45/0x130 [<ffffffff81466712>] 
> system_call_fastpath+0x16/0x1b [<00007fbf0f286aa7>] 0x7fbf0f286aa7 
> [<ffffffffffffffff>] 0xffffffffffffffff

That is the exact situation I mentioned above.  Until you allow the kworker thread your rt hog is blocking to run, that synchronization will not ever complete, that pgp task is as good as dead.

What you want, but currently cannot have, is bare metal.  A feature to get as close to that as possible is underway, but not ready for primetime.  When that effort is complete, you will no longer need to run your polling task with rt policy/priority, the improved isolation will remove the competition you are trying in vain to keep completely away from your precious core.
> 
-Mike



This e-mail transmission (inclusive of any attachments) is strictly confidential and intended solely for the ordinary user of the e-mail address to which it was addressed. It may contain legally privileged and/or CONFIDENTIAL information. The unauthorized use, disclosure, distribution printing and/or copying of this e-mail or any information it contains is prohibited and could, in certain circumstances, constitute an offence. If you have received this e-mail in error or are not an intended recipient please inform the sender of the email and MillenniumIT immediately by return e-mail or telephone (+94-11) 2416000. We advise that in keeping with good computing practice, the recipient of this e-mail should ensure that it is virus free. We do not accept responsibility for any virus that may be transferred by way of this e-mail. E-mail may be susceptible to data corruption, interception and unauthorized amendment, and we do not accept liability for any such corruption, interception or amendment or any consequences thereof.  www.millenniumit.com 


From mgalbraith at novell.com  Mon May 12 04:12:40 2014
From: mgalbraith at novell.com (Mike Galbraith)
Date: Mon, 12 May 2014 12:12:40 +0200
Subject: [sles-beta] Tasks get stuck with RT priority
In-Reply-To: <049A43DFF32DB14DBA34752BE3659AED241EE942@LG-SPMB-MBX01.lseg.stockex.local>
References: <7E0FF7E78901584F9F0EC5E69214670723B93DE7@LG-SPMB-MBX01.lseg.stockex.local>
	<20140506123618.GE21258@fm.suse.cz>
	<049A43DFF32DB14DBA34752BE3659AED241ED5D6@LG-SPMB-MBX01.lseg.stockex.local>
	<1399614536.5200.35.camel@marge.simpson.net>
	<049A43DFF32DB14DBA34752BE3659AED241EE942@LG-SPMB-MBX01.lseg.stockex.local>
Message-ID: <1399889560.14507.11.camel@marge.simpson.net>

On Mon, 2014-05-12 at 09:55 +0000, Laxman, Mahendra wrote:

> Can you please provide a pointer or resource with more information
> related to the on-going development of that feature. 

I can give you the kernel config option, CONFIG_NO_HZ_FULL.

An info pointer I can't give, other that to point you at the linux
kernel mailing list, where the work needed to support it is scattered
all over the kernel map, RCU, timers, workqueues, the works.

Subscribing to LKML will get you all of the traffic, and oh, around 800
or so messages per day.  Buyer beware, it's a fire-hose, trying to keep
track of what's going on there is a full time job and then some.

LKML destructions:
send message body "subscribe linux-kernel" to majordomo at vger.kernel.org

-Mike


From Klaus.Gmeinwieser at oce.com  Mon May 12 05:24:06 2014
From: Klaus.Gmeinwieser at oce.com (Klaus Gmeinwieser)
Date: Mon, 12 May 2014 13:24:06 +0200
Subject: [sles-beta] B5 Autoyast netowrk config
Message-ID: <5370AF56.3040706@oce.com>

Hi all,

I was just working on the autoyast file for mass installations of
different servers using a single file and removing all options not
needed and to be replaced by autoyast with the default settings...

I found a xml tag which reads

<keep_installation_network>

which I assume to keep the network configuration. But which
configuration is addressed with this tag? The network which was used for
installation of the OS over the network?

I remember a discussion on one of the SUSE Expert Forums, where
information about a popup window was given, which should be ask for the
final network configuration to be manually entered in order to remove
the need of a dedicated network config after install finished.

If not using austoyast for installation, there is a possibility for
network setup for registration. Is this functionality planned for a
later beta, or did I miss the removal of the feature? As for me, this
feature would be very very good, as the need for an additional reboot
would be eliminated and I suppose, that it also would be possible to set
a default network setting which is to be overwritten by the manual input...

Please advise about this issue

Thanks a lot in advance
Klaus


--
Klaus Gmeinwieser
T +49 (0)8121 72 4358 F +49 (0)8121 72 3173
E klaus.gmeinwieser at oce.com W www.oce.com

Oc? Printing Systems GmbH & Co. KG ? A Canon Group Company
P.O. Box 1260 ? 85581 Poing
Siemensallee 2 ? 85586 Poing ? Germany

Oc? enables its customers to manage their documents efficiently and
effectively by offering
innovative print and document management products and services for
professional
environments.

Oc? Printing Systems GmbH & Co. KG
The company is a limited partnership with its registered office in Poing
? Trade Register HRA 100955 (Amtsgericht M?nchen) ? WEEE-Reg.-No. DE 888
05 443

General Partner: Oc? Printing Systems Gesch?ftsf?hrungsgesellschaft mbH
Registered Office: Poing ? Trade Register HRB 206480 (Amtsgericht M?nchen)
Executive Officer: Andr? Mittelsteiner, Hans Manzer
This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation.

From kdupke at suse.com  Mon May 12 06:30:45 2014
From: kdupke at suse.com (Kai Dupke)
Date: Mon, 12 May 2014 14:30:45 +0200
Subject: [sles-beta] Tasks get stuck with RT priority
In-Reply-To: <049A43DFF32DB14DBA34752BE3659AED241EE942@LG-SPMB-MBX01.lseg.stockex.local>
References: <7E0FF7E78901584F9F0EC5E69214670723B93DE7@LG-SPMB-MBX01.lseg.stockex.local>	<20140506123618.GE21258@fm.suse.cz>
	<049A43DFF32DB14DBA34752BE3659AED241ED5D6@LG-SPMB-MBX01.lseg.stockex.local>	<1399614536.5200.35.camel@marge.simpson.net>
	<049A43DFF32DB14DBA34752BE3659AED241EE942@LG-SPMB-MBX01.lseg.stockex.local>
Message-ID: <5370BEF5.3070802@suse.com>

On 05/12/2014 11:55 AM, Laxman, Mahendra wrote:
> Happy to hear that there is an on-going  work to provide the near bare metal behaviour.

You might not be surprised that we have it on the list for features to
look into for our Real Time product, but it still is some way to go.

greetings
Kai Dupke
Senior Product Manager
Server Product Line
-- 
Phone:  +49-(0)5102-9310828     Mail: kai.dupke at suse.com
Mobile: +49-(0)173-5876766      WWW:  www.suse.com

SUSE Linux Products GmbH - Maxfeldstr. 5 - 90409 Nuernberg (Germany)
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG Nurnberg)

From fcrozat at suse.com  Mon May 12 06:34:35 2014
From: fcrozat at suse.com (Frederic Crozat)
Date: Mon, 12 May 2014 14:34:35 +0200
Subject: [sles-beta] SLES12 x86_64 Systemd reload service ??
In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0EFB3AFD@HXMB12.pnet.ch>
References: <40637DBB36AF3941B243A286A432CA0B0EFB3AFD@HXMB12.pnet.ch>
Message-ID: <1399898075.22538.40.camel@par-r81vxc7.par.novell.com>

Le jeudi 08 mai 2014 ? 13:49 +0000, urs.frey at post.ch a ?crit :
> Hi
>  
> I have SLES12 x86_64 installed and I would like to reload cron after
> having defined a new cron-job
> I can see on SLES12 x86_64 , that there cronie still gets installed
> under /etc/init.d
> There is still and rccron link pointoig to sysvinit /etc/init.d

Because there is a systemd .service file, it is taking precedence over
the init.d file.

This init.d file should be dropped from the package, rccron symlinks
should be updated accordingly and cron.service is missing a ExecReload
command.

Could you open a service request to track this issue ?

Thanks !



-- 
Frederic Crozat
Project Manager Enterprise Desktop
SUSE


From urs.frey at post.ch  Mon May 12 07:31:39 2014
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Mon, 12 May 2014 13:31:39 +0000
Subject: [sles-beta] SLES12 x86_64 Systemd reload service ??
In-Reply-To: <1399898075.22538.40.camel@par-r81vxc7.par.novell.com>
References: <40637DBB36AF3941B243A286A432CA0B0EFB3AFD@HXMB12.pnet.ch>
	<1399898075.22538.40.camel@par-r81vxc7.par.novell.com>
Message-ID: <40637DBB36AF3941B243A286A432CA0B0EFB4B85@HXMB12.pnet.ch>

Thank you
I have opened a service request in this issue

SUMMARY OF SR # 10892154651 
  * SR Severity Level: Medium  
  * SR Brief Description: SLES12 Beta5 x86_64: cron service can not be reloaded, not yet integrated to systemd

Best regards

Urs Frey????????????????????????????????????????????? 
Post CH AG
Informationstechnologie
IT Betrieb 
Webergutstrasse 12 
3030 Bern (Zollikofen) 
Telefon : ++41 (0)58 338 58 70 
FAX???? : ++41 (0)58 667 30 07 
E-Mail:?? urs.frey at post.ch

-----Urspr?ngliche Nachricht-----
Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Frederic Crozat
Gesendet: Monday, May 12, 2014 2:35 PM
An: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] SLES12 x86_64 Systemd reload service ??

Le jeudi 08 mai 2014 ? 13:49 +0000, urs.frey at post.ch a ?crit :
> Hi
>  
> I have SLES12 x86_64 installed and I would like to reload cron after
> having defined a new cron-job
> I can see on SLES12 x86_64 , that there cronie still gets installed
> under /etc/init.d
> There is still and rccron link pointoig to sysvinit /etc/init.d

Because there is a systemd .service file, it is taking precedence over
the init.d file.

This init.d file should be dropped from the package, rccron symlinks
should be updated accordingly and cron.service is missing a ExecReload
command.

Could you open a service request to track this issue ?

Thanks !



-- 
Frederic Crozat
Project Manager Enterprise Desktop
SUSE

_______________________________________________
sles-beta mailing list
sles-beta at lists.suse.com
http://lists.suse.com/mailman/listinfo/sles-beta

From Klaus.Gmeinwieser at oce.com  Mon May 12 08:07:43 2014
From: Klaus.Gmeinwieser at oce.com (Klaus Gmeinwieser)
Date: Mon, 12 May 2014 16:07:43 +0200
Subject: [sles-beta] Missing Software packages on SLES12 but available on
	SLES11
Message-ID: <5370D5AF.1090205@oce.com>

Hi all,

while looking for packages we used with our SLES11 Builds I encountered
that some packages being part of SLES11 DVD will not be part of SLES12.

Missing is at least for my first check:

- a2ps
- xrdp
- ulimit
- jpeg
- mozilla-xulrunner

Is this correct that these packages/functionality disappear? Has the
packaging of the RPMs changed?

Or is the package list of SLES12 not yet final?

Please advise

Thanks & Best regards
Klaus

--
Klaus Gmeinwieser
T +49 (0)8121 72 4358 F +49 (0)8121 72 3173
E klaus.gmeinwieser at oce.com W www.oce.com

Oc? Printing Systems GmbH & Co. KG ? A Canon Group Company
P.O. Box 1260 ? 85581 Poing
Siemensallee 2 ? 85586 Poing ? Germany

Oc? enables its customers to manage their documents efficiently and
effectively by offering
innovative print and document management products and services for
professional
environments.

Oc? Printing Systems GmbH & Co. KG
The company is a limited partnership with its registered office in Poing
? Trade Register HRA 100955 (Amtsgericht M?nchen) ? WEEE-Reg.-No. DE 888
05 443

General Partner: Oc? Printing Systems Gesch?ftsf?hrungsgesellschaft mbH
Registered Office: Poing ? Trade Register HRB 206480 (Amtsgericht M?nchen)
Executive Officer: Andr? Mittelsteiner, Hans Manzer
This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation.

From mge at suse.com  Mon May 12 08:20:53 2014
From: mge at suse.com (Matthias G. Eckermann)
Date: Mon, 12 May 2014 16:20:53 +0200
Subject: [sles-beta] Missing Software packages on SLES12 but available
 on SLES11
In-Reply-To: <5370D5AF.1090205@oce.com>
References: <5370D5AF.1090205@oce.com>
Message-ID: <20140512142053.GB1137@suse.com>

Hello Klaus and all,

On 2014-05-12 T 16:07 +0200 Klaus Gmeinwieser wrote:

> while looking for packages we used with our SLES11
> Builds I encountered that some packages being part of
> SLES11 DVD will not be part of SLES12.
> 
> Missing is at least for my first check:
> 
> - a2ps

removed on purpose; our recommendation is enscript.

> - xrdp

This seems to be missing, but should be there
(FATE#317086).  Please open an SR, and we'll take
it from there.

> - ulimit

This is not necessary anymore, as "ulimit" like
limitations should be defined via systemd.

> - jpeg

The shared libraries are there. Do you mean the
commandline tools?  If yes, please open an SR, and
we'll discuss internally.

> - mozilla-xulrunner

If I remember, the Mozilla people stopped xulrunner
to be packaged separately, but I might be wrong.
 
> Is this correct that these packages/functionality
> disappear? Has the packaging of the RPMs changed?
> 
> Or is the package list of SLES12 not yet final?

Hope, my comments help.

so long -
	MgE

-- 
Matthias G. Eckermann     Senior Product Manager   SUSE? Linux Enterprise
Phone: +49 30 44315731    Mobile: +49 179 2949448    E-Mail: mge at suse.com
SUSE LINUX Products GmbH  Maxfeldstra?e 5          90409 N?rnberg Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg)

From Klaus.Gmeinwieser at oce.com  Mon May 12 08:23:50 2014
From: Klaus.Gmeinwieser at oce.com (Klaus Gmeinwieser)
Date: Mon, 12 May 2014 16:23:50 +0200
Subject: [sles-beta] Missing Software packages on SLES12 but available
 on SLES11
In-Reply-To: <20140512142053.GB1137@suse.com>
References: <5370D5AF.1090205@oce.com> <20140512142053.GB1137@suse.com>
Message-ID: <5370D976.3020204@oce.com>

Hi Matthias,

I appreciate you very very quick answer...

Will open service requests on this.

Regards
Klaus

Am 12.05.2014 16:20, schrieb Matthias G. Eckermann:
> Hello Klaus and all,
>
> On 2014-05-12 T 16:07 +0200 Klaus Gmeinwieser wrote:
>
>> while looking for packages we used with our SLES11
>> Builds I encountered that some packages being part of
>> SLES11 DVD will not be part of SLES12.
>>
>> Missing is at least for my first check:
>>
>> - a2ps
>
> removed on purpose; our recommendation is enscript.
>
>> - xrdp
>
> This seems to be missing, but should be there
> (FATE#317086).  Please open an SR, and we'll take
> it from there.
>
>> - ulimit
>
> This is not necessary anymore, as "ulimit" like
> limitations should be defined via systemd.
>
>> - jpeg
>
> The shared libraries are there. Do you mean the
> commandline tools?  If yes, please open an SR, and
> we'll discuss internally.
>
>> - mozilla-xulrunner
>
> If I remember, the Mozilla people stopped xulrunner
> to be packaged separately, but I might be wrong.
>
>> Is this correct that these packages/functionality
>> disappear? Has the packaging of the RPMs changed?
>>
>> Or is the package list of SLES12 not yet final?
>
> Hope, my comments help.
>
> so long -
>       MgE
>

--
Klaus Gmeinwieser
T +49 (0)8121 72 4358 F +49 (0)8121 72 3173
E klaus.gmeinwieser at oce.com W www.oce.com

Oc? Printing Systems GmbH & Co. KG ? A Canon Group Company
P.O. Box 1260 ? 85581 Poing
Siemensallee 2 ? 85586 Poing ? Germany

Oc? enables its customers to manage their documents efficiently and
effectively by offering
innovative print and document management products and services for
professional
environments.

Oc? Printing Systems GmbH & Co. KG
The company is a limited partnership with its registered office in Poing
? Trade Register HRA 100955 (Amtsgericht M?nchen) ? WEEE-Reg.-No. DE 888
05 443

General Partner: Oc? Printing Systems Gesch?ftsf?hrungsgesellschaft mbH
Registered Office: Poing ? Trade Register HRB 206480 (Amtsgericht M?nchen)
Executive Officer: Andr? Mittelsteiner, Hans Manzer
This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation.

From tee at sgi.com  Mon May 12 08:28:34 2014
From: tee at sgi.com (Tony Ernst)
Date: Mon, 12 May 2014 09:28:34 -0500
Subject: [sles-beta] Missing Software packages on SLES12 but available
 on SLES11
In-Reply-To: <20140512142053.GB1137@suse.com>
References: <5370D5AF.1090205@oce.com>
 <20140512142053.GB1137@suse.com>
Message-ID: <20140512142834.GB2822@sgi.com>

On Mon, May 12, 2014 at 04:20:53PM +0200, Matthias G. Eckermann wrote:
> Hello Klaus and all,
> 
> On 2014-05-12 T 16:07 +0200 Klaus Gmeinwieser wrote:
> 
> > while looking for packages we used with our SLES11
> > Builds I encountered that some packages being part of
> > SLES11 DVD will not be part of SLES12.
> > 
> > Missing is at least for my first check:
> > 
> > - a2ps
> 
> removed on purpose; our recommendation is enscript.
> 
> > - xrdp
> 
> This seems to be missing, but should be there
> (FATE#317086).  Please open an SR, and we'll take
> it from there.
> 
> > - ulimit
> 
> This is not necessary anymore, as "ulimit" like
> limitations should be defined via systemd.
> 
> > - jpeg

I'm not sure if this is the same issue, but it may be related:
Bug 876595 - SLES12: nothing provides libjpeg

> The shared libraries are there. Do you mean the
> commandline tools?  If yes, please open an SR, and
> we'll discuss internally.
> 
> > - mozilla-xulrunner
> 
> If I remember, the Mozilla people stopped xulrunner
> to be packaged separately, but I might be wrong.
>  
> > Is this correct that these packages/functionality
> > disappear? Has the packaging of the RPMs changed?
> > 
> > Or is the package list of SLES12 not yet final?
> 
> Hope, my comments help.
> 
> so long -
> 	MgE
> 
> -- 
> Matthias G. Eckermann     Senior Product Manager   SUSE? Linux Enterprise
> Phone: +49 30 44315731    Mobile: +49 179 2949448    E-Mail: mge at suse.com
> SUSE LINUX Products GmbH  Maxfeldstra?e 5          90409 N?rnberg Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg)
> _______________________________________________


From behlert at suse.com  Tue May 13 02:08:36 2014
From: behlert at suse.com (Stefan Behlert)
Date: Tue, 13 May 2014 10:08:36 +0200
Subject: [sles-beta] [ANNOUNCE] SLES 12 Beta6 is available
Message-ID: <20140513080836.GD27188@suse.de>

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!  SUSE CONFIDENTIAL  !!  SUSE CONFIDENTIAL  !!  SUSE CONFIDENTIAL  !!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


Dear Beta participants,

we are happy to announce the sixth Beta of

	SUSE Linux Enterprise Server 12.

ISO images are now available for download now. Please go to
http://www.novell.com/beta and select "View my beta page".
Here you should see all Beta's you are part of.

Note that the directory contains the images for the SDK as well as for the SLED
Extension.

We offer 3 DVD ISOs: DVD1 contains the binaries, the second
DVD the sources and the third DVD the debuginfo packages. 
The final product will not contain the debuginfo packages on the media.

For installation purposes you just need Media 1 for your architecture.

Please verify the md5sum of the ISO using the MD5SUMS file, which can
be found in the same directory on the download servers.


Known issues (selection):

 (several)  - upgrading from SLE 11 SP3 is not working flawlessly, requiring
	       manual interaction;
 (several)  - not all texts are translated yet
 bnc#865339 - Secure Boot not working on some systems (HP z220 for sure)
 bnc#869127 - keyboard focus lost in gdm
	      (keyboard focus lost in gdm, workaround is to press
	      "Ctrl-Alt-Tab" until you have focus again)
 bnc#870625 - No addon dialog without registration 


Installation on s390x:
	Please disable the blacklisting of devices during the installation
	(cio_ignore). This code still has a bug and other devices beside the
	IPL device and the console are not enabled.



With this Beta6 snapshot we have reached several milestones:
    o Milestone: Legal review of SLE12 contents completed.
    o Continue update, performance and regression tests.
    o Start first stress and certification tests.

For the next Beta-Release we are targeting these actions and milestones:
    o Continue update, performance and regression tests.
    o Continue intense stress and certification tests.



Thanks in advance for all your testing

	Your SUSE Linux Enterprise Team

-- 
Stefan Behlert, SUSE LINUX
Project Manager Enterprise Server
 
Maxfeldstr. 5, D-90409 Nuernberg, Germany
Phone +49-911-74053-173
SUSE LINUX Products GmbH, Nuernberg; GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer, HRB 16746 (AG Nuernberg)

From fcrozat at suse.com  Tue May 13 02:13:31 2014
From: fcrozat at suse.com (Frederic Crozat)
Date: Tue, 13 May 2014 10:13:31 +0200
Subject: [sles-beta] [ANNOUNCE] SLED Extension 12 Beta6 is available
Message-ID: <1399968811.27316.10.camel@par-r81vxc7.par.novell.com>

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!  SUSE CONFIDENTIAL  !!  SUSE CONFIDENTIAL  !!  SUSE CONFIDENTIAL  !!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Dear Beta participants,

we are happy to announce beta 6 release to beta testers (but fourth
Beta) of

         SUSE Linux Enterprise Desktop Extension 12.

ISO images are now available for download now. Please go to
http://www.novell.com/beta and select "View my beta page".
Here you should see all Beta's you are part of.

We offer 2 DVD ISOs: DVD1 contains the binaries and sources, the second
DVD the debuginfo packages.
The final product will not contain the debuginfo packages on the media.

To use this extension (together with SLES 12 Beta6):
 - start SLES installation
 - you MUST register to SCC and then only choose "use add-ons from
media" to select the Add-on ISO image (retrieving the extension for SCC
is not enabled yet).

Highlights:
  - Many bug fixes in the entire distribution
  - switching to runlevel 3 (from runlevel5) is working again !
  - openJDK web plugin (icetea-web) was updated to 2.4.7

Known problems:
 bnc#865339 - Secure Boot not working on some systems (HP z220 for sure)
 bnc#869127 - keyboard focus lost in gdm
              (keyboard focus lost in gdm, workaround is to press
              "Ctrl-Alt-Tab" until you have focus again)
 bnc#861543 - ICAClient not installable
 bnc#870625 - No addon dialog without registration 
 upgrading from SLE 11 SP3 is not working flawlessly, requiring manual
interaction

Happy testing!

        Your SUSE Linux Enterprise Team

-- 
Frederic Crozat
Project Manager Enterprise Desktop
SUSE


From urs.frey at post.ch  Tue May 13 02:43:33 2014
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Tue, 13 May 2014 08:43:33 +0000
Subject: [sles-beta] SLES 12 Beta6 download not easy
In-Reply-To: <126f8d405e304b348a30f150f59029c3@LGNMSXB02.prod.bk.dfs>
References: <126f8d405e304b348a30f150f59029c3@LGNMSXB02.prod.bk.dfs>
Message-ID: <40637DBB36AF3941B243A286A432CA0B0EFB4CE0@HXMB12.pnet.ch>

Hi Michael
Just downloaded SLE-12-Server-DVD-x86_64-Beta6-DVD1.iso, took me 40min to complete
Md5sum is correct.

Best regards

Urs Frey????????????????????????????????????????????? 
Post CH AG
Informationstechnologie
IT Betrieb 
Webergutstrasse 12 
3030 Bern (Zollikofen) 
Telefon : ++41 (0)58 338 58 70 
FAX???? : ++41 (0)58 667 30 07 
E-Mail:?? urs.frey at post.ch

-----Urspr?ngliche Nachricht-----
Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Michael Baensch
Gesendet: Tuesday, May 13, 2014 10:41 AM
An: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] SLES 12 Beta6 download not easy

Hello,

maybe a problem with akamai, has someone an idea/workaround ?

Most time with the Server DVD1 iso, always only waiting cdn.novell.com ... but no download pop up
DVD2 works, SDK works.

Regards
 Michael

From fcrozat at suse.com  Tue May 13 02:50:06 2014
From: fcrozat at suse.com (Frederic Crozat)
Date: Tue, 13 May 2014 10:50:06 +0200
Subject: [sles-beta] SLES 12 Beta6 download not easy
In-Reply-To: <126f8d405e304b348a30f150f59029c3@LGNMSXB02.prod.bk.dfs>
References: <126f8d405e304b348a30f150f59029c3@LGNMSXB02.prod.bk.dfs>
Message-ID: <1399971006.27316.11.camel@par-r81vxc7.par.novell.com>

Le mardi 13 mai 2014 ? 08:40 +0000, Michael Baensch a ?crit :
> Hello,
> 
> maybe a problem with akamai, has someone an idea/workaround ?

Just wait some hours and retry, to give CDN more time to get the ISO.


-- 
Frederic Crozat
Project Manager Enterprise Desktop
SUSE


From meissner at suse.de  Tue May 13 04:00:17 2014
From: meissner at suse.de (Marcus Meissner)
Date: Tue, 13 May 2014 12:00:17 +0200
Subject: [sles-beta] Missing Software packages on SLES12 but
	available	on SLES11
In-Reply-To: <20140512142834.GB2822@sgi.com>
References: <5370D5AF.1090205@oce.com> <20140512142053.GB1137@suse.com>
	<20140512142834.GB2822@sgi.com>
Message-ID: <20140513100017.GA24349@suse.de>

On Mon, May 12, 2014 at 09:28:34AM -0500, Tony Ernst wrote:
> On Mon, May 12, 2014 at 04:20:53PM +0200, Matthias G. Eckermann wrote:
> > Hello Klaus and all,
> > 
> > On 2014-05-12 T 16:07 +0200 Klaus Gmeinwieser wrote:
> > 
> > > while looking for packages we used with our SLES11
> > > Builds I encountered that some packages being part of
> > > SLES11 DVD will not be part of SLES12.
> > > 
> > > Missing is at least for my first check:
> > > 
> > > - a2ps
> > 
> > removed on purpose; our recommendation is enscript.
> > 
> > > - xrdp
> > 
> > This seems to be missing, but should be there
> > (FATE#317086).  Please open an SR, and we'll take
> > it from there.
> > 
> > > - ulimit
> > 
> > This is not necessary anymore, as "ulimit" like
> > limitations should be defined via systemd.
> > 
> > > - jpeg
> 
> I'm not sure if this is the same issue, but it may be related:
> Bug 876595 - SLES12: nothing provides libjpeg

No, it is not.

 
> > The shared libraries are there. Do you mean the
> > commandline tools?  If yes, please open an SR, and
> > we'll discuss internally.
> > 
> > > - mozilla-xulrunner
> > 
> > If I remember, the Mozilla people stopped xulrunner
> > to be packaged separately, but I might be wrong.
> >  
> > > Is this correct that these packages/functionality
> > > disappear? Has the packaging of the RPMs changed?
> > > 
> > > Or is the package list of SLES12 not yet final?
> > 
> > Hope, my comments help.
> > 
> > so long -
> > 	MgE
> > 
> > -- 
> > Matthias G. Eckermann     Senior Product Manager   SUSE? Linux Enterprise
> > Phone: +49 30 44315731    Mobile: +49 179 2949448    E-Mail: mge at suse.com
> > SUSE LINUX Products GmbH  Maxfeldstra?e 5          90409 N?rnberg Germany
> > GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg)
> > _______________________________________________
> 
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta
> 

From gjn at gjn.priv.at  Tue May 13 06:05:09 2014
From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer)
Date: Tue, 13 May 2014 14:05:09 +0200
Subject: [sles-beta] YaST2 dont find a driver
Message-ID: <3723988.jTkDiuVQnb@gjn.priv.at>

Hello,

I make a new Installation Beta 6 ;), without GNOME, only X-Server installed 
now I found this ?

GTK GUI wanted but not found, falling back to QT.
libGL error: failed to load driver: swrast
libGL error: Try again with LIBGL_DEBUG=verbose for more details.
/sbin/yast2: line 429:  2892 Speicherzugriffsfehler  $ybindir/y2base $module 
"$@" "$SELECTED_GUI" $Y2_GEOMETRY $Y2UI_ARGS

Is this known or a #SR ?

-- 
mit freundlichen Gr??en / best Regards,

  G?nther J. Niederwimmer

From behlert at suse.com  Tue May 13 08:02:53 2014
From: behlert at suse.com (Stefan Behlert)
Date: Tue, 13 May 2014 16:02:53 +0200
Subject: [sles-beta] SLES12 Beta6 x86_64
In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0EFB4D01@HXMB12.pnet.ch>
References: <40637DBB36AF3941B243A286A432CA0B0EFB4D01@HXMB12.pnet.ch>
Message-ID: <20140513140253.GO27188@suse.de>

Hi,

On May 13, 14 09:05:38 +0000, urs.frey at post.ch wrote:
> Hi
> When installing SLES12 Beta6 x86_64 manually I have to wait for up to
> 4minutes on the install screen with the Message "Initializing software
> manager"
> Any ideas?
> (waiting is not so funny. Linux servers are there to serve me, not to make me wait for ;-)

This is strange, I'm not seeing this here, will try different setups now.
Was it a physical of virtual installation?
And how much memory had the machine?

        Stefan
        
> 
> Best regards
> 
> Urs Frey
> Post CH AG
> Informationstechnologie
> IT Betrieb
> Webergutstrasse 12
> 3030 Bern (Zollikofen)
> Telefon : ++41 (0)58 338 58 70
> FAX     : ++41 (0)58 667 30 07
> E-Mail:   urs.frey at post.ch<mailto:urs.frey at post.ch>
> 
> 
> 

> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta


-- 
Stefan Behlert, SUSE LINUX
Project Manager Enterprise Server
 
Maxfeldstr. 5, D-90409 Nuernberg, Germany
Phone +49-911-74053-173
SUSE LINUX Products GmbH, Nuernberg; GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer, HRB 16746 (AG Nuernberg)

From urs.frey at post.ch  Tue May 13 08:12:55 2014
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Tue, 13 May 2014 14:12:55 +0000
Subject: [sles-beta] SLES12 Beta6 x86_64
In-Reply-To: <20140513140253.GO27188@suse.de>
References: <40637DBB36AF3941B243A286A432CA0B0EFB4D01@HXMB12.pnet.ch>
	<20140513140253.GO27188@suse.de>
Message-ID: <40637DBB36AF3941B243A286A432CA0B0EFB4EC2@HXMB12.pnet.ch>

Hi Stefan

I can observe the same behavior on a HP Proliant DL380-G7 2 Intel Intel(R) Xeon(R) CPU X5660 @ 2.80GHz Procs, 48GB RAM, attached to SAN EMC where I do a network installation ISO attached to ILO-3 and installation server via http using autoyast.
Kernel Boot options:
netwait=40
net.ifnames=0
splash=verbose
install=http://172.27.40.68/sles12_64
netdevice=eth0
hostname=h063uz
hostip=10.226.154.19
netmask=255.255.254.0
gateway=10.226.155.254
nameserver=10.1.121.11
autoyast=http://172.27.40.68/pstkits/profiles/sles12_autoinst_h063uz.xml
netsetup=-dhcp,+hostip,+gateway,+netmask,+nameserver
udev.rule= "mac=78:e7:d1:e7:eb:c0,name=eth0"

and also on a very small VMware ESXi VM 1 CPU 2GB RAM doing manual installation using Btrfs.
On this manual installation I am using only the SLE-12-Server-DVD-x86_64-Beta6-DVD1.iso mounted remotely via v-sphere DVD-ROM device.

The issue is, that this behavior was not there with SLES12 Beta4.
It began with Beta5 and now with Beta6 it seems to be worse.

With SLES11-SP3 on the same servers there is absolutely no delay, no waiting on initialization of the software manager.

Best regards

Urs Frey????????????????????????????????????????????? 
Post CH AG
Informationstechnologie
IT Betrieb 
Webergutstrasse 12 
3030 Bern (Zollikofen) 
Telefon : ++41 (0)58 338 58 70 
FAX???? : ++41 (0)58 667 30 07 
E-Mail:?? urs.frey at post.ch


-----Urspr?ngliche Nachricht-----
Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Stefan Behlert
Gesendet: Tuesday, May 13, 2014 4:03 PM
An: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] SLES12 Beta6 x86_64

Hi,

On May 13, 14 09:05:38 +0000, urs.frey at post.ch wrote:
> Hi
> When installing SLES12 Beta6 x86_64 manually I have to wait for up to
> 4minutes on the install screen with the Message "Initializing software
> manager"
> Any ideas?
> (waiting is not so funny. Linux servers are there to serve me, not to make me wait for ;-)

This is strange, I'm not seeing this here, will try different setups now.
Was it a physical of virtual installation?
And how much memory had the machine?

        Stefan
        
> 
> Best regards
> 
> Urs Frey
> Post CH AG
> Informationstechnologie
> IT Betrieb
> Webergutstrasse 12
> 3030 Bern (Zollikofen)
> Telefon : ++41 (0)58 338 58 70
> FAX     : ++41 (0)58 667 30 07
> E-Mail:   urs.frey at post.ch<mailto:urs.frey at post.ch>
> 
> 
> 

> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta


-- 
Stefan Behlert, SUSE LINUX
Project Manager Enterprise Server
 
Maxfeldstr. 5, D-90409 Nuernberg, Germany
Phone +49-911-74053-173
SUSE LINUX Products GmbH, Nuernberg; GF: 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

From miguel.e.rivera at lmco.com  Tue May 13 08:21:14 2014
From: miguel.e.rivera at lmco.com (Rivera, Miguel E)
Date: Tue, 13 May 2014 14:21:14 +0000
Subject: [sles-beta] SLES12 Beta6 x86_64
In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0EFB4EC2@HXMB12.pnet.ch>
References: <40637DBB36AF3941B243A286A432CA0B0EFB4D01@HXMB12.pnet.ch>
	<20140513140253.GO27188@suse.de>
	<40637DBB36AF3941B243A286A432CA0B0EFB4EC2@HXMB12.pnet.ch>
Message-ID: <A8ED4661493E8E4BBB1ACCE95DB402A7171B02B9@HDXDSP54.us.lmco.com>

I have seen this on all of our servers in the range from HP380's, 580's and 980's.

When I load a smaller system like a desk side Z600 or laptop I do not see the lengthy wait time to load.  I believe it is either a memory or cpu count issue on the bigger systems.

Mike Rivera
Texas

-----Original Message-----
From: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] On Behalf Of urs.frey at post.ch
Sent: Tuesday, May 13, 2014 9:13 AM
To: behlert at suse.com
Cc: sles-beta at lists.suse.com
Subject: EXTERNAL: Re: [sles-beta] SLES12 Beta6 x86_64

Hi Stefan

I can observe the same behavior on a HP Proliant DL380-G7 2 Intel Intel(R) Xeon(R) CPU X5660 @ 2.80GHz Procs, 48GB RAM, attached to SAN EMC where I do a network installation ISO attached to ILO-3 and installation server via http using autoyast.
Kernel Boot options:
netwait=40
net.ifnames=0
splash=verbose
install=http://172.27.40.68/sles12_64
netdevice=eth0
hostname=h063uz
hostip=10.226.154.19
netmask=255.255.254.0
gateway=10.226.155.254
nameserver=10.1.121.11
autoyast=http://172.27.40.68/pstkits/profiles/sles12_autoinst_h063uz.xml
netsetup=-dhcp,+hostip,+gateway,+netmask,+nameserver
udev.rule= "mac=78:e7:d1:e7:eb:c0,name=eth0"

and also on a very small VMware ESXi VM 1 CPU 2GB RAM doing manual installation using Btrfs.
On this manual installation I am using only the SLE-12-Server-DVD-x86_64-Beta6-DVD1.iso mounted remotely via v-sphere DVD-ROM device.

The issue is, that this behavior was not there with SLES12 Beta4.
It began with Beta5 and now with Beta6 it seems to be worse.

With SLES11-SP3 on the same servers there is absolutely no delay, no waiting on initialization of the software manager.

Best regards

Urs Frey Post CH AG Informationstechnologie IT Betrieb Webergutstrasse 12
3030 Bern (Zollikofen)
Telefon : ++41 (0)58 338 58 70
FAX???? : ++41 (0)58 667 30 07
E-Mail:?? urs.frey at post.ch


-----Urspr?ngliche Nachricht-----
Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Stefan Behlert
Gesendet: Tuesday, May 13, 2014 4:03 PM
An: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] SLES12 Beta6 x86_64

Hi,

On May 13, 14 09:05:38 +0000, urs.frey at post.ch wrote:
> Hi
> When installing SLES12 Beta6 x86_64 manually I have to wait for up to 
> 4minutes on the install screen with the Message "Initializing software 
> manager"
> Any ideas?
> (waiting is not so funny. Linux servers are there to serve me, not to 
> make me wait for ;-)

This is strange, I'm not seeing this here, will try different setups now.
Was it a physical of virtual installation?
And how much memory had the machine?

        Stefan
        
> 
> Best regards
> 
> Urs Frey
> Post CH AG
> Informationstechnologie
> IT Betrieb
> Webergutstrasse 12
> 3030 Bern (Zollikofen)
> Telefon : ++41 (0)58 338 58 70
> FAX     : ++41 (0)58 667 30 07
> E-Mail:   urs.frey at post.ch<mailto:urs.frey at post.ch>
> 
> 
> 

> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta


--
Stefan Behlert, SUSE LINUX
Project Manager Enterprise Server
 
Maxfeldstr. 5, D-90409 Nuernberg, Germany Phone +49-911-74053-173 SUSE LINUX Products GmbH, Nuernberg; GF: 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

From gjn at gjn.priv.at  Tue May 13 09:43:57 2014
From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer)
Date: Tue, 13 May 2014 17:43:57 +0200
Subject: [sles-beta] Network Problems
Message-ID: <1843761.B4mTVGp333@gjn.priv.at>

Hello,

have any tested wicked with openvswitch, on my system the network crash

A other Problem is to connect over ssh with SLES 12 I have to wait. ...... 
wait, also a ping is extreme slow for a answer.
-- 
mit freundlichen Gr??en / best Regards,

  G?nther J. Niederwimmer

From darrent at akurit.com.au  Tue May 13 16:39:07 2014
From: darrent at akurit.com.au (Darren Thompson)
Date: Wed, 14 May 2014 08:39:07 +1000
Subject: [sles-beta] Typo in VMDP
Message-ID: <CAEUhfEcgsyRQZ4yiP2v2JDdRykWqyKZzmoLfXRvD1vSVMtvY2g@mail.gmail.com>

Team

There is a typo in the file name of one of the "Virtual machine driver
pack" files.
The file 'vmdp-140227_virtio.is' should end in '.iso'

The correct name should have been 'vmdp-140227_virtio.iso'

Regards

Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.suse.com/mailman/private/sles-beta/attachments/20140514/69b2fbaf/attachment.htm>

From mmarion at qualcomm.com  Tue May 13 16:40:57 2014
From: mmarion at qualcomm.com (Mike Marion)
Date: Tue, 13 May 2014 15:40:57 -0700
Subject: [sles-beta] SLES12 Beta6 x86_64
In-Reply-To: <A8ED4661493E8E4BBB1ACCE95DB402A7171B02B9@HDXDSP54.us.lmco.com>
References: <40637DBB36AF3941B243A286A432CA0B0EFB4D01@HXMB12.pnet.ch>
	<20140513140253.GO27188@suse.de>
	<40637DBB36AF3941B243A286A432CA0B0EFB4EC2@HXMB12.pnet.ch>
	<A8ED4661493E8E4BBB1ACCE95DB402A7171B02B9@HDXDSP54.us.lmco.com>
Message-ID: <20140513224057.GJ21153@qualcomm.com>

On Tue, May 13, 2014 at 02:21:14PM +0000, Rivera, Miguel E wrote:

> I have seen this on all of our servers in the range from HP380's, 580's and 980's.
> 
> When I load a smaller system like a desk side Z600 or laptop I do not see 
> the lengthy wait time to load.  I believe it is either a memory or cpu count 
> issue on the bigger systems.

Considering how long many of the HPs take to POST these days (and every
Gen seems to get worse)... I'd say this sounds logical.

-- 
Mike Marion-Unix SysAdmin/Sr. Staff IT Engineer-http://www.qualcomm.com
Jo-anna: "Bing? That's a great name."
Chandler: "Thanks, it's Gaelic for 'Thy turkey's done.'"
--Friends

From mpost at suse.com  Tue May 13 16:48:04 2014
From: mpost at suse.com (Mark Post)
Date: Tue, 13 May 2014 16:48:04 -0600
Subject: [sles-beta] Network Problems
In-Reply-To: <1843761.B4mTVGp333@gjn.priv.at>
References: <1843761.B4mTVGp333@gjn.priv.at>
Message-ID: <537268E40200006D00160A2E@prv-mh.provo.novell.com>

>>> On 5/13/2014 at 11:43 AM, G?nther J.Niederwimmer <gjn at gjn.priv.at> wrote: 
> A other Problem is to connect over ssh with SLES 12 I have to wait. ...... 

That sounds like the typical symptom of a reverse DNS lookup timing out.  How long do you have to wait?


Mark Post

From Dick.Waite at softwareag.com  Tue May 13 23:33:51 2014
From: Dick.Waite at softwareag.com (Waite, Dick)
Date: Wed, 14 May 2014 05:33:51 +0000
Subject: [sles-beta] YaST2 dont find a driver - Upgrade to SLE 12 -
 Gnome from SLE 11-3 with KDE
Message-ID: <46AC8C81C10B8C48820201DF2AE1D76D537B63F1@hqmbx6.eur.ad.sag>

Grand New Day,

May I add a few words to G?nther email. I have " a lot " of QE and user machines running SLE 11-2 and 11-3, they all run KDE. I have found Beta6 is making the upgrade better, but when you get into the upgraded machine it's sitting on a command prompt, and our users / customers would be expecting a Display Manager (GNOME)

I think it would be very helpful if SUSE give us *DETAILED* information on how they would like their thousands of happy KDE users running SLE 11 to update / upgrade to SLE 12 running Gnome.

What to do before starting the upgrade, the steps needed one by one and then what to do after the upgrade.

I have found removing the Network hardware and software before attempting the upgrade give one a better chance of success, but as I have had many years of happily running SuSE and SUSE on KDE and never used the good Gnome in the past I'd like a little help in getting the steps *right*. Then maybe we can start checking their own application.

Many Thanks,

__R
________________________________________
From: sles-beta-bounces at lists.suse.com [sles-beta-bounces at lists.suse.com] on behalf of G?nther J. Niederwimmer [gjn at gjn.priv.at]
Sent: 13 May 2014 14:05
To: sles-beta at lists.suse.com
Subject: [sles-beta] YaST2 dont find a driver

Hello,

I make a new Installation Beta 6 ;), without GNOME, only X-Server installed
now I found this ?

GTK GUI wanted but not found, falling back to QT.
libGL error: failed to load driver: swrast
libGL error: Try again with LIBGL_DEBUG=verbose for more details.
/sbin/yast2: line 429:  2892 Speicherzugriffsfehler  $ybindir/y2base $module
"$@" "$SELECTED_GUI" $Y2_GEOMETRY $Y2UI_ARGS

Is this known or a #SR ?

--
mit freundlichen Gr??en / best Regards,

  G?nther J. Niederwimmer
_______________________________________________
sles-beta mailing list
sles-beta at lists.suse.com
http://lists.suse.com/mailman/listinfo/sles-beta

Software AG ? Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany ? Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com


From gjn at gjn.priv.at  Wed May 14 00:39:10 2014
From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer)
Date: Wed, 14 May 2014 08:39:10 +0200
Subject: [sles-beta] Network Problems
In-Reply-To: <537268E40200006D00160A2E@prv-mh.provo.novell.com>
References: <1843761.B4mTVGp333@gjn.priv.at>
	<537268E40200006D00160A2E@prv-mh.provo.novell.com>
Message-ID: <2497664.j8H055dDZO@gjn.priv.at>

Thank's Mark for the answer,

Am Dienstag, 13. Mai 2014, 16:48:04 schrieb Mark Post:
> >>> On 5/13/2014 at 11:43 AM, G?nther J.Niederwimmer <gjn at gjn.priv.at> 
wrote:
> > A other Problem is to connect over ssh with SLES 12 I have to wait. ......
> 
> That sounds like the typical symptom of a reverse DNS lookup timing out. 
> How long do you have to wait?

but the reverse DNS is OK, and I change also the NIC (?).

5-15 sec for a answer and the same time for password afterward I mean it is 
ok.

> Mark Post
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta

-- 
mit freundlichen Gr??en / best Regards,

  G?nther J. Niederwimmer

From aginies at suse.com  Wed May 14 00:44:13 2014
From: aginies at suse.com (Antoine Ginies)
Date: Wed, 14 May 2014 08:44:13 +0200
Subject: [sles-beta] Typo in VMDP
In-Reply-To: <CAEUhfEcgsyRQZ4yiP2v2JDdRykWqyKZzmoLfXRvD1vSVMtvY2g@mail.gmail.com>
References: <CAEUhfEcgsyRQZ4yiP2v2JDdRykWqyKZzmoLfXRvD1vSVMtvY2g@mail.gmail.com>
Message-ID: <20140514064413.GA2942@linux-w520.guibland.com>

Darren Thompson:
> Team
> There is a typo in the file name of one of the "Virtual machine driver
> pack" files.
> The file 'vmdp-140227_virtio.is' should end in '.iso'

yes, it has been discovered yesterday and will be fixed.
A new version of VMDP will be available soon on this repository.
Thanks for reporting.

regards
Antoine


-- 
Antoine Ginies <aginies at suse.com>
Project Manager
SUSE France

From fcrozat at suse.com  Wed May 14 00:51:15 2014
From: fcrozat at suse.com (Frederic Crozat)
Date: Wed, 14 May 2014 08:51:15 +0200
Subject: [sles-beta] YaST2 dont find a driver - Upgrade to SLE 12 -
 Gnome from SLE 11-3 with KDE
In-Reply-To: <46AC8C81C10B8C48820201DF2AE1D76D537B63F1@hqmbx6.eur.ad.sag>
References: <46AC8C81C10B8C48820201DF2AE1D76D537B63F1@hqmbx6.eur.ad.sag>
Message-ID: <1400050275.2346.7.camel@par-r81vxc7.par.novell.com>

Le mercredi 14 mai 2014 ? 05:33 +0000, Waite, Dick a ?crit :
> Grand New Day,
> 
> May I add a few words to G?nther email. I have " a lot " of QE and user machines running SLE 11-2 and 11-3, they all run KDE. I have found Beta6 is making the upgrade better, but when you get into the upgraded machine it's sitting on a command prompt, and our users / customers would be expecting a Display Manager (GNOME)
> 
> I think it would be very helpful if SUSE give us *DETAILED* information on how they would like their thousands of happy KDE users running SLE 11 to update / upgrade to SLE 12 running Gnome.
> 
> What to do before starting the upgrade, the steps needed one by one and then what to do after the upgrade.
> 
> I have found removing the Network hardware and software before attempting the upgrade give one a better chance of success, but as I have had many years of happily running SuSE and SUSE on KDE and never used the good Gnome in the past I'd like a little help in getting the steps *right*. Then maybe we can start checking their own application.

As mentioned in the announcement for Beta6, we are still busy fixing
bugs in the upgrade path, including from KDE desktop (SLE11) to SLE12.
The expected upgrade path should not include manual steps but it is not
here yet.


-- 
Frederic Crozat
Project Manager Enterprise Desktop
SUSE


From Dick.Waite at softwareag.com  Wed May 14 01:23:29 2014
From: Dick.Waite at softwareag.com (Waite, Dick)
Date: Wed, 14 May 2014 07:23:29 +0000
Subject: [sles-beta] YaST2 dont find a driver - Upgrade to SLE 12 -
 Gnome from SLE 11-3 with KDE
In-Reply-To: <1400050275.2346.7.camel@par-r81vxc7.par.novell.com>
References: <46AC8C81C10B8C48820201DF2AE1D76D537B63F1@hqmbx6.eur.ad.sag>,
	<1400050275.2346.7.camel@par-r81vxc7.par.novell.com>
Message-ID: <46AC8C81C10B8C48820201DF2AE1D76D537B64E1@hqmbx6.eur.ad.sag>

Many Thanks for the Quick Update,

upgrading from SLE 11 SP3 is not working flawlessly, requiring manual
interaction

I did read the good words, what would be grand are some words so that the "manual interaction" is done how SUSE would like it done. If we are given the 1 to n steps to run the manual interaction, then we all get it right and we can then run our applications checks against SUSE 12-0-beta6 and the results will be helpful to you and are-selves. If we do the manual steps as each of us think it should be done then I'm not sure the issues we find with Beta6 will be so meaningful. Some will get it right and some (me) might not.

Wishing you all a grand day.

__R
________________________________________
From: sles-beta-bounces at lists.suse.com [sles-beta-bounces at lists.suse.com] on behalf of Frederic Crozat [fcrozat at suse.com]
Sent: 14 May 2014 08:51
To: sles-beta at lists.suse.com
Subject: Re: [sles-beta] YaST2 dont find a driver - Upgrade to SLE 12 - Gnome from SLE 11-3 with KDE

Le mercredi 14 mai 2014 ? 05:33 +0000, Waite, Dick a ?crit :
> Grand New Day,
>
> May I add a few words to G?nther email. I have " a lot " of QE and user machines running SLE 11-2 and 11-3, they all run KDE. I have found Beta6 is making the upgrade better, but when you get into the upgraded machine it's sitting on a command prompt, and our users / customers would be expecting a Display Manager (GNOME)
>
> I think it would be very helpful if SUSE give us *DETAILED* information on how they would like their thousands of happy KDE users running SLE 11 to update / upgrade to SLE 12 running Gnome.
>
> What to do before starting the upgrade, the steps needed one by one and then what to do after the upgrade.
>
> I have found removing the Network hardware and software before attempting the upgrade give one a better chance of success, but as I have had many years of happily running SuSE and SUSE on KDE and never used the good Gnome in the past I'd like a little help in getting the steps *right*. Then maybe we can start checking their own application.

As mentioned in the announcement for Beta6, we are still busy fixing
bugs in the upgrade path, including from KDE desktop (SLE11) to SLE12.
The expected upgrade path should not include manual steps but it is not
here yet.


--
Frederic Crozat
Project Manager Enterprise Desktop
SUSE

_______________________________________________
sles-beta mailing list
sles-beta at lists.suse.com
http://lists.suse.com/mailman/listinfo/sles-beta

Software AG ? Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany ? Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com


From fcrozat at suse.com  Wed May 14 01:28:14 2014
From: fcrozat at suse.com (Frederic Crozat)
Date: Wed, 14 May 2014 09:28:14 +0200
Subject: [sles-beta] YaST2 dont find a driver - Upgrade to SLE 12 -
 Gnome from SLE 11-3 with KDE
In-Reply-To: <46AC8C81C10B8C48820201DF2AE1D76D537B64E1@hqmbx6.eur.ad.sag>
References: <46AC8C81C10B8C48820201DF2AE1D76D537B63F1@hqmbx6.eur.ad.sag>
	,<1400050275.2346.7.camel@par-r81vxc7.par.novell.com>
	<46AC8C81C10B8C48820201DF2AE1D76D537B64E1@hqmbx6.eur.ad.sag>
Message-ID: <1400052494.2346.9.camel@par-r81vxc7.par.novell.com>

Le mercredi 14 mai 2014 ? 07:23 +0000, Waite, Dick a ?crit :
> Many Thanks for the Quick Update,
> 
> upgrading from SLE 11 SP3 is not working flawlessly, requiring manual
> interaction
> 
> I did read the good words, what would be grand are some words so that the "manual interaction" is done how SUSE would like it done. If we are given the 1 to n steps to run the manual interaction, then we all get it right and we can then run our applications checks against SUSE 12-0-beta6 and the results will be helpful to you and are-selves. If we do the manual steps as each of us think it should be done then I'm not sure the issues we find with Beta6 will be so meaningful. Some will get it right and some (me) might not.

Could you please fill a service request ?

This will help us to track your particular upgrade issue.

Thanks.


-- 
Frederic Crozat
Project Manager Enterprise Desktop
SUSE


From mge at suse.com  Wed May 14 01:36:43 2014
From: mge at suse.com (Matthias G. Eckermann)
Date: Wed, 14 May 2014 09:36:43 +0200
Subject: [sles-beta] YaST2 dont find a driver
In-Reply-To: <3723988.jTkDiuVQnb@gjn.priv.at>
References: <3723988.jTkDiuVQnb@gjn.priv.at>
Message-ID: <20140514073643.GA8133@suse.com>

Hello G?nther and all,

I ran into the same: it's at least one bug, probably
multiple bugs even.  Please open an SR.

TIA -
	MgE

On 2014-05-13 T 14:05 +0200 G?nther J. Niederwimmer wrote:
> 
> I make a new Installation Beta 6 ;), without GNOME, only X-Server installed 
> now I found this ?
> 
> GTK GUI wanted but not found, falling back to QT.
> libGL error: failed to load driver: swrast
> libGL error: Try again with LIBGL_DEBUG=verbose for more details.
> /sbin/yast2: line 429:  2892 Speicherzugriffsfehler  $ybindir/y2base $module 
> "$@" "$SELECTED_GUI" $Y2_GEOMETRY $Y2UI_ARGS
> 
> Is this known or a #SR ?

-- 
Matthias G. Eckermann     Senior Product Manager   SUSE? Linux Enterprise
Phone: +49 30 44315731    Mobile: +49 179 2949448    E-Mail: mge at suse.com
SUSE LINUX Products GmbH  Maxfeldstra?e 5          90409 N?rnberg Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg)

From Dick.Waite at softwareag.com  Wed May 14 01:37:55 2014
From: Dick.Waite at softwareag.com (Waite, Dick)
Date: Wed, 14 May 2014 07:37:55 +0000
Subject: [sles-beta] YaST2 dont find a driver - Upgrade to SLE 12 -
 Gnome from SLE 11-3 with KDE
In-Reply-To: <1400052494.2346.9.camel@par-r81vxc7.par.novell.com>
References: <46AC8C81C10B8C48820201DF2AE1D76D537B63F1@hqmbx6.eur.ad.sag>
	,<1400050275.2346.7.camel@par-r81vxc7.par.novell.com>
	<46AC8C81C10B8C48820201DF2AE1D76D537B64E1@hqmbx6.eur.ad.sag>,
	<1400052494.2346.9.camel@par-r81vxc7.par.novell.com>
Message-ID: <20140514073755.5824657.51322.2958@softwareag.com>

SR# 10884981671 been running for some time.
On the road today back Thursday PM


Sent from my BlackBerry 10 smartphone.
  Original Message
From: Frederic Crozat
Sent: Wednesday, 14 May 2014 09:28
To: sles-beta at lists.suse.com
Subject: Re: [sles-beta] YaST2 dont find a driver - Upgrade to SLE 12 - Gnome from SLE 11-3 with KDE


Le mercredi 14 mai 2014 ? 07:23 +0000, Waite, Dick a ?crit :
> Many Thanks for the Quick Update,
>
> upgrading from SLE 11 SP3 is not working flawlessly, requiring manual
> interaction
>
> I did read the good words, what would be grand are some words so that the "manual interaction" is done how SUSE would like it done. If we are given the 1 to n steps to run the manual interaction, then we all get it right and we can then run our applications checks against SUSE 12-0-beta6 and the results will be helpful to you and are-selves. If we do the manual steps as each of us think it should be done then I'm not sure the issues we find with Beta6 will be so meaningful. Some will get it right and some (me) might not.

Could you please fill a service request ?

This will help us to track your particular upgrade issue.

Thanks.


--
Frederic Crozat
Project Manager Enterprise Desktop
SUSE

_______________________________________________
sles-beta mailing list
sles-beta at lists.suse.com
http://lists.suse.com/mailman/listinfo/sles-beta

Software AG ? Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany ? Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com


From Klaus.Gmeinwieser at oce.com  Wed May 14 02:38:19 2014
From: Klaus.Gmeinwieser at oce.com (Klaus Gmeinwieser)
Date: Wed, 14 May 2014 10:38:19 +0200
Subject: [sles-beta] New and additional home for root??
Message-ID: <53732B7B.6090204@oce.com>

Hi all,

after installing Beta6 I accidentally found out, that now on a standard
installation I get two "home" directiries for user root.

The original "/root" which is populated with files and also a new
"/home/root" with all of the files from /etc/skel directory.

I activated "ROOT_USES_LANG" and also I preset the password within my
autoinst.xml file...

Is this a new "feature" I missed?

Please advise

Rgds
Klaus

--
Klaus Gmeinwieser
T +49 (0)8121 72 4358 F +49 (0)8121 72 3173
E klaus.gmeinwieser at oce.com W www.oce.com

Oc? Printing Systems GmbH & Co. KG ? A Canon Group Company
P.O. Box 1260 ? 85581 Poing
Siemensallee 2 ? 85586 Poing ? Germany

Oc? enables its customers to manage their documents efficiently and
effectively by offering
innovative print and document management products and services for
professional
environments.

Oc? Printing Systems GmbH & Co. KG
The company is a limited partnership with its registered office in Poing
? Trade Register HRA 100955 (Amtsgericht M?nchen) ? WEEE-Reg.-No. DE 888
05 443

General Partner: Oc? Printing Systems Gesch?ftsf?hrungsgesellschaft mbH
Registered Office: Poing ? Trade Register HRB 206480 (Amtsgericht M?nchen)
Executive Officer: Andr? Mittelsteiner
This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation.

From rbrown at suse.de  Wed May 14 02:43:04 2014
From: rbrown at suse.de (Richard Brown)
Date: Wed, 14 May 2014 10:43:04 +0200
Subject: [sles-beta] New and additional home for root??
In-Reply-To: <53732B7B.6090204@oce.com>
References: <53732B7B.6090204@oce.com>
Message-ID: <1400056984.6922.11.camel@ibrokeit.suse.de>

On Wed, 2014-05-14 at 10:38 +0200, Klaus Gmeinwieser wrote:
> The original "/root" which is populated with files and also a new
> "/home/root" with all of the files from /etc/skel directory.
> 
> I activated "ROOT_USES_LANG" and also I preset the password within my
> autoinst.xml file...
> 
> Is this a new "feature" I missed?

On my Beta 6 machines, I only have /root and not /home/root - I do not
think what you're seeing is intentional.

This includes 2 machines which were installed using AutoYaST, however
neither used ROOT_USES_LANG so that would be where I suspect this might
have been triggered

Hope this helps,
Richard
-- 
-------------------------------------------------------------------
  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)
-------------------------------------------------------------------



From michael.baensch at dfs.de  Wed May 14 07:20:28 2014
From: michael.baensch at dfs.de (Michael Baensch)
Date: Wed, 14 May 2014 13:20:28 +0000
Subject: [sles-beta] mei module or not ?
Message-ID: <c2ba3f59f449417cb55868e5bb024519@LGNMSXB02.prod.bk.dfs>

Hello,

does someone know if the mei module (iAMT) is missing or is it removed ? 
SLES 11 has it.

Thanks
 Michael




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>

From tee at sgi.com  Wed May 14 09:35:39 2014
From: tee at sgi.com (Tony Ernst)
Date: Wed, 14 May 2014 10:35:39 -0500
Subject: [sles-beta] php disappeared in beta6?
Message-ID: <20140514153539.GC11257@sgi.com>

Sles12 beta5 had php (php5) rpms. They seem to have disappeared in beta6.
Was that intentional? Oddly enough, the php5-devel and the pcp .src rpm 
are still in the beta6 SDK.

Regards,
Tony

-- 
Tony Ernst
Linux System Software
SGI
tee at sgi.com


From allen at ua.edu  Wed May 14 09:55:44 2014
From: allen at ua.edu (Beddingfield, Allen)
Date: Wed, 14 May 2014 15:55:44 +0000
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <20140514153539.GC11257@sgi.com>
References: <20140514153539.GC11257@sgi.com>
Message-ID: <AAD7066EC17A5541BF5145CD44BEFA72E68EAB70@EX10MBN01.ua-net.ua.edu>

I can confirm this as an issue, too.  We definitely require that PHP be included, since we are hosting our web infrastructure on SLES.

Allen B.
--
Allen Beddingfield
Systems Engineer
The University of Alabama

________________________________________
From: sles-beta-bounces at lists.suse.com [sles-beta-bounces at lists.suse.com] on behalf of Tony Ernst [tee at sgi.com]
Sent: Wednesday, May 14, 2014 10:35 AM
To: sles-beta at lists.suse.com
Subject: [sles-beta] php disappeared in beta6?

Sles12 beta5 had php (php5) rpms. They seem to have disappeared in beta6.
Was that intentional? Oddly enough, the php5-devel and the pcp .src rpm
are still in the beta6 SDK.

Regards,
Tony

--
Tony Ernst
Linux System Software
SGI
tee at sgi.com

_______________________________________________
sles-beta mailing list
sles-beta at lists.suse.com
http://lists.suse.com/mailman/listinfo/sles-beta

From gregg at ricis.com  Wed May 14 10:23:36 2014
From: gregg at ricis.com (Gregory D. Rosenberg)
Date: Wed, 14 May 2014 11:23:36 -0500
Subject: [sles-beta] New and additional home for root??
In-Reply-To: <1400056984.6922.11.camel@ibrokeit.suse.de>
References: <53732B7B.6090204@oce.com>
	<1400056984.6922.11.camel@ibrokeit.suse.de>
Message-ID: <3A2B5C20-B505-427A-99D2-C063CBF40A4A@ricis.com>

Klaus,

Maybe it would make sense to have a soft link from /root and /home/root. This would be beneficial for new users starting out that struggle with the notion that /root is not under /home/root. Of course we all know why and that is to securely isolate it. This probably would not work well when /home was mounted on a different machine or a cluster of machines. So maybe it is a bad suggestion.


On May 14, 2014, at 03:43 CDT, Richard Brown <rbrown at suse.de> wrote:

> On Wed, 2014-05-14 at 10:38 +0200, Klaus Gmeinwieser wrote:
>> The original "/root" which is populated with files and also a new
>> "/home/root" with all of the files from /etc/skel directory.
>> 
>> I activated "ROOT_USES_LANG" and also I preset the password within my
>> autoinst.xml file...
>> 
>> Is this a new "feature" I missed?
> 
> On my Beta 6 machines, I only have /root and not /home/root - I do not
> think what you're seeing is intentional.
> 
> This includes 2 machines which were installed using AutoYaST, however
> neither used ROOT_USES_LANG so that would be where I suspect this might
> have been triggered
> 
> Hope this helps,
> Richard
> -- 
> -------------------------------------------------------------------
>  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://cp.mcafee.com/d/avndzgQ821J5yZXLzHEICXCQrFKc8Lf3DzqdQT64jhOyMOrhKMqekPhOYqem3hOrhKCU-qekS6nPp6fAi8azaQGsKrzaQGsKro8mjp7cLZvC7CjhOe7tuVt4sqerYYe7ccLYJt6OaaJXLYG7DR8OJMddECQjqfniESgFqcy7CQjo0c-l9QWztfVv1dnoovaAVgtHB3_En8vfjt3_En8vfiV2Hsbvg57OFeDkrF_bCSkQrCMnWhEwdbt3_En8vfjiWq80pVwQgr10QgqwxasGMQYQg4WG-q87qNd44qRCi96TXCROiA-syZ



P.S. Text the word BLIND to 85944 to donate $10 to the NFB Imagination Fund via your phone bill.

The National Federation of the Blind knows that blindness is not the characteristic that defines you or your future. Every day we raise the expectations of blind people, because low expectations create obstacles between blind people and our dreams. You can have the life you want; blindness is not what holds you back. 

--
73' & 75'
Gregory D. Rosenberg AB9MZ
gregg at ricis.com

RICIS, Inc.
7849 Bristol Park Drive
Tinley Park, IL 60477-4594
http://www.ricis.com

708-267-6664 Cell 
708-444-2690 Office
708-444-1115 Fax 
(Please call before sending a fax)




From mpost at suse.com  Wed May 14 12:23:48 2014
From: mpost at suse.com (Mark Post)
Date: Wed, 14 May 2014 12:23:48 -0600
Subject: [sles-beta] Network Problems
In-Reply-To: <2497664.j8H055dDZO@gjn.priv.at>
References: <1843761.B4mTVGp333@gjn.priv.at>
	<537268E40200006D00160A2E@prv-mh.provo.novell.com>
	<2497664.j8H055dDZO@gjn.priv.at>
Message-ID: <53737C740200006D00160C44@prv-mh.provo.novell.com>

>>> On 5/14/2014 at 02:39 AM, G?nther J.Niederwimmer <gjn at gjn.priv.at> wrote: 
> Am Dienstag, 13. Mai 2014, 16:48:04 schrieb Mark Post:
>
>> How long do you have to wait?
> 
> but the reverse DNS is OK, and I change also the NIC (?).
> 
> 5-15 sec for a answer and the same time for password afterward I mean it is 
> ok.

Yes, that's not long enough for a DNS timeout.  But it sounds too long to me.


Mark Post

From tee at sgi.com  Wed May 14 14:56:35 2014
From: tee at sgi.com (Tony Ernst)
Date: Wed, 14 May 2014 15:56:35 -0500
Subject: [sles-beta] Beta6 on EFI
Message-ID: <20140514205635.GK11257@sgi.com>

Is anyone else able to get the beta6 DVD to boot on a x86_64 EFI system?
It won't boot on ours.

Regards,
Tony

-- 
Tony Ernst
Linux System Software
SGI
tee at sgi.com


From nmunoz at suse.com  Wed May 14 15:07:34 2014
From: nmunoz at suse.com (Nefi Munoz)
Date: Wed, 14 May 2014 15:07:34 -0600
Subject: [sles-beta] Beta6 on EFI
In-Reply-To: <20140514205635.GK11257@sgi.com>
References: <20140514205635.GK11257@sgi.com>
Message-ID: <537386B6020000C800137F15@prv-mh.provo.novell.com>

> Is anyone else able to get the beta6 DVD to boot on a x86_64 EFI system?
> It won't boot on ours.

I was able to install Beta 6 from DVD on a couple of IBM System x servers (x86_64) with UEFI.   Also, UEFI installed another system x server from PXE.  

I know on some System x servers (e.g. ones with AMD processors) you have to enable UEFI boot by setting "Launch Storage OpROM" to "UEFI Driver" in the Setup Utility -> System Settings -> Device and I/O Ports.

- Nefi M.





From mge at suse.com  Wed May 14 15:14:28 2014
From: mge at suse.com (Matthias G. Eckermann)
Date: Wed, 14 May 2014 23:14:28 +0200
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <AAD7066EC17A5541BF5145CD44BEFA72E68EAB70@EX10MBN01.ua-net.ua.edu>
References: <20140514153539.GC11257@sgi.com>
	<AAD7066EC17A5541BF5145CD44BEFA72E68EAB70@EX10MBN01.ua-net.ua.edu>
Message-ID: <20140514211427.GA5102@suse.com>

On 2014-05-14 T 15:55 +0000 Beddingfield, Allen wrote:

> I can confirm this as an issue, too.  We
> definitely require that PHP be included, since we
> are hosting our web infrastructure on SLES.

PHP is not on the "ISO" anymore, but in a "module",
which is only delivered online. 

To get PHP, please register your system during
installation and chose the "Web & Scripting" module.

More on the "Modules" concept I will explain in one
of the next beta calls.

so long -
	MgE
 
> From: sles-beta-bounces at lists.suse.com [sles-beta-bounces at lists.suse.com] on behalf of Tony Ernst [tee at sgi.com]
> Sent: Wednesday, May 14, 2014 10:35 AM
> To: sles-beta at lists.suse.com
> Subject: [sles-beta] php disappeared in beta6?
> 
> Sles12 beta5 had php (php5) rpms. They seem to have disappeared in beta6.
> Was that intentional? Oddly enough, the php5-devel and the pcp .src rpm
> are still in the beta6 SDK.

-- 
Matthias G. Eckermann     Senior Product Manager   SUSE? Linux Enterprise
Phone: +49 30 44315731    Mobile: +49 179 2949448    E-Mail: mge at suse.com
SUSE LINUX Products GmbH  Maxfeldstra?e 5          90409 N?rnberg Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg)

From mahendral at millenniumit.com  Wed May 14 23:43:41 2014
From: mahendral at millenniumit.com (Laxman, Mahendra)
Date: Thu, 15 May 2014 05:43:41 +0000
Subject: [sles-beta] Tasks get stuck with RT priority
In-Reply-To: <5370BEF5.3070802@suse.com>
References: <7E0FF7E78901584F9F0EC5E69214670723B93DE7@LG-SPMB-MBX01.lseg.stockex.local>
	<20140506123618.GE21258@fm.suse.cz> 
	<049A43DFF32DB14DBA34752BE3659AED241ED5D6@LG-SPMB-MBX01.lseg.stockex.local>
	<1399614536.5200.35.camel@marge.simpson.net> 
	<049A43DFF32DB14DBA34752BE3659AED241EE942@LG-SPMB-MBX01.lseg.stockex.local>
	<5370BEF5.3070802@suse.com>
Message-ID: <049A43DFF32DB14DBA34752BE3659AED241EED21@LG-SPMB-MBX01.lseg.stockex.local>

This is really Great.. We are looking forward to test this.

Best Regards,
Mahendra Laxaman
Technical Consultant, MillenniumIT
Technology Services, LSEG
Telephone +94 11 2416373
Switchboard +94 11 2416000
Mobile +94 (0)77 3935401
Fax +94 11 2413227
mahendral at millenniumit.com
No: 1, Millennium Drive, Malabe, Sri Lanka
www.millenniumit.com

Part of London Stock Exchange Group



-----Original Message-----
From: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] On Behalf Of Kai Dupke
Sent: 12 May 2014 18:01
To: sles-beta at lists.suse.com
Subject: Re: [sles-beta] Tasks get stuck with RT priority

On 05/12/2014 11:55 AM, Laxman, Mahendra wrote:
> Happy to hear that there is an on-going  work to provide the near bare metal behaviour.

You might not be surprised that we have it on the list for features to
look into for our Real Time product, but it still is some way to go.

greetings
Kai Dupke
Senior Product Manager
Server Product Line
-- 
Phone:  +49-(0)5102-9310828     Mail: kai.dupke at suse.com
Mobile: +49-(0)173-5876766      WWW:  www.suse.com

SUSE Linux Products GmbH - Maxfeldstr. 5 - 90409 Nuernberg (Germany)
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG Nurnberg)
_______________________________________________
sles-beta mailing list
sles-beta at lists.suse.com
http://lists.suse.com/mailman/listinfo/sles-beta


This e-mail transmission (inclusive of any attachments) is strictly confidential and intended solely for the ordinary user of the e-mail address to which it was addressed. It may contain legally privileged and/or CONFIDENTIAL information. The unauthorized use, disclosure, distribution printing and/or copying of this e-mail or any information it contains is prohibited and could, in certain circumstances, constitute an offence. If you have received this e-mail in error or are not an intended recipient please inform the sender of the email and MillenniumIT immediately by return e-mail or telephone (+94-11) 2416000. We advise that in keeping with good computing practice, the recipient of this e-mail should ensure that it is virus free. We do not accept responsibility for any virus that may be transferred by way of this e-mail. E-mail may be susceptible to data corruption, interception and unauthorized amendment, and we do not accept liability for any such corruption, interception or amendment or any consequences thereof.  www.millenniumit.com 


From jreidinger at suse.com  Thu May 15 00:38:28 2014
From: jreidinger at suse.com (Josef Reidinger)
Date: Thu, 15 May 2014 08:38:28 +0200
Subject: [sles-beta] Beta6 on EFI
In-Reply-To: <20140514205635.GK11257@sgi.com>
References: <20140514205635.GK11257@sgi.com>
Message-ID: <20140515083828.4858b269@dhcp150.suse.cz>

On Wed, 14 May 2014 15:56:35 -0500
"Tony Ernst" <tee at sgi.com> wrote:

> Is anyone else able to get the beta6 DVD to boot on a x86_64 EFI
> system? It won't boot on ours.
> 
> Regards,
> Tony
> 

If you use autoyast and UEFI, then we have some reports regarding UEFI
boot and missing package. What you need to be sure, is having set
bootloader in autoyast profile to grub2-efi, probably proposing if
bootloader configuration missing is buggy or not smart enough.

Josef

From Klaus.Gmeinwieser at oce.com  Thu May 15 01:24:12 2014
From: Klaus.Gmeinwieser at oce.com (Klaus Gmeinwieser)
Date: Thu, 15 May 2014 09:24:12 +0200
Subject: [sles-beta] New and additional home for root??
In-Reply-To: <3A2B5C20-B505-427A-99D2-C063CBF40A4A@ricis.com>
References: <53732B7B.6090204@oce.com>
	<1400056984.6922.11.camel@ibrokeit.suse.de>
	<3A2B5C20-B505-427A-99D2-C063CBF40A4A@ricis.com>
Message-ID: <53746B9C.1080000@oce.com>

Hi all,

sorry for asking this question in an unclear way...

I was just wondering about the existence of the /home/root directory and
why this is existing anyway? In my opinion /home/root should not (and
never) be existent. /root is home of root and should be. So my question
is, if the existence of /home/root is correct behavior of SLES12 or I
should open a SR for the bug that created the directory

Sorry for confusing...
Rgds
Klaus

Am 14.05.2014 18:23, schrieb Gregory D. Rosenberg:
> Klaus,
>
> Maybe it would make sense to have a soft link from /root and /home/root. This would be beneficial for new users starting out that struggle with the notion that /root is not under /home/root. Of course we all know why and that is to securely isolate it. This probably would not work well when /home was mounted on a different machine or a cluster of machines. So maybe it is a bad suggestion.
>
>
> On May 14, 2014, at 03:43 CDT, Richard Brown <rbrown at suse.de> wrote:
>
>> On Wed, 2014-05-14 at 10:38 +0200, Klaus Gmeinwieser wrote:
>>> The original "/root" which is populated with files and also a new
>>> "/home/root" with all of the files from /etc/skel directory.
>>>
>>> I activated "ROOT_USES_LANG" and also I preset the password within my
>>> autoinst.xml file...
>>>
>>> Is this a new "feature" I missed?
>>
>> On my Beta 6 machines, I only have /root and not /home/root - I do not
>> think what you're seeing is intentional.
>>
>> This includes 2 machines which were installed using AutoYaST, however
>> neither used ROOT_USES_LANG so that would be where I suspect this might
>> have been triggered
>>
>> Hope this helps,
>> Richard
>> --
>> -------------------------------------------------------------------
>>   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://cp.mcafee.com/d/avndzgQ821J5yZXLzHEICXCQrFKc8Lf3DzqdQT64jhOyMOrhKMqekPhOYqem3hOrhKCU-qekS6nPp6fAi8azaQGsKrzaQGsKro8mjp7cLZvC7CjhOe7tuVt4sqerYYe7ccLYJt6OaaJXLYG7DR8OJMddECQjqfniESgFqcy7CQjo0c-l9QWztfVv1dnoovaAVgtHB3_En8vfjt3_En8vfiV2Hsbvg57OFeDkrF_bCSkQrCMnWhEwdbt3_En8vfjiWq80pVwQgr10QgqwxasGMQYQg4WG-q87qNd44qRCi96TXCROiA-syZ
>
>
>
> P.S. Text the word BLIND to 85944 to donate $10 to the NFB Imagination Fund via your phone bill.
>
> The National Federation of the Blind knows that blindness is not the characteristic that defines you or your future. Every day we raise the expectations of blind people, because low expectations create obstacles between blind people and our dreams. You can have the life you want; blindness is not what holds you back.
>
> --
> 73' & 75'
> Gregory D. Rosenberg AB9MZ
> gregg at ricis.com
>
> RICIS, Inc.
> 7849 Bristol Park Drive
> Tinley Park, IL 60477-4594
> http://www.ricis.com
>
> 708-267-6664 Cell
> 708-444-2690 Office
> 708-444-1115 Fax
> (Please call before sending a fax)
>
>
>
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta
>

--
Klaus Gmeinwieser
T +49 (0)8121 72 4358 F +49 (0)8121 72 3173
E klaus.gmeinwieser at oce.com W www.oce.com

Oc? Printing Systems GmbH & Co. KG ? A Canon Group Company
P.O. Box 1260 ? 85581 Poing
Siemensallee 2 ? 85586 Poing ? Germany

Oc? enables its customers to manage their documents efficiently and
effectively by offering
innovative print and document management products and services for
professional
environments.

Oc? Printing Systems GmbH & Co. KG
The company is a limited partnership with its registered office in Poing
? Trade Register HRA 100955 (Amtsgericht M?nchen) ? WEEE-Reg.-No. DE 888
05 443

General Partner: Oc? Printing Systems Gesch?ftsf?hrungsgesellschaft mbH
Registered Office: Poing ? Trade Register HRB 206480 (Amtsgericht M?nchen)
Executive Officer: Andr? Mittelsteiner
This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation.

From jrd at netlab1.net  Thu May 15 01:36:38 2014
From: jrd at netlab1.net (Joe Doupnik)
Date: Thu, 15 May 2014 08:36:38 +0100
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <20140514211427.GA5102@suse.com>
References: <20140514153539.GC11257@sgi.com>	<AAD7066EC17A5541BF5145CD44BEFA72E68EAB70@EX10MBN01.ua-net.ua.edu>
	<20140514211427.GA5102@suse.com>
Message-ID: <53746E86.20401@netlab1.net>

     Without having heard Matthias' presentation on the topic, the 
appearance at present is this is hostage taking. As we all know, PHP is 
a central component of building production servers. Chasing down -devel 
RPMs is awkward enough, now core material is being placed behind locked 
doors. Might someone offer a brief explanation of why this approach is 
being taken?
     Thanks,
     Joe D.

On 14/05/2014 22:14, Matthias G. Eckermann wrote:
> On 2014-05-14 T 15:55 +0000 Beddingfield, Allen wrote:
>
>> I can confirm this as an issue, too.  We
>> definitely require that PHP be included, since we
>> are hosting our web infrastructure on SLES.
> PHP is not on the "ISO" anymore, but in a "module",
> which is only delivered online.
>
> To get PHP, please register your system during
> installation and chose the "Web & Scripting" module.
>
> More on the "Modules" concept I will explain in one
> of the next beta calls.
>
> so long -
> 	MgE
>   
>> From: sles-beta-bounces at lists.suse.com [sles-beta-bounces at lists.suse.com] on behalf of Tony Ernst [tee at sgi.com]
>> Sent: Wednesday, May 14, 2014 10:35 AM
>> To: sles-beta at lists.suse.com
>> Subject: [sles-beta] php disappeared in beta6?
>>
>> Sles12 beta5 had php (php5) rpms. They seem to have disappeared in beta6.
>> Was that intentional? Oddly enough, the php5-devel and the pcp .src rpm
>> are still in the beta6 SDK.


From meissner at suse.de  Thu May 15 01:46:02 2014
From: meissner at suse.de (Marcus Meissner)
Date: Thu, 15 May 2014 09:46:02 +0200
Subject: [sles-beta] New and additional home for root??
In-Reply-To: <53746B9C.1080000@oce.com>
References: <53732B7B.6090204@oce.com>
	<1400056984.6922.11.camel@ibrokeit.suse.de>
	<3A2B5C20-B505-427A-99D2-C063CBF40A4A@ricis.com>
	<53746B9C.1080000@oce.com>
Message-ID: <20140515074601.GA14982@suse.de>

Hi,

it sounds more like a bug during user creation in autoyast.

Ciao, Mrcus
On Thu, May 15, 2014 at 09:24:12AM +0200, Klaus Gmeinwieser wrote:
> Hi all,
>
> sorry for asking this question in an unclear way...
>
> I was just wondering about the existence of the /home/root directory and
> why this is existing anyway? In my opinion /home/root should not (and
> never) be existent. /root is home of root and should be. So my question
> is, if the existence of /home/root is correct behavior of SLES12 or I
> should open a SR for the bug that created the directory
>
> Sorry for confusing...
> Rgds
> Klaus
>
> Am 14.05.2014 18:23, schrieb Gregory D. Rosenberg:
>> Klaus,
>>
>> Maybe it would make sense to have a soft link from /root and /home/root. This would be beneficial for new users starting out that struggle with the notion that /root is not under /home/root. Of course we all know why and that is to securely isolate it. This probably would not work well when /home was mounted on a different machine or a cluster of machines. So maybe it is a bad suggestion.
>>
>>
>> On May 14, 2014, at 03:43 CDT, Richard Brown <rbrown at suse.de> wrote:
>>
>>> On Wed, 2014-05-14 at 10:38 +0200, Klaus Gmeinwieser wrote:
>>>> The original "/root" which is populated with files and also a new
>>>> "/home/root" with all of the files from /etc/skel directory.
>>>>
>>>> I activated "ROOT_USES_LANG" and also I preset the password within my
>>>> autoinst.xml file...
>>>>
>>>> Is this a new "feature" I missed?
>>>
>>> On my Beta 6 machines, I only have /root and not /home/root - I do not
>>> think what you're seeing is intentional.
>>>
>>> This includes 2 machines which were installed using AutoYaST, however
>>> neither used ROOT_USES_LANG so that would be where I suspect this might
>>> have been triggered
>>>
>>> Hope this helps,
>>> Richard
>>> --
>>> -------------------------------------------------------------------
>>>   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://cp.mcafee.com/d/avndzgQ821J5yZXLzHEICXCQrFKc8Lf3DzqdQT64jhOyMOrhKMqekPhOYqem3hOrhKCU-qekS6nPp6fAi8azaQGsKrzaQGsKro8mjp7cLZvC7CjhOe7tuVt4sqerYYe7ccLYJt6OaaJXLYG7DR8OJMddECQjqfniESgFqcy7CQjo0c-l9QWztfVv1dnoovaAVgtHB3_En8vfjt3_En8vfiV2Hsbvg57OFeDkrF_bCSkQrCMnWhEwdbt3_En8vfjiWq80pVwQgr10QgqwxasGMQYQg4WG-q87qNd44qRCi96TXCROiA-syZ
>>
>>
>>
>> P.S. Text the word BLIND to 85944 to donate $10 to the NFB Imagination Fund via your phone bill.
>>
>> The National Federation of the Blind knows that blindness is not the characteristic that defines you or your future. Every day we raise the expectations of blind people, because low expectations create obstacles between blind people and our dreams. You can have the life you want; blindness is not what holds you back.
>>
>> --
>> 73' & 75'
>> Gregory D. Rosenberg AB9MZ
>> gregg at ricis.com
>>
>> RICIS, Inc.
>> 7849 Bristol Park Drive
>> Tinley Park, IL 60477-4594
>> http://www.ricis.com
>>
>> 708-267-6664 Cell
>> 708-444-2690 Office
>> 708-444-1115 Fax
>> (Please call before sending a fax)
>>
>>
>>
>> _______________________________________________
>> sles-beta mailing list
>> sles-beta at lists.suse.com
>> http://lists.suse.com/mailman/listinfo/sles-beta
>>
>
> --
> Klaus Gmeinwieser
> T +49 (0)8121 72 4358 F +49 (0)8121 72 3173
> E klaus.gmeinwieser at oce.com W www.oce.com
>
> Oc? Printing Systems GmbH & Co. KG ? A Canon Group Company
> P.O. Box 1260 ? 85581 Poing
> Siemensallee 2 ? 85586 Poing ? Germany
>
> Oc? enables its customers to manage their documents efficiently and
> effectively by offering
> innovative print and document management products and services for
> professional
> environments.
>
> Oc? Printing Systems GmbH & Co. KG
> The company is a limited partnership with its registered office in Poing
> ? Trade Register HRA 100955 (Amtsgericht M?nchen) ? WEEE-Reg.-No. DE 888
> 05 443
>
> General Partner: Oc? Printing Systems Gesch?ftsf?hrungsgesellschaft mbH
> Registered Office: Poing ? Trade Register HRB 206480 (Amtsgericht M?nchen)
> Executive Officer: Andr? Mittelsteiner
> This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation.
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta
>

From gregg at ricis.com  Thu May 15 01:49:08 2014
From: gregg at ricis.com (Gregory D. Rosenberg)
Date: Thu, 15 May 2014 02:49:08 -0500
Subject: [sles-beta] New and additional home for root??
In-Reply-To: <53746B9C.1080000@oce.com>
References: <53732B7B.6090204@oce.com>
	<1400056984.6922.11.camel@ibrokeit.suse.de>
	<3A2B5C20-B505-427A-99D2-C063CBF40A4A@ricis.com>
	<53746B9C.1080000@oce.com>
Message-ID: <AA31D88E-C912-49AE-AFED-8FEC54BF253A@ricis.com>

Klaus,

I would open an SR. I fully agree with you. Pardon my earlier ramblings.

On May 15, 2014, at 02:24 CDT, Klaus Gmeinwieser <Klaus.Gmeinwieser at oce.com> wrote:

> Hi all,
> 
> sorry for asking this question in an unclear way...
> 
> I was just wondering about the existence of the /home/root directory and
> why this is existing anyway? In my opinion /home/root should not (and
> never) be existent. /root is home of root and should be. So my question
> is, if the existence of /home/root is correct behavior of SLES12 or I
> should open a SR for the bug that created the directory
> 
> Sorry for confusing...
> Rgds
> Klaus
> 
> Am 14.05.2014 18:23, schrieb Gregory D. Rosenberg:
>> Klaus,
>> 
>> Maybe it would make sense to have a soft link from /root and /home/root. This would be beneficial for new users starting out that struggle with the notion that /root is not under /home/root. Of course we all know why and that is to securely isolate it. This probably would not work well when /home was mounted on a different machine or a cluster of machines. So maybe it is a bad suggestion.
>> 
>> 
>> On May 14, 2014, at 03:43 CDT, Richard Brown <rbrown at suse.de> wrote:
>> 
>>> On Wed, 2014-05-14 at 10:38 +0200, Klaus Gmeinwieser wrote:
>>>> The original "/root" which is populated with files and also a new
>>>> "/home/root" with all of the files from /etc/skel directory.
>>>> 
>>>> I activated "ROOT_USES_LANG" and also I preset the password within my
>>>> autoinst.xml file...
>>>> 
>>>> Is this a new "feature" I missed?
>>> 
>>> On my Beta 6 machines, I only have /root and not /home/root - I do not
>>> think what you're seeing is intentional.
>>> 
>>> This includes 2 machines which were installed using AutoYaST, however
>>> neither used ROOT_USES_LANG so that would be where I suspect this might
>>> have been triggered
>>> 
>>> Hope this helps,
>>> Richard
>>> --
>>> -------------------------------------------------------------------
>>>  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://cp.mcafee.com/d/avndzgQ821J5yZXLzHEICXCQrFKc8Lf3DzqdQT64jhOyMOrhKMqekPhOYqem3hOrhKCU-qekS6nPp6fAi8azaQGsKrzaQGsKro8mjp7cLZvC7CjhOe7tuVt4sqerYYe7ccLYJt6OaaJXLYG7DR8OJMddECQjqfniESgFqcy7CQjo0c-l9QWztfVv1dnoovaAVgtHB3_En8vfjt3_En8vfiV2Hsbvg57OFeDkrF_bCSkQrCMnWhEwdbt3_En8vfjiWq80pVwQgr10QgqwxasGMQYQg4WG-q87qNd44qRCi96TXCROiA-syZ
>> 
>> 
>> 
>> P.S. Text the word BLIND to 85944 to donate $10 to the NFB Imagination Fund via your phone bill.
>> 
>> The National Federation of the Blind knows that blindness is not the characteristic that defines you or your future. Every day we raise the expectations of blind people, because low expectations create obstacles between blind people and our dreams. You can have the life you want; blindness is not what holds you back.
>> 
>> --
>> 73' & 75'
>> Gregory D. Rosenberg AB9MZ
>> gregg at ricis.com
>> 
>> RICIS, Inc.
>> 7849 Bristol Park Drive
>> Tinley Park, IL 60477-4594
>> http://www.ricis.com
>> 
>> 708-267-6664 Cell
>> 708-444-2690 Office
>> 708-444-1115 Fax
>> (Please call before sending a fax)
>> 
>> 
>> 
>> _______________________________________________
>> sles-beta mailing list
>> sles-beta at lists.suse.com
>> http://cp.mcafee.com/d/5fHCN0g6x0SyNuWbbPwVMTsSztdNx5VUsYrhKCUMyqekm6jqdS3hOCqenzhOMqejqdQT7PhOCMO-r8NYyh1kpmBjBPspmBjBPr10wUMepvW_fLIKn7tuVtdAsZNEVuvjhhVqWtAkRkkmul3PWApmU6CQjrVKVKVI06vaAWthKDYLwCHIcfBisEeROx_QbAfDFKx_QbAfDFsxlK5LE2zVkDjGdQ_BPpEVppodwLQzh0qmW7_gKg-uCBQQg0PP1EwS21EwR12kVlxFVEw9RlYQgeRyq88RHcAidLTdUPBM
>> 
> 
> --
> Klaus Gmeinwieser
> T +49 (0)8121 72 4358 F +49 (0)8121 72 3173
> E klaus.gmeinwieser at oce.com W http://cp.mcafee.com/d/FZsS76QmbThpus7e6XCQrFKc8Lf3DzqdQT64jhOyMOrhKMqekPhOYqem3hOrhKCU-qekS6nPp6fAi8azaQGsKrzaQGsKro84761Pb_nVZZBOUXHTbFIzDKd7bPWqafbnjIyCGyyPOEuvkzaT0QSCrvdTdTdBeHr-ndQf-xsxYZbAaJMJZ0kvaAWthKDYKrd7bbb1I5-Aq83iTg_W5O7PQQKCy06uod46Mgd46E8iDaIdfd41eGLCy1SIjh16JpAyhJ-VKlqppLsW
> 
> Oc? Printing Systems GmbH & Co. KG ? A Canon Group Company
> P.O. Box 1260 ? 85581 Poing
> Siemensallee 2 ? 85586 Poing ? Germany
> 
> Oc? enables its customers to manage their documents efficiently and
> effectively by offering
> innovative print and document management products and services for
> professional
> environments.
> 
> Oc? Printing Systems GmbH & Co. KG
> The company is a limited partnership with its registered office in Poing
> ? Trade Register HRA 100955 (Amtsgericht M?nchen) ? WEEE-Reg.-No. DE 888
> 05 443
> 
> General Partner: Oc? Printing Systems Gesch?ftsf?hrungsgesellschaft mbH
> Registered Office: Poing ? Trade Register HRB 206480 (Amtsgericht M?nchen)
> Executive Officer: Andr? Mittelsteiner
> This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation.
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://cp.mcafee.com/d/2DRPoA82hJ5yZQmnD1PxKVJ6Wrz2bPMVUSztdNx4QsEIcCQrI6zBcQsL6zBwQsCQrFKfCzBdxBYShzV4y2EOJaDbCUOJaDbCS211NwsO_R-vvpsKeWZOWr8VXzhOY-CyzORQX8FGEEIYG7DR8OJMddICTPtPtPo0c-l9QWztfVv1dnoovaAVgtHB3_En8vfjt3_En8vfiV2Hsbvg57OFeDkrF_bCPhOOOMr1vF6y0QJQf-xsxYZdbFEw1DC3h1I43h1G24FOH3jPh0jGHVEwtH4QghHmp8ArvKrRzKz_kDvS8rm



P.S. Text the word BLIND to 85944 to donate $10 to the NFB Imagination Fund via your phone bill.

The National Federation of the Blind knows that blindness is not the characteristic that defines you or your future. Every day we raise the expectations of blind people, because low expectations create obstacles between blind people and our dreams. You can have the life you want; blindness is not what holds you back. 

--
73' & 75'
Gregory D. Rosenberg AB9MZ
gregg at ricis.com

RICIS, Inc.
7849 Bristol Park Drive
Tinley Park, IL 60477-4594
http://www.ricis.com

708-267-6664 Cell 
708-444-2690 Office
708-444-1115 Fax 
(Please call before sending a fax)




From Klaus.Gmeinwieser at oce.com  Thu May 15 02:02:55 2014
From: Klaus.Gmeinwieser at oce.com (Klaus Gmeinwieser)
Date: Thu, 15 May 2014 10:02:55 +0200
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <53746E86.20401@netlab1.net>
References: <20140514153539.GC11257@sgi.com>
	<AAD7066EC17A5541BF5145CD44BEFA72E68EAB70@EX10MBN01.ua-net.ua.edu>
	<20140514211427.GA5102@suse.com> <53746E86.20401@netlab1.net>
Message-ID: <537474AF.5060301@oce.com>

Hi all,

I agree to Joe and think I speak also for many others, that this is an
absolute NOGO to have core issues to be part of an online only repo, as
this will also enforce a server to be "online" for any installation or
update of "such" software!?!?! This would kick us out of at least 75% of
our installations...

As this is a severe breach in confidence to me, I would like to ask NOW
for any remaining surprise coming up with SLES12...

Please advise as soon as possible with detailed information

Best Regards
Klaus

Am 15.05.2014 09:36, schrieb Joe Doupnik:
>
>      Without having heard Matthias' presentation on the topic, the
> appearance at present is this is hostage taking. As we all know, PHP is
> a central component of building production servers. Chasing down -devel
> RPMs is awkward enough, now core material is being placed behind locked
> doors. Might someone offer a brief explanation of why this approach is
> being taken?
>      Thanks,
>      Joe D.
>
> On 14/05/2014 22:14, Matthias G. Eckermann wrote:
>> On 2014-05-14 T 15:55 +0000 Beddingfield, Allen wrote:
>>
>>> I can confirm this as an issue, too.  We
>>> definitely require that PHP be included, since we
>>> are hosting our web infrastructure on SLES.
>> PHP is not on the "ISO" anymore, but in a "module",
>> which is only delivered online.
>>
>> To get PHP, please register your system during
>> installation and chose the "Web & Scripting" module.
>>
>> More on the "Modules" concept I will explain in one
>> of the next beta calls.
>>
>> so long -
>>     MgE
>>> From: sles-beta-bounces at lists.suse.com
>>> [sles-beta-bounces at lists.suse.com] on behalf of Tony Ernst [tee at sgi.com]
>>> Sent: Wednesday, May 14, 2014 10:35 AM
>>> To: sles-beta at lists.suse.com
>>> Subject: [sles-beta] php disappeared in beta6?
>>>
>>> Sles12 beta5 had php (php5) rpms. They seem to have disappeared in
>>> beta6.
>>> Was that intentional? Oddly enough, the php5-devel and the pcp .src rpm
>>> are still in the beta6 SDK.
>
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta

--
Klaus Gmeinwieser
T +49 (0)8121 72 4358 F +49 (0)8121 72 3173
E klaus.gmeinwieser at oce.com W www.oce.com

Oc? Printing Systems GmbH & Co. KG ? A Canon Group Company
P.O. Box 1260 ? 85581 Poing
Siemensallee 2 ? 85586 Poing ? Germany

Oc? enables its customers to manage their documents efficiently and
effectively by offering
innovative print and document management products and services for
professional
environments.

Oc? Printing Systems GmbH & Co. KG
The company is a limited partnership with its registered office in Poing
? Trade Register HRA 100955 (Amtsgericht M?nchen) ? WEEE-Reg.-No. DE 888
05 443

General Partner: Oc? Printing Systems Gesch?ftsf?hrungsgesellschaft mbH
Registered Office: Poing ? Trade Register HRB 206480 (Amtsgericht M?nchen)
Executive Officer: Andr? Mittelsteiner
This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation.

From rbrown at suse.de  Thu May 15 02:04:49 2014
From: rbrown at suse.de (rbrown)
Date: Thu, 15 May 2014 10:04:49 +0200
Subject: [sles-beta] =?utf-8?q?php_disappeared_in_beta6=3F?=
In-Reply-To: <53746E86.20401@netlab1.net>
References: " <20140514153539.GC11257@sgi.com>"
	<AAD7066EC17A5541BF5145CD44BEFA72E68EAB70@EX10MBN01.ua-net.ua.edu>
	<20140514211427.GA5102@suse.com> <53746E86.20401@netlab1.net>
Message-ID: <1e6baf755026aeaff80ff3d690e7b0d0@suse.de>

'hostage taking'? quite an emotive way of putting it Joe :)
Without wanting to preempt too much Matthias' call, partially because 
I'm lacking all the details, I would like to share a little about what I 
know about Modules and why I think they're exciting.
In my past life as a customer, I was involved in lots of conversations 
about how SLES was not the best platform for certain workloads, such as 
PHP Web Hosting, as the release cycle and strict adherence to keeping 
versions the same over the lifespan of a SLE release meant it was 
hard/impossible to run more recent versions of PHP on top of SLES.
It is my understanding that 'Modules' is an answer to that issue, a way 
for SUSE to deliver specific software stacks at a different rate of 
change than the 'core' SLES platform

So I wouldn't characterize the relocation of PHP as 'hostage taking', 
but more 'liberation', able to follow a slightly different path which I 
expect Matthias' presentation will explain far better than I can.

On 2014-05-15 09:36, Joe Doupnik wrote:
> Without having heard Matthias' presentation on the topic, the
> appearance at present is this is hostage taking. As we all know, PHP
> is a central component of building production servers. Chasing down
> -devel RPMs is awkward enough, now core material is being placed
> behind locked doors. Might someone offer a brief explanation of why
> this approach is being taken?
>     Thanks,
>     Joe D.
> 
> On 14/05/2014 22:14, Matthias G. Eckermann wrote:
>> On 2014-05-14 T 15:55 +0000 Beddingfield, Allen wrote:
>> 
>>> I can confirm this as an issue, too.  We
>>> definitely require that PHP be included, since we
>>> are hosting our web infrastructure on SLES.
>> PHP is not on the "ISO" anymore, but in a "module",
>> which is only delivered online.
>> 
>> To get PHP, please register your system during
>> installation and chose the "Web & Scripting" module.
>> 
>> More on the "Modules" concept I will explain in one
>> of the next beta calls.
>> 
>> so long -
>> 	MgE
>> 
>>> From: sles-beta-bounces at lists.suse.com 
>>> [sles-beta-bounces at lists.suse.com] on behalf of Tony Ernst 
>>> [tee at sgi.com]
>>> Sent: Wednesday, May 14, 2014 10:35 AM
>>> To: sles-beta at lists.suse.com
>>> Subject: [sles-beta] php disappeared in beta6?
>>> 
>>> Sles12 beta5 had php (php5) rpms. They seem to have disappeared in 
>>> beta6.
>>> Was that intentional? Oddly enough, the php5-devel and the pcp .src 
>>> rpm
>>> are still in the beta6 SDK.
> 
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta

From jrd at netlab1.net  Thu May 15 02:11:46 2014
From: jrd at netlab1.net (Joe Doupnik)
Date: Thu, 15 May 2014 09:11:46 +0100
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <1e6baf755026aeaff80ff3d690e7b0d0@suse.de>
References: "
	<20140514153539.GC11257@sgi.com>"	<AAD7066EC17A5541BF5145CD44BEFA72E68EAB70@EX10MBN01.ua-net.ua.edu>	<20140514211427.GA5102@suse.com>
	<53746E86.20401@netlab1.net>
	<1e6baf755026aeaff80ff3d690e7b0d0@suse.de>
Message-ID: <537476C2.30900@netlab1.net>

Richard,
     Thanks for stepping in.
     I used those words carefully, as that is what the current 
statements suggest.
     Offering multiple tracks for selected RPM groups is one thing, an 
interesting innovation which would be a good step forward. Removing such 
core material from the mainline distribution and tying them to 
subscription-only repos is a very different matter and some of us think 
it would be a fatal move. Again, I chose that word purposefully.
     Thanks,
     Joe D.

On 15/05/2014 09:04, rbrown wrote:
> 'hostage taking'? quite an emotive way of putting it Joe :)
> Without wanting to preempt too much Matthias' call, partially because 
> I'm lacking all the details, I would like to share a little about what 
> I know about Modules and why I think they're exciting.
> In my past life as a customer, I was involved in lots of conversations 
> about how SLES was not the best platform for certain workloads, such 
> as PHP Web Hosting, as the release cycle and strict adherence to 
> keeping versions the same over the lifespan of a SLE release meant it 
> was hard/impossible to run more recent versions of PHP on top of SLES.
> It is my understanding that 'Modules' is an answer to that issue, a 
> way for SUSE to deliver specific software stacks at a different rate 
> of change than the 'core' SLES platform
>
> So I wouldn't characterize the relocation of PHP as 'hostage taking', 
> but more 'liberation', able to follow a slightly different path which 
> I expect Matthias' presentation will explain far better than I can.
>
> On 2014-05-15 09:36, Joe Doupnik wrote:
>> Without having heard Matthias' presentation on the topic, the
>> appearance at present is this is hostage taking. As we all know, PHP
>> is a central component of building production servers. Chasing down
>> -devel RPMs is awkward enough, now core material is being placed
>> behind locked doors. Might someone offer a brief explanation of why
>> this approach is being taken?
>>     Thanks,
>>     Joe D.
>>
>> On 14/05/2014 22:14, Matthias G. Eckermann wrote:
>>> On 2014-05-14 T 15:55 +0000 Beddingfield, Allen wrote:
>>>
>>>> I can confirm this as an issue, too. We
>>>> definitely require that PHP be included, since we
>>>> are hosting our web infrastructure on SLES.
>>> PHP is not on the "ISO" anymore, but in a "module",
>>> which is only delivered online.
>>>
>>> To get PHP, please register your system during
>>> installation and chose the "Web & Scripting" module.
>>>
>>> More on the "Modules" concept I will explain in one
>>> of the next beta calls.
>>>
>>> so long -
>>>     MgE
>>>
>>>> From: sles-beta-bounces at lists.suse.com 
>>>> [sles-beta-bounces at lists.suse.com] on behalf of Tony Ernst 
>>>> [tee at sgi.com]
>>>> Sent: Wednesday, May 14, 2014 10:35 AM
>>>> To: sles-beta at lists.suse.com
>>>> Subject: [sles-beta] php disappeared in beta6?
>>>>
>>>> Sles12 beta5 had php (php5) rpms. They seem to have disappeared in 
>>>> beta6.
>>>> Was that intentional? Oddly enough, the php5-devel and the pcp .src 
>>>> rpm
>>>> are still in the beta6 SDK.
>>
>> _______________________________________________
>> 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


From fcrozat at suse.com  Thu May 15 02:43:43 2014
From: fcrozat at suse.com (Frederic Crozat)
Date: Thu, 15 May 2014 10:43:43 +0200
Subject: [sles-beta] Beta6 on EFI
In-Reply-To: <20140514205635.GK11257@sgi.com>
References: <20140514205635.GK11257@sgi.com>
Message-ID: <1400143423.2593.7.camel@par-r81vxc7.par.novell.com>

Le mercredi 14 mai 2014 ? 15:56 -0500, Tony Ernst a ?crit :
> Is anyone else able to get the beta6 DVD to boot on a x86_64 EFI system?
> It won't boot on ours.

Please open a SR with more details on the system tested and if Secure
Boot was involved or not. You might also want to test with dumping the
ISO image on an usb stick and boot from it.

Thanks !


-- 
Frederic Crozat
Project Manager Enterprise Desktop
SUSE


From gregg at ricis.com  Thu May 15 03:13:32 2014
From: gregg at ricis.com (Gregory D. Rosenberg)
Date: Thu, 15 May 2014 04:13:32 -0500
Subject: [sles-beta] Beta6 on EFI
In-Reply-To: <20140515083828.4858b269@dhcp150.suse.cz>
References: <20140514205635.GK11257@sgi.com>
	<20140515083828.4858b269@dhcp150.suse.cz>
Message-ID: <7B8820F9-EFEB-4E0D-B5EE-30BD72C42F7F@ricis.com>

Good morning Josef,

I can get it to boot on my MAC under VMware Fusion, but I can?t get the install started. I can verify the media, but I am unsure what NIC driver to load with VMware Fusion. I tried a few and ever NIC choice caused the system to hang. When I manage to let the NIC default to the one I assigned to it on my MAC. Then it complains it can?t find the repository, even though it is a mounted image. I am using the x86_64 Mini ISO. I will try the full one once it finishes downloading.

On May 15, 2014, at 01:38 CDT, Josef Reidinger <jreidinger at suse.com> wrote:

> On Wed, 14 May 2014 15:56:35 -0500
> "Tony Ernst" <tee at sgi.com> wrote:
> 
>> Is anyone else able to get the beta6 DVD to boot on a x86_64 EFI
>> system? It won't boot on ours.
>> 
>> Regards,
>> Tony
>> 
> 
> If you use autoyast and UEFI, then we have some reports regarding UEFI
> boot and missing package. What you need to be sure, is having set
> bootloader in autoyast profile to grub2-efi, probably proposing if
> bootloader configuration missing is buggy or not smart enough.
> 
> Josef
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://cp.mcafee.com/d/avndy1J5yZQmnPhOCOrKrhKCUMyYYeudETjsohd7ab39J6X1EVjd7bNEVod79J6WrzVEVjopvdAo-h8wGcHiFOVKcHiFOVJBSXz0VB_HYYyqenDeLsKCO-NObdTT4-mKzp5dmVEVjVkffGhBrwqrhdECQuKBhIxiQp4fdECM0pYGjFR6WvO-2qKMM-l9OwXna7_gKg-uCW7_gKg-uBO5mUm-wafBiteETj-ndFzAmjobZ8Qg6BKx_QbAfDFFtd40PYZsd45o6y0q5MQSCYr67pjaogt



P.S. Text the word BLIND to 85944 to donate $10 to the NFB Imagination Fund via your phone bill.

The National Federation of the Blind knows that blindness is not the characteristic that defines you or your future. Every day we raise the expectations of blind people, because low expectations create obstacles between blind people and our dreams. You can have the life you want; blindness is not what holds you back. 

--
73' & 75'
Gregory D. Rosenberg AB9MZ
gregg at ricis.com

RICIS, Inc.
7849 Bristol Park Drive
Tinley Park, IL 60477-4594
http://www.ricis.com

708-267-6664 Cell 
708-444-2690 Office
708-444-1115 Fax 
(Please call before sending a fax)




From pieter.hollants at dfs.de  Thu May 15 03:46:46 2014
From: pieter.hollants at dfs.de (Pieter Hollants)
Date: Thu, 15 May 2014 09:46:46 +0000
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <20140514211427.GA5102@suse.com>
References: <20140514153539.GC11257@sgi.com>
	<AAD7066EC17A5541BF5145CD44BEFA72E68EAB70@EX10MBN01.ua-net.ua.edu>
	<20140514211427.GA5102@suse.com>
Message-ID: <4c3641b0b0a84805b7fb10afe11b1cb2@LGNMSXA01.prod.bk.dfs>

There are environments that do not have online access for security reasons. So whatever the module concept is exactly, be sure it works with addon ISOs, too.

-----Urspr?ngliche Nachricht-----
Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Matthias G. Eckermann
Gesendet: Mittwoch, 14. Mai 2014 23:14
An: Beddingfield, Allen; sles-beta at lists.suse.com; tee at sgi.com
Betreff: Re: [sles-beta] php disappeared in beta6?

On 2014-05-14 T 15:55 +0000 Beddingfield, Allen wrote:

> I can confirm this as an issue, too.  We definitely require that PHP 
> be included, since we are hosting our web infrastructure on SLES.

PHP is not on the "ISO" anymore, but in a "module", which is only delivered online. 

To get PHP, please register your system during installation and chose the "Web & Scripting" module.

More on the "Modules" concept I will explain in one of the next beta calls.

so long -
	MgE
 
> From: sles-beta-bounces at lists.suse.com 
> [sles-beta-bounces at lists.suse.com] on behalf of Tony Ernst 
> [tee at sgi.com]
> Sent: Wednesday, May 14, 2014 10:35 AM
> To: sles-beta at lists.suse.com
> Subject: [sles-beta] php disappeared in beta6?
> 
> Sles12 beta5 had php (php5) rpms. They seem to have disappeared in beta6.
> Was that intentional? Oddly enough, the php5-devel and the pcp .src 
> rpm are still in the beta6 SDK.

-- 
Matthias G. Eckermann     Senior Product Manager   SUSE? Linux Enterprise
Phone: +49 30 44315731    Mobile: +49 179 2949448    E-Mail: mge at suse.com
SUSE LINUX Products GmbH  Maxfeldstra?e 5          90409 N?rnberg Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) _______________________________________________
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>

From urs.frey at post.ch  Thu May 15 04:17:50 2014
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Thu, 15 May 2014 10:17:50 +0000
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <4c3641b0b0a84805b7fb10afe11b1cb2@LGNMSXA01.prod.bk.dfs>
References: <20140514153539.GC11257@sgi.com>
	<AAD7066EC17A5541BF5145CD44BEFA72E68EAB70@EX10MBN01.ua-net.ua.edu>
	<20140514211427.GA5102@suse.com>
	<4c3641b0b0a84805b7fb10afe11b1cb2@LGNMSXA01.prod.bk.dfs>
Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9982D7@HXMB12.pnet.ch>

Thank you Pieter

YES I am behind an SMT, the only allowed contact to NCC and possible repository sources so far. 
So when modules are only available online and SMT on SLES11-SP3 can't see them, there is no test possibility.
SMT for SLE-12 shall be ready someday after release of SLES12 and there is also a change from NCC to SCC.
I wonder how all this will work



Urs Frey????????????????????????????????????????????? 
Post CH AG
Informationstechnologie
IT Betrieb 
Webergutstrasse 12 
3030 Bern (Zollikofen) 
Telefon : ++41 (0)58 338 58 70 
FAX???? : ++41 (0)58 667 30 07 
E-Mail:?? urs.frey at post.ch


-----Urspr?ngliche Nachricht-----
Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Pieter Hollants
Gesendet: Thursday, May 15, 2014 11:47 AM
An: Matthias G. Eckermann; Beddingfield, Allen; sles-beta at lists.suse.com; tee at sgi.com
Betreff: Re: [sles-beta] php disappeared in beta6?

There are environments that do not have online access for security reasons. So whatever the module concept is exactly, be sure it works with addon ISOs, too.

-----Urspr?ngliche Nachricht-----
Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Matthias G. Eckermann
Gesendet: Mittwoch, 14. Mai 2014 23:14
An: Beddingfield, Allen; sles-beta at lists.suse.com; tee at sgi.com
Betreff: Re: [sles-beta] php disappeared in beta6?

On 2014-05-14 T 15:55 +0000 Beddingfield, Allen wrote:

> I can confirm this as an issue, too.  We definitely require that PHP 
> be included, since we are hosting our web infrastructure on SLES.

PHP is not on the "ISO" anymore, but in a "module", which is only delivered online. 

To get PHP, please register your system during installation and chose the "Web & Scripting" module.

More on the "Modules" concept I will explain in one of the next beta calls.

so long -
	MgE
 
> From: sles-beta-bounces at lists.suse.com 
> [sles-beta-bounces at lists.suse.com] on behalf of Tony Ernst 
> [tee at sgi.com]
> Sent: Wednesday, May 14, 2014 10:35 AM
> To: sles-beta at lists.suse.com
> Subject: [sles-beta] php disappeared in beta6?
> 
> Sles12 beta5 had php (php5) rpms. They seem to have disappeared in beta6.
> Was that intentional? Oddly enough, the php5-devel and the pcp .src 
> rpm are still in the beta6 SDK.

-- 
Matthias G. Eckermann     Senior Product Manager   SUSE? Linux Enterprise
Phone: +49 30 44315731    Mobile: +49 179 2949448    E-Mail: mge at suse.com
SUSE LINUX Products GmbH  Maxfeldstra?e 5          90409 N?rnberg Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) _______________________________________________
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>
_______________________________________________
sles-beta mailing list
sles-beta at lists.suse.com
http://lists.suse.com/mailman/listinfo/sles-beta

From okir at suse.de  Thu May 15 05:04:26 2014
From: okir at suse.de (Olaf Kirch)
Date: Thu, 15 May 2014 13:04:26 +0200
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <53746E86.20401@netlab1.net>
References: <20140514153539.GC11257@sgi.com> <20140514211427.GA5102@suse.com>
	<53746E86.20401@netlab1.net>
Message-ID: <201405151304.26509.okir@suse.de>


Hi Joe,

On Thursday 15 May 2014 09:36:38 Joe Doupnik wrote:
>      Without having heard Matthias' presentation on the topic, the
> appearance at present is this is hostage taking. As we all know,
>  PHP is a central component of building production servers. Chasing
>  down -devel RPMs is awkward enough, now core material is being
>  placed behind locked doors. Might someone offer a brief
>  explanation of why this approach is being taken?

"Hostage taking" and "locked door" are somewhat strong words... and I 
hope you'll come to a different conclusion once we're talking about 
the facts behind these changes.

In a nutshell, SLES faces a dilemma with fast moving technologies. 
SLES releases are in the market for a very long time. Customers using 
SLES expect a high level of stability in everything, including APIs. 
Now, API stability is definitely not one of the focus areas of the 
people creating Web development frameworks. This includes php, ruby on 
rails, you name it.

With SLES, we could definitely take the approach of companies selling 
pharmaceuticals: "Bayer Froozle fights migraine, except when you do 
this or that or something else, and by the way if you're unlucky, it 
might make your hair fall out, cause your ears to grown like balloons 
and your nose to turn green, ..." Just like that, we could say "In 
SLES, we keep all APIs stable, except for <insert longish list>, and 
we provide full support for everything, except for <insert another 
list>."

In some weird coordinate system, this might be considered customer 
friendly, but in most it's not.

In the past, we have had a very hard time to upgrade components such 
as php. Not really for technical reasons, but because of such 
expectations on the life cycle. So what we are going to do is to 
create several modules (aka channels) which will be free of charge to 
SLE customers. These modules will hold collections of related 
packages, and communicate a clear life cycle and support statement for 
each module.

You discovered the drawback of the module concept. It's easy to miss. 
On the other hand, you receive a strong benefit - which is a regular 
refresh of the code base for components such as php, which was not 
possible before.

One of these modules will be targeted at Web Development, and contain 
PHP.

Regards,
Olaf
-- 
Neo didn't bring down the Matrix. SOA did. (soafacts.com)
--------------------------------------------
Olaf Kirch - Director SUSE Linux Enterprise; R&D (okir at suse.com)
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG 
N?rnberg) 

From mge at suse.com  Thu May 15 05:06:15 2014
From: mge at suse.com (Matthias G. Eckermann)
Date: Thu, 15 May 2014 13:06:15 +0200
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9982D7@HXMB12.pnet.ch>
References: <20140514153539.GC11257@sgi.com>
	<AAD7066EC17A5541BF5145CD44BEFA72E68EAB70@EX10MBN01.ua-net.ua.edu>
	<20140514211427.GA5102@suse.com>
	<4c3641b0b0a84805b7fb10afe11b1cb2@LGNMSXA01.prod.bk.dfs>
	<40637DBB36AF3941B243A286A432CA0B0F9982D7@HXMB12.pnet.ch>
Message-ID: <20140515110615.GB9453@suse.com>

Hello all,

On 2014-05-15 T 10:17 +0000 urs.frey at post.ch wrote:
 
> YES I am behind an SMT, the only allowed contact
> to NCC and possible repository sources so far.  So
> when modules are only available online and SMT on
> SLES11-SP3 can't see them, there is no test
> possibility.  SMT for SLE-12 shall be ready
> someday after release of SLES12 and there is also
> a change from NCC to SCC.  I wonder how all this
> will work

SMT 11 SP3 will (get an update) and be able to mirror
SUSE Linux Enterprise 12 related repositories, and
yes, this certainly includes the Modules.

In other words: if you have a way to work with
maintenance updates provided by SUSE in a structured
way, you will also be able to work with Modules.

Others already sent more details on the benefits of
Modules for keeping SLES "fresh" and attractive.

HTH -
	MgE

 
> -----Urspr?ngliche Nachricht-----
> Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Pieter Hollants
> Gesendet: Thursday, May 15, 2014 11:47 AM
> An: Matthias G. Eckermann; Beddingfield, Allen; sles-beta at lists.suse.com; tee at sgi.com
> Betreff: Re: [sles-beta] php disappeared in beta6?
> 
> There are environments that do not have online access for security reasons. So whatever the module concept is exactly, be sure it works with addon ISOs, too.
> 
> -----Urspr?ngliche Nachricht-----
> Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Matthias G. Eckermann
> Gesendet: Mittwoch, 14. Mai 2014 23:14
> An: Beddingfield, Allen; sles-beta at lists.suse.com; tee at sgi.com
> Betreff: Re: [sles-beta] php disappeared in beta6?
> 
> On 2014-05-14 T 15:55 +0000 Beddingfield, Allen wrote:
> 
> > I can confirm this as an issue, too.  We definitely require that PHP 
> > be included, since we are hosting our web infrastructure on SLES.
> 
> PHP is not on the "ISO" anymore, but in a "module", which is only delivered online. 
> 
> To get PHP, please register your system during installation and chose the "Web & Scripting" module.
> 
> More on the "Modules" concept I will explain in one of the next beta calls.
> 
> so long -
> 	MgE
>  
> > From: sles-beta-bounces at lists.suse.com 
> > [sles-beta-bounces at lists.suse.com] on behalf of Tony Ernst 
> > [tee at sgi.com]
> > Sent: Wednesday, May 14, 2014 10:35 AM
> > To: sles-beta at lists.suse.com
> > Subject: [sles-beta] php disappeared in beta6?
> > 
> > Sles12 beta5 had php (php5) rpms. They seem to have disappeared in beta6.
> > Was that intentional? Oddly enough, the php5-devel and the pcp .src 
> > rpm are still in the beta6 SDK.
> 
> -- 
> Matthias G. Eckermann     Senior Product Manager   SUSE? Linux Enterprise
> Phone: +49 30 44315731    Mobile: +49 179 2949448    E-Mail: mge at suse.com
> SUSE LINUX Products GmbH  Maxfeldstra?e 5          90409 N?rnberg Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) _______________________________________________
> 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>
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta

-- 
Matthias G. Eckermann     Senior Product Manager   SUSE? Linux Enterprise
Phone: +49 30 44315731    Mobile: +49 179 2949448    E-Mail: mge at suse.com
SUSE LINUX Products GmbH  Maxfeldstra?e 5          90409 N?rnberg Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg)

From jrd at netlab1.net  Thu May 15 05:17:05 2014
From: jrd at netlab1.net (Joe Doupnik)
Date: Thu, 15 May 2014 12:17:05 +0100
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <201405151304.26509.okir@suse.de>
References: <20140514153539.GC11257@sgi.com>
	<20140514211427.GA5102@suse.com>	<53746E86.20401@netlab1.net>
	<201405151304.26509.okir@suse.de>
Message-ID: <5374A231.6080108@netlab1.net>

     If I might clarify procedures, it would go like this.
     Let us distinguish between tail and dog in this part of things. 
That means ship PHP and many other standard items as before, providing 
the long term base, and those are part of DVD1 when we build a server. 
No removed functionality at installation time. That's the pooch. 
Alternatives, which I am pleased to see, are options, "tail" items, 
which might require yet another set of channels or be on DVD1 in a 
useful manner. To be candid, the multiplicity of channels is getting out 
of hand, but I don't have a clever solution to cite here.
     The reason I chose those strong words is because they represent 
what we in the field would be faced with. One does not wish to think 
about what trade press articles would say, so we work out these things 
within our group.
     Thanks,
     Joe D.

On 15/05/2014 12:04, Olaf Kirch wrote:
> Hi Joe,
>
> On Thursday 15 May 2014 09:36:38 Joe Doupnik wrote:
>>       Without having heard Matthias' presentation on the topic, the
>> appearance at present is this is hostage taking. As we all know,
>>   PHP is a central component of building production servers. Chasing
>>   down -devel RPMs is awkward enough, now core material is being
>>   placed behind locked doors. Might someone offer a brief
>>   explanation of why this approach is being taken?
> "Hostage taking" and "locked door" are somewhat strong words... and I
> hope you'll come to a different conclusion once we're talking about
> the facts behind these changes.
>
> In a nutshell, SLES faces a dilemma with fast moving technologies.
> SLES releases are in the market for a very long time. Customers using
> SLES expect a high level of stability in everything, including APIs.
> Now, API stability is definitely not one of the focus areas of the
> people creating Web development frameworks. This includes php, ruby on
> rails, you name it.
>
> With SLES, we could definitely take the approach of companies selling
> pharmaceuticals: "Bayer Froozle fights migraine, except when you do
> this or that or something else, and by the way if you're unlucky, it
> might make your hair fall out, cause your ears to grown like balloons
> and your nose to turn green, ..." Just like that, we could say "In
> SLES, we keep all APIs stable, except for <insert longish list>, and
> we provide full support for everything, except for <insert another
> list>."
>
> In some weird coordinate system, this might be considered customer
> friendly, but in most it's not.
>
> In the past, we have had a very hard time to upgrade components such
> as php. Not really for technical reasons, but because of such
> expectations on the life cycle. So what we are going to do is to
> create several modules (aka channels) which will be free of charge to
> SLE customers. These modules will hold collections of related
> packages, and communicate a clear life cycle and support statement for
> each module.
>
> You discovered the drawback of the module concept. It's easy to miss.
> On the other hand, you receive a strong benefit - which is a regular
> refresh of the code base for components such as php, which was not
> possible before.
>
> One of these modules will be targeted at Web Development, and contain
> PHP.
>
> Regards,
> Olaf


From Klaus.Gmeinwieser at oce.com  Thu May 15 05:25:15 2014
From: Klaus.Gmeinwieser at oce.com (Klaus Gmeinwieser)
Date: Thu, 15 May 2014 13:25:15 +0200
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <20140515110615.GB9453@suse.com>
References: <20140514153539.GC11257@sgi.com>
	<AAD7066EC17A5541BF5145CD44BEFA72E68EAB70@EX10MBN01.ua-net.ua.edu>
	<20140514211427.GA5102@suse.com>
	<4c3641b0b0a84805b7fb10afe11b1cb2@LGNMSXA01.prod.bk.dfs>
	<40637DBB36AF3941B243A286A432CA0B0F9982D7@HXMB12.pnet.ch>
	<20140515110615.GB9453@suse.com>
Message-ID: <5374A41B.8020509@oce.com>

Hello Matthias,

I understand the approach to get possibilities to have 10zears of
support and also to be able to migrate to newer versions of software so
to have more flexibility.

As of our way we deliver software to the customers, we have the absolute
need to have installation medias keeping the whole process offline. So
from what I understand, I can get packages via SMT to be installed on a
SLES connected to the SMT. Will there be any kind of Addon Medias, Will
there be a way to include software packages in a default installation
without playing disc jockey? How will the patch/update process be done?
One offline Iso per channel?

I will not talk about any upgrade from SLES11 to SLES12 issues, which
will only be possible with a internet (or at least SMT) enabled server?

What, if the customer is located somewhere "close to nowhere", without
SMT and without propper internet?

Again, this issue came up WITHOUT any message before it was detected by
the BETA testers. What was the original plan of SUSE to make an official
announcement of these changes (as with KDE)?

Please give me answers to my concerns!

Rgds
Klaus


Am 15.05.2014 13:06, schrieb Matthias G. Eckermann:
> Hello all,
>
> On 2014-05-15 T 10:17 +0000 urs.frey at post.ch wrote:
>
>> YES I am behind an SMT, the only allowed contact
>> to NCC and possible repository sources so far.  So
>> when modules are only available online and SMT on
>> SLES11-SP3 can't see them, there is no test
>> possibility.  SMT for SLE-12 shall be ready
>> someday after release of SLES12 and there is also
>> a change from NCC to SCC.  I wonder how all this
>> will work
>
> SMT 11 SP3 will (get an update) and be able to mirror
> SUSE Linux Enterprise 12 related repositories, and
> yes, this certainly includes the Modules.
>
> In other words: if you have a way to work with
> maintenance updates provided by SUSE in a structured
> way, you will also be able to work with Modules.
>
> Others already sent more details on the benefits of
> Modules for keeping SLES "fresh" and attractive.
>
> HTH -
>       MgE
>
>
>> -----Urspr?ngliche Nachricht-----
>> Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Pieter Hollants
>> Gesendet: Thursday, May 15, 2014 11:47 AM
>> An: Matthias G. Eckermann; Beddingfield, Allen; sles-beta at lists.suse.com; tee at sgi.com
>> Betreff: Re: [sles-beta] php disappeared in beta6?
>>
>> There are environments that do not have online access for security reasons. So whatever the module concept is exactly, be sure it works with addon ISOs, too.
>>
>> -----Urspr?ngliche Nachricht-----
>> Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Matthias G. Eckermann
>> Gesendet: Mittwoch, 14. Mai 2014 23:14
>> An: Beddingfield, Allen; sles-beta at lists.suse.com; tee at sgi.com
>> Betreff: Re: [sles-beta] php disappeared in beta6?
>>
>> On 2014-05-14 T 15:55 +0000 Beddingfield, Allen wrote:
>>
>>> I can confirm this as an issue, too.  We definitely require that PHP
>>> be included, since we are hosting our web infrastructure on SLES.
>>
>> PHP is not on the "ISO" anymore, but in a "module", which is only delivered online.
>>
>> To get PHP, please register your system during installation and chose the "Web & Scripting" module.
>>
>> More on the "Modules" concept I will explain in one of the next beta calls.
>>
>> so long -
>>      MgE
>>
>>> From: sles-beta-bounces at lists.suse.com
>>> [sles-beta-bounces at lists.suse.com] on behalf of Tony Ernst
>>> [tee at sgi.com]
>>> Sent: Wednesday, May 14, 2014 10:35 AM
>>> To: sles-beta at lists.suse.com
>>> Subject: [sles-beta] php disappeared in beta6?
>>>
>>> Sles12 beta5 had php (php5) rpms. They seem to have disappeared in beta6.
>>> Was that intentional? Oddly enough, the php5-devel and the pcp .src
>>> rpm are still in the beta6 SDK.
>>
>> --
>> Matthias G. Eckermann     Senior Product Manager   SUSE? Linux Enterprise
>> Phone: +49 30 44315731    Mobile: +49 179 2949448    E-Mail: mge at suse.com
>> SUSE LINUX Products GmbH  Maxfeldstra?e 5          90409 N?rnberg Germany
>> GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) _______________________________________________
>> 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>
>> _______________________________________________
>> sles-beta mailing list
>> sles-beta at lists.suse.com
>> http://lists.suse.com/mailman/listinfo/sles-beta
>

--
Klaus Gmeinwieser
T +49 (0)8121 72 4358 F +49 (0)8121 72 3173
E klaus.gmeinwieser at oce.com W www.oce.com

Oc? Printing Systems GmbH & Co. KG ? A Canon Group Company
P.O. Box 1260 ? 85581 Poing
Siemensallee 2 ? 85586 Poing ? Germany

Oc? enables its customers to manage their documents efficiently and
effectively by offering
innovative print and document management products and services for
professional
environments.

Oc? Printing Systems GmbH & Co. KG
The company is a limited partnership with its registered office in Poing
? Trade Register HRA 100955 (Amtsgericht M?nchen) ? WEEE-Reg.-No. DE 888
05 443

General Partner: Oc? Printing Systems Gesch?ftsf?hrungsgesellschaft mbH
Registered Office: Poing ? Trade Register HRB 206480 (Amtsgericht M?nchen)
Executive Officer: Andr? Mittelsteiner
This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation.

From pieter.hollants at dfs.de  Thu May 15 06:23:40 2014
From: pieter.hollants at dfs.de (Pieter Hollants)
Date: Thu, 15 May 2014 12:23:40 +0000
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <5374A231.6080108@netlab1.net>
References: <20140514153539.GC11257@sgi.com>
	<20140514211427.GA5102@suse.com>	<53746E86.20401@netlab1.net>
	<201405151304.26509.okir@suse.de> <5374A231.6080108@netlab1.net>
Message-ID: <793d4b13bcf34209be5e668b8a512864@LGNMSXA01.prod.bk.dfs>

That would exactly be the right solution to get the best of both: not complicating customers' install scenarios further AND satisfying other customer's demands for up-to-date PHP, Python, younameit. 
Otherwise, as suggested, SUSE should make sure to create a addon ISO as well. You can perfectly offer that ISO download subject to the same support lifecycle statements as the online repo. Maybe a SLEWEB addon as for HA.

We perfectly understand that SUSE doesn't want to raise assumptions that PHP etc. can be supported in the same way as, say, core-utils, and that's fine. But at the same time SUSE needs to understand customer requirements. And as long as your next German flight's security is guaranteed by months-taking software approval procedures, we need ISOs, not online repos.

-----Urspr?ngliche Nachricht-----
Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Joe Doupnik
Gesendet: Donnerstag, 15. Mai 2014 13:17
An: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] php disappeared in beta6?

     If I might clarify procedures, it would go like this.
     Let us distinguish between tail and dog in this part of things. 
That means ship PHP and many other standard items as before, providing the long term base, and those are part of DVD1 when we build a server. 
No removed functionality at installation time. That's the pooch. 
Alternatives, which I am pleased to see, are options, "tail" items, which might require yet another set of channels or be on DVD1 in a useful manner. To be candid, the multiplicity of channels is getting out of hand, but I don't have a clever solution to cite here.
     The reason I chose those strong words is because they represent what we in the field would be faced with. One does not wish to think about what trade press articles would say, so we work out these things within our group.
     Thanks,
     Joe D.

On 15/05/2014 12:04, Olaf Kirch wrote:
> Hi Joe,
>
> On Thursday 15 May 2014 09:36:38 Joe Doupnik wrote:
>>       Without having heard Matthias' presentation on the topic, the 
>> appearance at present is this is hostage taking. As we all know,
>>   PHP is a central component of building production servers. Chasing
>>   down -devel RPMs is awkward enough, now core material is being
>>   placed behind locked doors. Might someone offer a brief
>>   explanation of why this approach is being taken?
> "Hostage taking" and "locked door" are somewhat strong words... and I 
> hope you'll come to a different conclusion once we're talking about 
> the facts behind these changes.
>
> In a nutshell, SLES faces a dilemma with fast moving technologies.
> SLES releases are in the market for a very long time. Customers using 
> SLES expect a high level of stability in everything, including APIs.
> Now, API stability is definitely not one of the focus areas of the 
> people creating Web development frameworks. This includes php, ruby on 
> rails, you name it.
>
> With SLES, we could definitely take the approach of companies selling
> pharmaceuticals: "Bayer Froozle fights migraine, except when you do 
> this or that or something else, and by the way if you're unlucky, it 
> might make your hair fall out, cause your ears to grown like balloons 
> and your nose to turn green, ..." Just like that, we could say "In 
> SLES, we keep all APIs stable, except for <insert longish list>, and 
> we provide full support for everything, except for <insert another
> list>."
>
> In some weird coordinate system, this might be considered customer 
> friendly, but in most it's not.
>
> In the past, we have had a very hard time to upgrade components such 
> as php. Not really for technical reasons, but because of such 
> expectations on the life cycle. So what we are going to do is to 
> create several modules (aka channels) which will be free of charge to 
> SLE customers. These modules will hold collections of related 
> packages, and communicate a clear life cycle and support statement for 
> each module.
>
> You discovered the drawback of the module concept. It's easy to miss.
> On the other hand, you receive a strong benefit - which is a regular 
> refresh of the code base for components such as php, which was not 
> possible before.
>
> One of these modules will be targeted at Web Development, and contain 
> PHP.
>
> Regards,
> Olaf

_______________________________________________
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>


From rbrown at suse.de  Thu May 15 07:37:33 2014
From: rbrown at suse.de (Richard Brown)
Date: Thu, 15 May 2014 15:37:33 +0200
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <793d4b13bcf34209be5e668b8a512864@LGNMSXA01.prod.bk.dfs>
References: <20140514153539.GC11257@sgi.com>
	<20140514211427.GA5102@suse.com>	<53746E86.20401@netlab1.net>
	<201405151304.26509.okir@suse.de> <5374A231.6080108@netlab1.net>
	<793d4b13bcf34209be5e668b8a512864@LGNMSXA01.prod.bk.dfs>
Message-ID: <1400161053.24945.10.camel@ibrokeit.suse.de>

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)
-------------------------------------------------------------------



From S.M.Flood at ucs.cam.ac.uk  Thu May 15 07:47:25 2014
From: S.M.Flood at ucs.cam.ac.uk (Simon Flood)
Date: Thu, 15 May 2014 14:47:25 +0100
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <793d4b13bcf34209be5e668b8a512864@LGNMSXA01.prod.bk.dfs>
References: <20140514153539.GC11257@sgi.com>	<20140514211427.GA5102@suse.com>	<53746E86.20401@netlab1.net>	<201405151304.26509.okir@suse.de>
	<5374A231.6080108@netlab1.net>
	<793d4b13bcf34209be5e668b8a512864@LGNMSXA01.prod.bk.dfs>
Message-ID: <5374C56D.3050509@ucs.cam.ac.uk>

On 15/05/2014 13:23, Pieter Hollants wrote:

> Otherwise, as suggested, SUSE should make sure to create a addon ISO as well. You can perfectly offer that ISO download subject to the same support lifecycle statements as the online repo. Maybe a SLEWEB addon as for HA.

If PHP et al are not going to be reinstated back into the regular SLES 
ISO then I want one SLE(S) add-on ISO covering all modules not one ISO 
per module (as SLEWEB suggests).

Whilst the servers I build do have network access from the start (they 
PXE boot then install via AutoYaST) they don't all register against 
NCC/SCC or even SMT. If I want to build a server with PHP (for example) 
I want to install it with PHP not install it, then have to register it 
to then install PHP. Oh and then update it so it sounds like I'll have 
an additional step. Modules may be better for SUSE (forcing me to 
register) but not better for me.

 From the little information on modules leaking here I guess I'm not 
understanding the need for them - before SLE12 there was a fixed version 
of each package (sometimes two - think php and php53) on the release 
media with updates online via Updates repo or download from Patch 
Finder. If someone wants a (newer) version not available via media or 
updates then they can build from source or turn to OBS. Is that where 
modules are aimed?

Simon
-- 
Simon Flood
Senior Systems Specialist
University of Cambridge
United Kingdom

Novell/SUSE/NetIQ Knowledge Partner

From wendy at cray.com  Thu May 15 07:58:36 2014
From: wendy at cray.com (Wendy Palm)
Date: Thu, 15 May 2014 13:58:36 +0000
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <1400161053.24945.10.camel@ibrokeit.suse.de>
References: <20140514153539.GC11257@sgi.com>
	<20140514211427.GA5102@suse.com>	<53746E86.20401@netlab1.net>
	<201405151304.26509.okir@suse.de> <5374A231.6080108@netlab1.net>
	<793d4b13bcf34209be5e668b8a512864@LGNMSXA01.prod.bk.dfs>
	<1400161053.24945.10.camel@ibrokeit.suse.de>
Message-ID: <D5048769A89C5C40BAC8CD7E108BF5E824045DF2@CFWEX01.americas.cray.com>

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

From pieter.hollants at dfs.de  Thu May 15 08:19:26 2014
From: pieter.hollants at dfs.de (Pieter Hollants)
Date: Thu, 15 May 2014 14:19:26 +0000
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <D5048769A89C5C40BAC8CD7E108BF5E824045DF2@CFWEX01.americas.cray.com>
References: <20140514153539.GC11257@sgi.com>
	<20140514211427.GA5102@suse.com>	<53746E86.20401@netlab1.net>
	<201405151304.26509.okir@suse.de> <5374A231.6080108@netlab1.net>
	<793d4b13bcf34209be5e668b8a512864@LGNMSXA01.prod.bk.dfs>
	<1400161053.24945.10.camel@ibrokeit.suse.de>
	<D5048769A89C5C40BAC8CD7E108BF5E824045DF2@CFWEX01.americas.cray.com>
Message-ID: <b3b6c5ee2bbf477fb03173b9457fb27d@LGNMSXA01.prod.bk.dfs>

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>


From rbrown at suse.de  Thu May 15 10:13:07 2014
From: rbrown at suse.de (Richard Brown)
Date: Thu, 15 May 2014 18:13:07 +0200
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <b3b6c5ee2bbf477fb03173b9457fb27d@LGNMSXA01.prod.bk.dfs>
References: <20140514153539.GC11257@sgi.com>
	<20140514211427.GA5102@suse.com>	<53746E86.20401@netlab1.net>
	<201405151304.26509.okir@suse.de> <5374A231.6080108@netlab1.net>
	<793d4b13bcf34209be5e668b8a512864@LGNMSXA01.prod.bk.dfs>
	<1400161053.24945.10.camel@ibrokeit.suse.de>
	<D5048769A89C5C40BAC8CD7E108BF5E824045DF2@CFWEX01.americas.cray.com>
	<b3b6c5ee2bbf477fb03173b9457fb27d@LGNMSXA01.prod.bk.dfs>
Message-ID: <1400170387.24945.16.camel@ibrokeit.suse.de>

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>
> 


-- 
-------------------------------------------------------------------
  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)
-------------------------------------------------------------------



From rbrown at suse.de  Thu May 15 10:34:39 2014
From: rbrown at suse.de (Richard Brown)
Date: Thu, 15 May 2014 18:34:39 +0200
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <5374C56D.3050509@ucs.cam.ac.uk>
References: <20140514153539.GC11257@sgi.com>
	<20140514211427.GA5102@suse.com>	<53746E86.20401@netlab1.net>
	<201405151304.26509.okir@suse.de> <5374A231.6080108@netlab1.net>
	<793d4b13bcf34209be5e668b8a512864@LGNMSXA01.prod.bk.dfs>
	<5374C56D.3050509@ucs.cam.ac.uk>
Message-ID: <1400171679.24945.28.camel@ibrokeit.suse.de>

On Thu, 2014-05-15 at 14:47 +0100, Simon Flood wrote:
>  From the little information on modules leaking here I guess I'm not 
> understanding the need for them - before SLE12 there was a fixed
> version 
> of each package (sometimes two - think php and php53) on the release 
> media with updates online via Updates repo or download from Patch 
> Finder. If someone wants a (newer) version not available via media or 
> updates then they can build from source or turn to OBS. Is that where 
> modules are aimed?

Hi Simon,

I think the intention is to stop the need for users to build from source
or turn to OBS - both of these are going to result in a situation when
you're running untested software that potentially could cause issues and
that is hard/impossible to support.

Having Modules as repositories with their own release & support schedule
(separate from SLE) gives SUSE a way of delivering current versions of
PHP and other scripting packages in a supportable way is meant to be an
improvement on the past where these quickly moving software stacks were
all but impossible to support in a timely manner

Best Wishes,
- Richard
-- 
-------------------------------------------------------------------
  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)
-------------------------------------------------------------------



From jrd at netlab1.net  Thu May 15 10:38:30 2014
From: jrd at netlab1.net (Joe Doupnik)
Date: Thu, 15 May 2014 17:38:30 +0100
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <1400170387.24945.16.camel@ibrokeit.suse.de>
References: <20140514153539.GC11257@sgi.com>	<20140514211427.GA5102@suse.com>	<53746E86.20401@netlab1.net>	<201405151304.26509.okir@suse.de>
	<5374A231.6080108@netlab1.net>	<793d4b13bcf34209be5e668b8a512864@LGNMSXA01.prod.bk.dfs>	<1400161053.24945.10.camel@ibrokeit.suse.de>	<D5048769A89C5C40BAC8CD7E108BF5E824045DF2@CFWEX01.americas.cray.com>	<b3b6c5ee2bbf477fb03173b9457fb27d@LGNMSXA01.prod.bk.dfs>
	<1400170387.24945.16.camel@ibrokeit.suse.de>
Message-ID: <5374ED86.7090703@netlab1.net>

     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>
>>
>


From tee at sgi.com  Thu May 15 12:03:40 2014
From: tee at sgi.com (Tony Ernst)
Date: Thu, 15 May 2014 13:03:40 -0500
Subject: [sles-beta] Beta6 on EFI
In-Reply-To: <1400143423.2593.7.camel@par-r81vxc7.par.novell.com>
References: <20140514205635.GK11257@sgi.com>
	<1400143423.2593.7.camel@par-r81vxc7.par.novell.com>
Message-ID: <20140515180340.GO11257@sgi.com>

On Thu, May 15, 2014 at 10:43:43AM +0200, Frederic Crozat wrote:
> Le mercredi 14 mai 2014 ? 15:56 -0500, Tony Ernst a ?crit :
> > Is anyone else able to get the beta6 DVD to boot on a x86_64 EFI system?
> > It won't boot on ours.
> 
> Please open a SR with more details on the system tested and if Secure
> Boot was involved or not. You might also want to test with dumping the
> ISO image on an usb stick and boot from it.

We'll look into it a little more before opening a bug. I just wanted 
to see if this was a general problem or not. 

Thanks,
Tony

-- 
Tony Ernst
Linux System Software
SGI
tee at sgi.com


From jreidinger at suse.com  Fri May 16 01:42:33 2014
From: jreidinger at suse.com (Josef Reidinger)
Date: Fri, 16 May 2014 09:42:33 +0200
Subject: [sles-beta] SLES12 x86_64 Beta6 5min waiting time upon
 initializing software manager, YaST installer
In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F99851F@HXMB12.pnet.ch>
References: <40637DBB36AF3941B243A286A432CA0B0F99851F@HXMB12.pnet.ch>
Message-ID: <20140516094233.72fbbb53@dhcp150.suse.cz>

On Fri, 16 May 2014 07:34:34 +0000
<urs.frey at post.ch> wrote:

> Hi
> 
> Coming back on the issue with SLES12 x86_64 Beta6.
> When installing, either from DVD iso, or using autoyast, every time
> YaST is waiting for 5min on topic "Initializing Software Manager".
> All my servers are behind a firewall, no internet access possible.
> Network is configured, DNS working, else I could not access my
> internal SLES repository on the SMT. I am working in a fixed server
> address environment. SLES11-SP3 has no waiting time at all, SLES12
> also had no waiting time until Beta5
> 
> I remember having seen somewhere that curl has a timeout of 5min.
> 
> When bringing the idea of additional product channels in context of
> the above isse, I can imagine, that something new in the YaST
> installer code is trying to connect a SUSE repository over the
> internet. The 5minutes waiting time is there either when installing
> manually from the SLE-12-Server-DVD ISO and also when using http
> network installation with autoyast The 5 minutes waiting time is
> there on every kind of server I use, HP Proliant BL460c-Gen8 with
> 128GB RAM, DL380G7 with 48GB RAM, VMware with only 2GB RAM etc.
> 
> Waiting 5 minutes on every installation of SLES12 is a real NOGO for
> me.
> 
> So please review this new code in YaST installer and bring back the
> fast and smooth installation.
> 
> 

Hi,
it would be great if you can report it together with yast logs, so we
can check where it spend so much time. Maybe it is in SLP discovery or
some other features. We do not see such slow down, so we need
investigate your logs, why it take so much time.

Josef



> Thank you
> 
> Best regards
> 
> Urs Frey
> Post CH AG
> Informationstechnologie
> IT Betrieb
> Webergutstrasse 12
> 3030 Bern (Zollikofen)
> Telefon : ++41 (0)58 338 58 70
> FAX     : ++41 (0)58 667 30 07
> E-Mail:   urs.frey at post.ch<mailto:urs.frey at post.ch>
> 
> 
> 


From urs.frey at post.ch  Fri May 16 02:57:24 2014
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Fri, 16 May 2014 08:57:24 +0000
Subject: [sles-beta] SLES12 x86_64 Beta6 5min waiting time upon
 initializing software manager, YaST installer
In-Reply-To: <20140516094233.72fbbb53@dhcp150.suse.cz>
References: <40637DBB36AF3941B243A286A432CA0B0F99851F@HXMB12.pnet.ch>
	<20140516094233.72fbbb53@dhcp150.suse.cz>
Message-ID: <40637DBB36AF3941B243A286A432CA0B0F99855D@HXMB12.pnet.ch>

Hi Josef

I just opened a Service Request on this issue providing supportconfig output and also all YaST logs collected using save_y2logs. y2log-LNOlEf.tar.gz 
I booted the server using y2debug=1 to increase yast verbosity.

SUMMARY OF SR # 10892922951 
  * SR Severity Level: Medium  
  * SR Brief Description: SLES12 Beta6 x86_64 YaST installer waiting 5min in Initalizing Software Manager

Thank you very much for your help
Best regards

Urs Frey????????????????????????????????????????????? 
Post CH AG
Informationstechnologie
IT Betrieb 
Webergutstrasse 12 
3030 Bern (Zollikofen) 
Telefon : ++41 (0)58 338 58 70 
FAX???? : ++41 (0)58 667 30 07 
E-Mail:?? urs.frey at post.ch


-----Urspr?ngliche Nachricht-----
Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Josef Reidinger
Gesendet: Friday, May 16, 2014 9:43 AM
An: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] SLES12 x86_64 Beta6 5min waiting time upon initializing software manager, YaST installer

On Fri, 16 May 2014 07:34:34 +0000
<urs.frey at post.ch> wrote:

> Hi
> 
> Coming back on the issue with SLES12 x86_64 Beta6.
> When installing, either from DVD iso, or using autoyast, every time
> YaST is waiting for 5min on topic "Initializing Software Manager".
> All my servers are behind a firewall, no internet access possible.
> Network is configured, DNS working, else I could not access my
> internal SLES repository on the SMT. I am working in a fixed server
> address environment. SLES11-SP3 has no waiting time at all, SLES12
> also had no waiting time until Beta5
> 
> I remember having seen somewhere that curl has a timeout of 5min.
> 
> When bringing the idea of additional product channels in context of
> the above isse, I can imagine, that something new in the YaST
> installer code is trying to connect a SUSE repository over the
> internet. The 5minutes waiting time is there either when installing
> manually from the SLE-12-Server-DVD ISO and also when using http
> network installation with autoyast The 5 minutes waiting time is
> there on every kind of server I use, HP Proliant BL460c-Gen8 with
> 128GB RAM, DL380G7 with 48GB RAM, VMware with only 2GB RAM etc.
> 
> Waiting 5 minutes on every installation of SLES12 is a real NOGO for
> me.
> 
> So please review this new code in YaST installer and bring back the
> fast and smooth installation.
> 
> 

Hi,
it would be great if you can report it together with yast logs, so we
can check where it spend so much time. Maybe it is in SLP discovery or
some other features. We do not see such slow down, so we need
investigate your logs, why it take so much time.

Josef



> Thank you
> 
> Best regards
> 
> Urs Frey
> Post CH AG
> Informationstechnologie
> IT Betrieb
> Webergutstrasse 12
> 3030 Bern (Zollikofen)
> Telefon : ++41 (0)58 338 58 70
> FAX     : ++41 (0)58 667 30 07
> E-Mail:   urs.frey at post.ch<mailto:urs.frey at post.ch>
> 
> 
> 

_______________________________________________
sles-beta mailing list
sles-beta at lists.suse.com
http://lists.suse.com/mailman/listinfo/sles-beta

From urs.frey at post.ch  Fri May 16 03:03:41 2014
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Fri, 16 May 2014 09:03:41 +0000
Subject: [sles-beta] SLES12 x86_64 Beta6 5min waiting time upon
 initializing software manager, YaST installer
In-Reply-To: <20140516094233.72fbbb53@dhcp150.suse.cz>
References: <40637DBB36AF3941B243A286A432CA0B0F99851F@HXMB12.pnet.ch>
	<20140516094233.72fbbb53@dhcp150.suse.cz>
Message-ID: <40637DBB36AF3941B243A286A432CA0B0F998572@HXMB12.pnet.ch>

Hi 
Just when browsing the yast2 logs from the installation and 5min waiting time I can see this entry

2014-05-16 06:09:14 <0> h063uz(3730) [bash] ShellCommand.cc(shellcommand):31 shellcommand start
2014-05-16 06:11:21 <0> h063uz(3730) [bash] ShellCommand.cc(shellcommand):197 shellcommand end
2014-05-16 06:11:21 <1> h063uz(3730) [Ruby] clients/inst_download_release_notes.rb:111 Downloading release notes: /usr/bin/curl --location --verbose --fail --
max-time 300   'https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/RELEASE-NOTES.en.rtf' --output '/tmp/YaST2-03730-kp1K67/relnotes' > '/var/log/YaST2/curl
_log' 2>&1 returned 7
2014-05-16 06:11:21 <1> h063uz(3730) [Ruby] clients/inst_download_release_notes.rb:97 URL: https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/RELEASE-NOTES
.en.rtf

AND again here
2014-05-16 06:11:21 <0> h063uz(3730) [agent-system] ../../libscr/src/include/scr/Y2AgentComponent.h(evaluate):94 evaluate (`Execute (.bash, "/usr/bin/curl --l
ocation --verbose --fail --max-time 300   'https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/RELEASE-NOTES.en.rtf' --output '/tmp/YaST2-03730-kp1K67/relno
tes' > '/var/log/YaST2/curl_log' 2>&1"))
2014-05-16 06:11:21 <0> h063uz(3730) [agent-system] ../../libscr/src/include/scr/Y2AgentComponent.h(evaluate):99 Going to evaluate `Execute (.bash, "/usr/bin/
curl --location --verbose --fail --max-time 300   'https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/RELEASE-NOTES.en.rtf' --output '/tmp/YaST2-03730-kp1K
67/relnotes' > '/var/log/YaST2/curl_log' 2>&1")
2014-05-16 06:11:21 <0> h063uz(3730) [agent-system] ../../libscr/src/include/scr/Y2AgentComponent.h(evaluate):120 After code evaluation: `Execute (.bash, "/us
r/bin/curl --location --verbose --fail --max-time 300   'https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/RELEASE-NOTES.en.rtf' --output '/tmp/YaST2-0373
0-kp1K67/relnotes' > '/var/log/YaST2/curl_log' 2>&1")
2014-05-16 06:11:21 <0> h063uz(3730) [agent-system] ../../libscr/src/include/scr/Y2AgentComponent.h(evaluate):141 Execute, arg size is 2
2014-05-16 06:11:21 <0> h063uz(3730) [agent-system] SystemAgent.cc(Execute):902 Execute (.bash)
2014-05-16 06:11:21 <0> h063uz(3730) [bash] ShellCommand.cc(shellcommand):31 shellcommand start
2014-05-16 06:13:29 <0> h063uz(3730) [bash] ShellCommand.cc(shellcommand):197 shellcommand end
2014-05-16 06:13:29 <1> h063uz(3730) [Ruby] clients/inst_download_release_notes.rb:111 Downloading release notes: /usr/bin/curl --location --verbose --fail --
max-time 300   'https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/RELEASE-NOTES.en.rtf' --output '/tmp/YaST2-03730-kp1K67/relnotes' > '/var/log/YaST2/curl
_log' 2>&1 returned 7
2014-05-16 06:13:29 <1> h063uz(3730) [Interpreter] clients/inst_system_analysis.rb:352 Called YaST client returned.

So somewhere YaST installer tries to download the release notes via https://www.suse.com
Of course this does not work behind firewalls
And as can be seen above there is twice a waiting time of 2min until I get error code 7

Best regards

Urs Frey????????????????????????????????????????????? 
Post CH AG
Informationstechnologie
IT Betrieb 
Webergutstrasse 12 
3030 Bern (Zollikofen) 
Telefon : ++41 (0)58 338 58 70 
FAX???? : ++41 (0)58 667 30 07 
E-Mail:?? urs.frey at post.ch


-----Urspr?ngliche Nachricht-----
Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Josef Reidinger
Gesendet: Friday, May 16, 2014 9:43 AM
An: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] SLES12 x86_64 Beta6 5min waiting time upon initializing software manager, YaST installer

On Fri, 16 May 2014 07:34:34 +0000
<urs.frey at post.ch> wrote:

> Hi
> 
> Coming back on the issue with SLES12 x86_64 Beta6.
> When installing, either from DVD iso, or using autoyast, every time
> YaST is waiting for 5min on topic "Initializing Software Manager".
> All my servers are behind a firewall, no internet access possible.
> Network is configured, DNS working, else I could not access my
> internal SLES repository on the SMT. I am working in a fixed server
> address environment. SLES11-SP3 has no waiting time at all, SLES12
> also had no waiting time until Beta5
> 
> I remember having seen somewhere that curl has a timeout of 5min.
> 
> When bringing the idea of additional product channels in context of
> the above isse, I can imagine, that something new in the YaST
> installer code is trying to connect a SUSE repository over the
> internet. The 5minutes waiting time is there either when installing
> manually from the SLE-12-Server-DVD ISO and also when using http
> network installation with autoyast The 5 minutes waiting time is
> there on every kind of server I use, HP Proliant BL460c-Gen8 with
> 128GB RAM, DL380G7 with 48GB RAM, VMware with only 2GB RAM etc.
> 
> Waiting 5 minutes on every installation of SLES12 is a real NOGO for
> me.
> 
> So please review this new code in YaST installer and bring back the
> fast and smooth installation.
> 
> 

Hi,
it would be great if you can report it together with yast logs, so we
can check where it spend so much time. Maybe it is in SLP discovery or
some other features. We do not see such slow down, so we need
investigate your logs, why it take so much time.

Josef



> Thank you
> 
> Best regards
> 
> Urs Frey
> Post CH AG
> Informationstechnologie
> IT Betrieb
> Webergutstrasse 12
> 3030 Bern (Zollikofen)
> Telefon : ++41 (0)58 338 58 70
> FAX     : ++41 (0)58 667 30 07
> E-Mail:   urs.frey at post.ch<mailto:urs.frey at post.ch>
> 
> 
> 

_______________________________________________
sles-beta mailing list
sles-beta at lists.suse.com
http://lists.suse.com/mailman/listinfo/sles-beta

From jsmeix at suse.de  Fri May 16 03:08:29 2014
From: jsmeix at suse.de (Johannes Meixner)
Date: Fri, 16 May 2014 11:08:29 +0200 (CEST)
Subject: [sles-beta] SLES12 x86_64 Beta6 5min waiting time upon
 initializing software manager, YaST installer
In-Reply-To: <20140516094233.72fbbb53@dhcp150.suse.cz>
References: <40637DBB36AF3941B243A286A432CA0B0F99851F@HXMB12.pnet.ch>
	<20140516094233.72fbbb53@dhcp150.suse.cz>
Message-ID: <alpine.LNX.2.00.1405161057250.4374@nelson.suse.de>


Hello,

On May 16 09:42 Josef Reidinger wrote (excerpt):
> On Fri, 16 May 2014 07:34:34 +0000
> <urs.frey at post.ch> wrote:
...
>> When installing, either from DVD iso, or using autoyast, every time
>> YaST is waiting for 5min on topic "Initializing Software Manager".
...
>> SLES12 also had no waiting time until Beta5
...
> it would be great if you can report it together with yast logs, so we
> can check where it spend so much time. Maybe it is in SLP discovery or
> some other features. We do not see such slow down, so we need
> investigate your logs, why it take so much time.

As far as I know Urs Frey cannot submit himself a new bug for SLE12.

As an usability experiment I submitted right now
https://bugzilla.novell.com/show_bug.cgi?id=878265
with NEEDINFO from "urs.frey at post.ch".

Regardless that "urs.frey at post.ch" is a vaild bugzilla user,
with only NEEDINFO from "urs.frey at post.ch" that mail address
was excluded by bugzilla (for me this is a bug in bugzilla).

Therefore I also added "urs.frey at post.ch" to CC of this bug
and now - voila! - bugzilla even sent a mail to that address.

Background information:

I think it is much easier for developers (like me and Josef Reidinger)
when we can work by using bugzilla (as we do all the time)
instead of "SR"s which are rather "obscure" for us and as a result
by working via bugzilla it could be faster to get issues fixed.


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany
HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer

From jsmeix at suse.de  Fri May 16 03:13:05 2014
From: jsmeix at suse.de (Johannes Meixner)
Date: Fri, 16 May 2014 11:13:05 +0200 (CEST)
Subject: [sles-beta] SLES12 x86_64 Beta6 5min waiting time upon
 initializing software manager, YaST installer
In-Reply-To: <alpine.LNX.2.00.1405161057250.4374@nelson.suse.de>
References: <40637DBB36AF3941B243A286A432CA0B0F99851F@HXMB12.pnet.ch>
	<20140516094233.72fbbb53@dhcp150.suse.cz>
	<alpine.LNX.2.00.1405161057250.4374@nelson.suse.de>
Message-ID: <alpine.LNX.2.00.1405161109580.4541@nelson.suse.de>


Hello,

On May 16 11:08 Johannes Meixner wrote (excerpt):
> I think it is much easier for developers (like me and Josef Reidinger)
> when we can work by using bugzilla (as we do all the time)
> instead of "SR"s which are rather "obscure" for us and as a result
> by working via bugzilla it could be faster to get issues fixed.

I had submitted the new bug on 2014-05-16 10:56:30 CEST and
we got the needed information on 2014-05-16 11:07:41 CEST
i.e. in less than 15 minutes!

q.e.d.

Have a nice weekend!

Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany
HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer

From Christian.Woertz at dachser.com  Fri May 16 03:24:41 2014
From: Christian.Woertz at dachser.com (Christian.Woertz at dachser.com)
Date: Fri, 16 May 2014 11:24:41 +0200
Subject: [sles-beta] Antwort: Re:  php disappeared in beta6?
In-Reply-To: <20140515110615.GB9453@suse.com>
References: <20140514153539.GC11257@sgi.com>	<AAD7066EC17A5541BF5145CD44BEFA72E68EAB70@EX10MBN01.ua-net.ua.edu>
	<20140514211427.GA5102@suse.com>	<4c3641b0b0a84805b7fb10afe11b1cb2@LGNMSXA01.prod.bk.dfs>
	<40637DBB36AF3941B243A286A432CA0B0F9982D7@HXMB12.pnet.ch>
	<20140515110615.GB9453@suse.com>
Message-ID: <OF115EC1CF.ABCAEFB2-ONC1257CDA.0032B80D-C1257CDA.0033B2E3@dachser.com>

Hello Matthias,

thanks for the information regarding SMT, but as we use ZCM for
installation/updates, what is the time line there for the module
integration?

Mit freundlichen Gr??en - best regards

Christian W?rtz



Von:	"Matthias G. Eckermann" <mge at suse.com>
An:	urs.frey at post.ch, pieter.hollants at dfs.de,
            allen at ua.edu, sles-beta at lists.suse.com, tee at sgi.com
Datum:	15.05.2014 13:07
Betreff:	Re: [sles-beta] php disappeared in beta6?
Gesendet von:	sles-beta-bounces at lists.suse.com


<snip>

SMT 11 SP3 will (get an update) and be able to mirror
SUSE Linux Enterprise 12 related repositories, and
yes, this certainly includes the Modules.

<snip>
--
Matthias G. Eckermann     Senior Product Manager   SUSE? Linux
Enterprise
Phone: +49 30 44315731    Mobile: +49 179 2949448    E-Mail:
mge at suse.com
SUSE LINUX Products GmbH  Maxfeldstra?e 5          90409 N?rnberg
Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG
N?rnberg)
_______________________________________________
sles-beta mailing list
sles-beta at lists.suse.com
http://lists.suse.com/mailman/listinfo/sles-beta

From mge at suse.com  Fri May 16 03:40:01 2014
From: mge at suse.com (Matthias G. Eckermann)
Date: Fri, 16 May 2014 11:40:01 +0200
Subject: [sles-beta] SLES12 x86_64 Beta6 snapper not working after
 autoyast installation, no it works if you know how
In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9985AC@HXMB12.pnet.ch>
References: <40637DBB36AF3941B243A286A432CA0B0F9985AC@HXMB12.pnet.ch>
Message-ID: <20140516094001.GC1723@suse.com>

Hello Urs,

please open two SRs and ask our team to include
mge at suse.com in the internal bugzillas (as you all
know, Snapshot/Rollback with btrfs and snapper is
the topic I am driving with extra energy:-).

On 2014-05-16 T 09:21 +0000 urs.frey at post.ch wrote:
> Hi
> 
> Don't know how many of you are tinkering on btrfs and autoyast.
> Btrfs is something really good. On the other hand, the need for automated deployment is a basic need.
> So let me share some experience here (those who already know the stuff may smile and exit here ;-)
> 
> When using yast clone_system, the resulting autoinst.xml is far too much.
> Reporting tags, sysvinit runlevel tags containing service definitions and systemd services-manager tags get mixed up and do bite each other, so at first try your installation does get stuck and autoyast configurations are somewhat corrupted.
> In the generated autoinst.xml one finds also many entries called
>    <listentry>.snapshots</listentry>
>    <listentry>.snapshots/1/snapshot</listentry>
>    <listentry>.snapshots/2/snapshot</listentry>
>    <listentry>.snapshots/3/snapshot</listentry>

> These entries are not needed, when setting up from scratch and doing a complete new initialization .
> Yast clone_system does register too much here.

First SR: exclude Snapshots

> Best way is to reduce and try using ext4 or xfs first.
> When the installation with xfs works, introduce btrfs partitioning, btrfs related packages, snapper related package and suse_btrfs tag in bootloader in the autoinst.xml profile.
> 
>       <package>grub2-snapper-plugin</package>
>       <package>libbtrfs0</package>
>       <package>libsnapper2</package>
>       <package>snapper</package>
>       <package>snapper-zypp-plugin</package>
>       <package>yast2-snapper</package>
> 
>   <bootloader>
>     <global>
>       <suse_btrfs>true</suse_btrfs>
>     </global>
>     <loader_type>grub2</loader_type>
> 
> NEVER do a sysconfig entry in autoyast filling out the parameter SNAPPER_CONFIGS=root in /etc/sysconfig/snapper.
> This will result in snapper thinking root config is already done and refusing to work properly.
> 
> So after completion of the autoyast process at first login when you enter snapper list, you will get "unknown config"
> # snapper list
> Unknown config.
> 
> The magic behind is, that one has to create the first root configuration
> # snapper -c root create-config /
> - this will create the /.snapshots subvolume
> - and create the entry SNAPPER_CONFIGS=root in /etc/sysconfig/snapper
> - and also the file /etc/snapper/configs/root which will be used by cron.hourly and cron.daily to create snapshots.
> 
> Finally snapper list will show a short table with the first single snapshot.
> v03er9:~ # snapper list
> Type   | # | Pre # | Date | User | Cleanup | Description | Userdata
> -------+---+-------+------+------+---------+-------------+---------
> single | 0 |       |      | root |         | current     |
> v03er9:~ #
> 
> This snapper -c root create-config / can be placed in autoyast init-script
> 
> Unfortunately this initial configuration of snapper is not documented.
> At least I could not find a trace in the latest release of  book.sle.admin_en.pdf coming with Beta6.
> Source for the final click in my brain was this here http://superuser.com/questions/584245/how-do-i-reinstall-enable-snapper

Second SR: the configuration for btrfs root should be
cloned easily.

Thanks for finding!

so logn -
	MgE


> Best regards
> 
> 
> Urs Frey
> Post CH AG
> Informationstechnologie
> IT Betrieb
> Webergutstrasse 12
> 3030 Bern (Zollikofen)
> Telefon : ++41 (0)58 338 58 70
> FAX     : ++41 (0)58 667 30 07
> E-Mail:   urs.frey at post.ch<mailto:urs.frey at post.ch>
> 
> 
> 

> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta


-- 
Matthias G. Eckermann     Senior Product Manager   SUSE? Linux Enterprise
Phone: +49 30 44315731    Mobile: +49 179 2949448    E-Mail: mge at suse.com
SUSE LINUX Products GmbH  Maxfeldstra?e 5          90409 N?rnberg Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg)

From urs.frey at post.ch  Fri May 16 03:40:47 2014
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Fri, 16 May 2014 09:40:47 +0000
Subject: [sles-beta] SLES12 x86_64 Beta6 5min waiting time upon
 initializing software manager, YaST installer
In-Reply-To: <alpine.LNX.2.00.1405161109580.4541@nelson.suse.de>
References: <40637DBB36AF3941B243A286A432CA0B0F99851F@HXMB12.pnet.ch>
	<20140516094233.72fbbb53@dhcp150.suse.cz>
	<alpine.LNX.2.00.1405161057250.4374@nelson.suse.de>
	<alpine.LNX.2.00.1405161109580.4541@nelson.suse.de>
Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9985D4@HXMB12.pnet.ch>

Hello Johannes

Thank you very much! 
I mean this speed is what makes the difference to other OS -es!
Penguins are fast divers, they have to find their way around sea lions ;-)

And also this speed in response is what makes the difference in support quality: SUSE is TOP! 

Thank's again
Best regards

Urs Frey????????????????????????????????????????????? 
Post CH AG
Informationstechnologie
IT Betrieb 
Webergutstrasse 12 
3030 Bern (Zollikofen) 
Telefon : ++41 (0)58 338 58 70 
FAX???? : ++41 (0)58 667 30 07 
E-Mail:?? urs.frey at post.ch


-----Urspr?ngliche Nachricht-----
Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Johannes Meixner
Gesendet: Friday, May 16, 2014 11:13 AM
An: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] SLES12 x86_64 Beta6 5min waiting time upon initializing software manager, YaST installer


Hello,

On May 16 11:08 Johannes Meixner wrote (excerpt):
> I think it is much easier for developers (like me and Josef Reidinger)
> when we can work by using bugzilla (as we do all the time)
> instead of "SR"s which are rather "obscure" for us and as a result
> by working via bugzilla it could be faster to get issues fixed.

I had submitted the new bug on 2014-05-16 10:56:30 CEST and
we got the needed information on 2014-05-16 11:07:41 CEST
i.e. in less than 15 minutes!

q.e.d.

Have a nice weekend!

Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany
HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer
_______________________________________________
sles-beta mailing list
sles-beta at lists.suse.com
http://lists.suse.com/mailman/listinfo/sles-beta

From S.M.Flood at ucs.cam.ac.uk  Fri May 16 04:47:54 2014
From: S.M.Flood at ucs.cam.ac.uk (Simon Flood)
Date: Fri, 16 May 2014 11:47:54 +0100
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <1400171679.24945.28.camel@ibrokeit.suse.de>
References: <20140514153539.GC11257@sgi.com>	<20140514211427.GA5102@suse.com>	<53746E86.20401@netlab1.net>	<201405151304.26509.okir@suse.de>
	<5374A231.6080108@netlab1.net>	<793d4b13bcf34209be5e668b8a512864@LGNMSXA01.prod.bk.dfs>	<5374C56D.3050509@ucs.cam.ac.uk>
	<1400171679.24945.28.camel@ibrokeit.suse.de>
Message-ID: <5375ECDA.4070409@ucs.cam.ac.uk>

On 15/05/2014 17:34, Richard Brown wrote:

> I think the intention is to stop the need for users to build from source
> or turn to OBS - both of these are going to result in a situation when
> you're running untested software that potentially could cause issues and
> that is hard/impossible to support.

That might be SUSE's intention but I think they're going to achieve the 
opposite (drive more people to build from source and/or use OBS) when 
they find something missing ...

Either that or they'll skip using SLES altogether and go with another 
(enterprise) distro that has what they want.

> Having Modules as repositories with their own release & support schedule
> (separate from SLE) gives SUSE a way of delivering current versions of
> PHP and other scripting packages in a supportable way is meant to be an
> improvement on the past where these quickly moving software stacks were
> all but impossible to support in a timely manner

Currently anyone can check which packages are included with a version of 
SLE (SLES[1] or SLED[2], down to specific architecture and SP level) so 
I hope that will handle (i.e. correctly explain why) packages available 
via Modules. Otherwise people will use another distro.

What concerns me, without knowing all the details about Modules 
(obviously this thread has now brought a future topic to the table 
earlier than planned), is where SUSE will stop with Modules because you 
could say that all previously included (on media) packages could be 
considered the same as PHP so only available via Module(s). Perhaps SUSE 
want to only ship mini ISOs that pull down all packages via Modules 
post-registration? [Note: don't do this!]

I'm certainly finding that I'm now using OBS more than before to provide 
newer versions of packages than included with SLES (i.e. 
freeradius-server) or packages missing (i.e. nfdump). When that's 
happening for "core" packages (and I consider PHP to be core) then I'll 
start looking at other distros as I'm sure my colleagues across the 
University also will.

Simon

[1] https://www.suse.com/products/server/technical-information/
[2] https://www.suse.com/products/desktop/technical-information/
-- 
Simon Flood
Senior Systems Specialist
University of Cambridge
United Kingdom

Novell/SUSE/NetIQ Knowledge Partner

From mge at suse.com  Fri May 16 05:43:49 2014
From: mge at suse.com (Matthias G. Eckermann)
Date: Fri, 16 May 2014 13:43:49 +0200
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <5375ECDA.4070409@ucs.cam.ac.uk>
References: <20140514153539.GC11257@sgi.com> <20140514211427.GA5102@suse.com>
	<53746E86.20401@netlab1.net> <201405151304.26509.okir@suse.de>
	<5374A231.6080108@netlab1.net>
	<793d4b13bcf34209be5e668b8a512864@LGNMSXA01.prod.bk.dfs>
	<5374C56D.3050509@ucs.cam.ac.uk>
	<1400171679.24945.28.camel@ibrokeit.suse.de>
	<5375ECDA.4070409@ucs.cam.ac.uk>
Message-ID: <20140516114349.GA5230@suse.com>

On 2014-05-16 T 11:47 +0100 Simon Flood wrote:
 
> I'm certainly finding that I'm now using OBS more than
> before to provide newer versions of packages than
> included with SLES (i.e.  freeradius-server) or
> packages missing (i.e. nfdump). When that's happening
> for "core" packages (and I consider PHP to be core)
> then I'll start looking at other distros as I'm sure
> my colleagues across the University also will.

I am afraid that you are contradicting yourself a bit:
if you are able to use OBS, you _are_ online, and thus
there is no reason to not use the Modules either from
SCC or from an SMT or SUSE Manager (both with the
appropriate repositories preloaded).

So long -
	MgE

-- 
Matthias G. Eckermann     Senior Product Manager   SUSE? Linux Enterprise
Phone: +49 30 44315731    Mobile: +49 179 2949448    E-Mail: mge at suse.com
SUSE LINUX Products GmbH  Maxfeldstra?e 5          90409 N?rnberg Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg)

From urs.frey at post.ch  Fri May 16 06:50:08 2014
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Fri, 16 May 2014 12:50:08 +0000
Subject: [sles-beta] SLES12 x86_64 Beta6 snapper not working after
 autoyast installation, no it works if you know how
In-Reply-To: <20140516094001.GC1723@suse.com>
References: <40637DBB36AF3941B243A286A432CA0B0F9985AC@HXMB12.pnet.ch>
	<20140516094001.GC1723@suse.com>
Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9986FF@HXMB12.pnet.ch>

Hi Matthias
First Service Request opened, issue btrfs snapshot should not be included in autoinst.xml

SUMMARY OF SR # 10892923191 
  * SR Severity Level: Medium  
  * SR Brief Description: SLES12 Beta6 x86_64 yast clone_system collects falsely btrfs snapshot data

Best regards

Urs Frey????????????????????????????????????????????? 
Post CH AG
Informationstechnologie
IT Betrieb 
Webergutstrasse 12 
3030 Bern (Zollikofen) 
Telefon : ++41 (0)58 338 58 70 
FAX???? : ++41 (0)58 667 30 07 
E-Mail:?? urs.frey at post.ch


-----Urspr?ngliche Nachricht-----
Von: Matthias G. Eckermann [mailto:mge at suse.com] 
Gesendet: Friday, May 16, 2014 11:40 AM
An: Frey Urs, IT222; sles-beta at lists.suse.com
Betreff: Re: [sles-beta] SLES12 x86_64 Beta6 snapper not working after autoyast installation, no it works if you know how

Hello Urs,

please open two SRs and ask our team to include
mge at suse.com in the internal bugzillas (as you all
know, Snapshot/Rollback with btrfs and snapper is
the topic I am driving with extra energy:-).

On 2014-05-16 T 09:21 +0000 urs.frey at post.ch wrote:
> Hi
> 
> Don't know how many of you are tinkering on btrfs and autoyast.
> Btrfs is something really good. On the other hand, the need for automated deployment is a basic need.
> So let me share some experience here (those who already know the stuff may smile and exit here ;-)
> 
> When using yast clone_system, the resulting autoinst.xml is far too much.
> Reporting tags, sysvinit runlevel tags containing service definitions and systemd services-manager tags get mixed up and do bite each other, so at first try your installation does get stuck and autoyast configurations are somewhat corrupted.
> In the generated autoinst.xml one finds also many entries called
>    <listentry>.snapshots</listentry>
>    <listentry>.snapshots/1/snapshot</listentry>
>    <listentry>.snapshots/2/snapshot</listentry>
>    <listentry>.snapshots/3/snapshot</listentry>

> These entries are not needed, when setting up from scratch and doing a complete new initialization .
> Yast clone_system does register too much here.

First SR: exclude Snapshots

> Best way is to reduce and try using ext4 or xfs first.
> When the installation with xfs works, introduce btrfs partitioning, btrfs related packages, snapper related package and suse_btrfs tag in bootloader in the autoinst.xml profile.
> 
>       <package>grub2-snapper-plugin</package>
>       <package>libbtrfs0</package>
>       <package>libsnapper2</package>
>       <package>snapper</package>
>       <package>snapper-zypp-plugin</package>
>       <package>yast2-snapper</package>
> 
>   <bootloader>
>     <global>
>       <suse_btrfs>true</suse_btrfs>
>     </global>
>     <loader_type>grub2</loader_type>
> 
> NEVER do a sysconfig entry in autoyast filling out the parameter SNAPPER_CONFIGS=root in /etc/sysconfig/snapper.
> This will result in snapper thinking root config is already done and refusing to work properly.
> 
> So after completion of the autoyast process at first login when you enter snapper list, you will get "unknown config"
> # snapper list
> Unknown config.
> 
> The magic behind is, that one has to create the first root configuration
> # snapper -c root create-config /
> - this will create the /.snapshots subvolume
> - and create the entry SNAPPER_CONFIGS=root in /etc/sysconfig/snapper
> - and also the file /etc/snapper/configs/root which will be used by cron.hourly and cron.daily to create snapshots.
> 
> Finally snapper list will show a short table with the first single snapshot.
> v03er9:~ # snapper list
> Type   | # | Pre # | Date | User | Cleanup | Description | Userdata
> -------+---+-------+------+------+---------+-------------+---------
> single | 0 |       |      | root |         | current     |
> v03er9:~ #
> 
> This snapper -c root create-config / can be placed in autoyast init-script
> 
> Unfortunately this initial configuration of snapper is not documented.
> At least I could not find a trace in the latest release of  book.sle.admin_en.pdf coming with Beta6.
> Source for the final click in my brain was this here http://superuser.com/questions/584245/how-do-i-reinstall-enable-snapper

Second SR: the configuration for btrfs root should be
cloned easily.

Thanks for finding!

so logn -
	MgE


> Best regards
> 
> 
> Urs Frey
> Post CH AG
> Informationstechnologie
> IT Betrieb
> Webergutstrasse 12
> 3030 Bern (Zollikofen)
> Telefon : ++41 (0)58 338 58 70
> FAX     : ++41 (0)58 667 30 07
> E-Mail:   urs.frey at post.ch<mailto:urs.frey at post.ch>
> 
> 
> 

> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta


-- 
Matthias G. Eckermann     Senior Product Manager   SUSE? Linux Enterprise
Phone: +49 30 44315731    Mobile: +49 179 2949448    E-Mail: mge at suse.com
SUSE LINUX Products GmbH  Maxfeldstra?e 5          90409 N?rnberg Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg)

From S.M.Flood at ucs.cam.ac.uk  Fri May 16 07:11:48 2014
From: S.M.Flood at ucs.cam.ac.uk (Simon Flood)
Date: Fri, 16 May 2014 14:11:48 +0100
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <20140516114349.GA5230@suse.com>
References: <20140514153539.GC11257@sgi.com> <20140514211427.GA5102@suse.com>
	<53746E86.20401@netlab1.net> <201405151304.26509.okir@suse.de>
	<5374A231.6080108@netlab1.net>
	<793d4b13bcf34209be5e668b8a512864@LGNMSXA01.prod.bk.dfs>
	<5374C56D.3050509@ucs.cam.ac.uk>
	<1400171679.24945.28.camel@ibrokeit.suse.de>
	<5375ECDA.4070409@ucs.cam.ac.uk> <20140516114349.GA5230@suse.com>
Message-ID: <53760E94.9030601@ucs.cam.ac.uk>

On 16/05/2014 12:43, Matthias G. Eckermann wrote:

> I am afraid that you are contradicting yourself a bit:
> if you are able to use OBS, you _are_ online, and thus
> there is no reason to not use the Modules either from
> SCC or from an SMT or SUSE Manager (both with the
> appropriate repositories preloaded).

If that's the best response you (representing SUSE) can come up with 
then that concerns me greatly.

BTW I'm not the person who said they installed servers off-line - in an 
earlier response to this thread I said "Whilst the servers I build do 
have network access from the start (they PXE boot then install via 
AutoYaST) they don't all register against NCC/SCC or even SMT."

Simon
-- 
Simon Flood
Senior Systems Specialist
University of Cambridge
United Kingdom

Novell/SUSE/NetIQ Knowledge Partner

From allen at ua.edu  Fri May 16 09:08:48 2014
From: allen at ua.edu (Beddingfield, Allen)
Date: Fri, 16 May 2014 15:08:48 +0000
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <53760E94.9030601@ucs.cam.ac.uk>
References: <20140514153539.GC11257@sgi.com>
	<20140514211427.GA5102@suse.com>	<53746E86.20401@netlab1.net>
	<201405151304.26509.okir@suse.de>	<5374A231.6080108@netlab1.net>
	<793d4b13bcf34209be5e668b8a512864@LGNMSXA01.prod.bk.dfs>
	<5374C56D.3050509@ucs.cam.ac.uk>
	<1400171679.24945.28.camel@ibrokeit.suse.de>
	<5375ECDA.4070409@ucs.cam.ac.uk>
	<20140516114349.GA5230@suse.com>,<53760E94.9030601@ucs.cam.ac.uk>
Message-ID: <AAD7066EC17A5541BF5145CD44BEFA72E68ECE85@EX10MBN01.ua-net.ua.edu>

I agree with Simon here in being "concerned greatly".  While I can go out and build this package or that package in OBS, why should I have to?  I think that pushing anyone to use custom OBS packaging over what is included with the OS is going to be very counter productive in the long run.  I'm assuming that each of these "modules" will add an additional repository per-module?  If these are available as channels in SUSE Manager and SMT (or whatever replaces SMT), my technical needs will be met on this issue, and it will just be an annoyance to me.  However, for those with other requirements, it can be more of a problem.  
I can foresee a number of situations where this is going to be problematic.
1.  I occasionally get the request for someone who just wants to do a quick test of something on a Linux system.  In that case, I just clone the VM (we usually use VMware cloning to deploy VMs) from my template, and send them the info.  I don't bother with registering with SMT, SUSE Manager, etc... since they are just going to test something quickly and tell me to delete the VM.  That is all fine now, with SLES 11, but with SLES 12, PHP won't be available in this case, unless I register the VM, or register my template first, install it, and then unregister before prepping it to be a template.  In that situation, I would need multiple templates, since not every VM will need every module.
2.  As much as we may not like it, we still have the stubborn vendors out there who will say "we support exactly this patch level, and nothing more", and we have to firewall the hell out of the system to keep it secure.  Well, currently if that vendor says they support SLES 11 SP2 or RHEL 6.3, etc... that would mean that they support the exact patch level that shipped on the media.  Well, with a repo, who determines what version they will support?  In reality, over here in the U.S. where we constantly have to justify why we "can't just run Red Hat like everyone else and quit being difficult", they are just going to drop SLES support.

What is the answer?  I'm not sure...  we definitely need something better than the current situation.  The php5* packages (being 5.2.x) and php53 (being 5.3.x) on SLES 11 is problematic.  First of all, I've already got people wanting 5.5.x. Maybe a good compromise would be a snapshot at release time of the modules all on the install DVD, and an update repo gets added on registration?  Maybe a series of directories on the DVD that are added as repos at install-time, if one selects the particular module?  That would seem sensible to me.  It allows for offline installation from DVD, and continued implementation of this new direction.
 
There are many questions to be answered here by someone from SUSE:

1.  Can someone give us details of  how the module system is supposed to be implemented?  
2.  How does one go about knowing what modules are available?
3.  Will there be a php 5.5.x module, later one for 5.6.x, etc...  or will there be one big repo with php55* and php56&* packages?
4.  What other packages will be handled this way (python? ruby? tomcat?)
5.  If this is to be implemented, what will be the release cycle/lifecycle?  Are we going to get faster releases of php, etc...  via new repos or new packages in a repo?  If so, that would be great for fending off our Ubuntu-loving web developers.
6.  Is it going to be considered some sort of license violation or violation of terms of service if a person adds the "module", installs the RPMs, and then removes the repo?
7.  Is there some plan to completely modularize the distro, and have a stripped-down OS install, and everything provided as a series of modules?  If so, I personally think that would be horrible.
8.  Why spring this on everyone now, at beta 6, with no announcement, and it just gets discovered by a few of us in testing?  Was this planned all along, or was it a last minute inclusion?

Something else that should be addressed - I see as the next logical step, a model where suddenly certain modules require additional entitlements...  Given that SLES has always been an OS where you pay one fee for all the features, please don't go down that road...please!  Does anyone remember having to pay extra per-CPU on RHEL to get XFS filesystem support?  Offering of features a la carte gets complex, and has been a particular sore spot with me when dealing with RHEL.

Allen Beddingfield
Systems Engineer
The University of Alabama

________________________________________
From: sles-beta-bounces at lists.suse.com [sles-beta-bounces at lists.suse.com] on behalf of Simon Flood [S.M.Flood at ucs.cam.ac.uk]
Sent: Friday, May 16, 2014 8:11 AM
To: sles-beta at lists.suse.com
Subject: Re: [sles-beta] php disappeared in beta6?

On 16/05/2014 12:43, Matthias G. Eckermann wrote:

> I am afraid that you are contradicting yourself a bit:
> if you are able to use OBS, you _are_ online, and thus
> there is no reason to not use the Modules either from
> SCC or from an SMT or SUSE Manager (both with the
> appropriate repositories preloaded).

If that's the best response you (representing SUSE) can come up with
then that concerns me greatly.

BTW I'm not the person who said they installed servers off-line - in an
earlier response to this thread I said "Whilst the servers I build do
have network access from the start (they PXE boot then install via
AutoYaST) they don't all register against NCC/SCC or even SMT."

Simon
--
Simon Flood
Senior Systems Specialist
University of Cambridge
United Kingdom

Novell/SUSE/NetIQ Knowledge Partner
_______________________________________________
sles-beta mailing list
sles-beta at lists.suse.com
http://lists.suse.com/mailman/listinfo/sles-beta

From wendy at cray.com  Fri May 16 09:19:40 2014
From: wendy at cray.com (Wendy Palm)
Date: Fri, 16 May 2014 15:19:40 +0000
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <AAD7066EC17A5541BF5145CD44BEFA72E68ECE85@EX10MBN01.ua-net.ua.edu>
References: <20140514153539.GC11257@sgi.com>
	<20140514211427.GA5102@suse.com>	<53746E86.20401@netlab1.net>
	<201405151304.26509.okir@suse.de>	<5374A231.6080108@netlab1.net>
	<793d4b13bcf34209be5e668b8a512864@LGNMSXA01.prod.bk.dfs>
	<5374C56D.3050509@ucs.cam.ac.uk>
	<1400171679.24945.28.camel@ibrokeit.suse.de>
	<5375ECDA.4070409@ucs.cam.ac.uk>
	<20140516114349.GA5230@suse.com>,<53760E94.9030601@ucs.cam.ac.uk>
	<AAD7066EC17A5541BF5145CD44BEFA72E68ECE85@EX10MBN01.ua-net.ua.edu>
Message-ID: <D5048769A89C5C40BAC8CD7E108BF5E824048144@CFWEX01.americas.cray.com>

If we have to build something locally, we might as well download the latest version in public domain.  
There's no net benefit to pulling from SuSE and building ourselves.


> -----Original Message-----
> From: sles-beta-bounces at lists.suse.com [mailto:sles-beta-
> bounces at lists.suse.com] On Behalf Of Beddingfield, Allen
> Sent: Friday, May 16, 2014 10:09 AM
> To: sles-beta at lists.suse.com
> Subject: Re: [sles-beta] php disappeared in beta6?
> 
> I agree with Simon here in being "concerned greatly".  While I can go out and
> build this package or that package in OBS, why should I have to?  I think that
> pushing anyone to use custom OBS packaging over what is included with the
> OS is going to be very counter productive in the long run.  I'm assuming that
> each of these "modules" will add an additional repository per-module?  If
> these are available as channels in SUSE Manager and SMT (or whatever
> replaces SMT), my technical needs will be met on this issue, and it will just be
> an annoyance to me.  However, for those with other requirements, it can be
> more of a problem.
> I can foresee a number of situations where this is going to be problematic.
> 1.  I occasionally get the request for someone who just wants to do a quick
> test of something on a Linux system.  In that case, I just clone the VM (we
> usually use VMware cloning to deploy VMs) from my template, and send
> them the info.  I don't bother with registering with SMT, SUSE Manager, etc...
> since they are just going to test something quickly and tell me to delete the
> VM.  That is all fine now, with SLES 11, but with SLES 12, PHP won't be
> available in this case, unless I register the VM, or register my template first,
> install it, and then unregister before prepping it to be a template.  In that
> situation, I would need multiple templates, since not every VM will need
> every module.
> 2.  As much as we may not like it, we still have the stubborn vendors out
> there who will say "we support exactly this patch level, and nothing more",
> and we have to firewall the hell out of the system to keep it secure.  Well,
> currently if that vendor says they support SLES 11 SP2 or RHEL 6.3, etc... that
> would mean that they support the exact patch level that shipped on the
> media.  Well, with a repo, who determines what version they will support?
> In reality, over here in the U.S. where we constantly have to justify why we
> "can't just run Red Hat like everyone else and quit being difficult", they are
> just going to drop SLES support.
> 
> What is the answer?  I'm not sure...  we definitely need something better
> than the current situation.  The php5* packages (being 5.2.x) and php53
> (being 5.3.x) on SLES 11 is problematic.  First of all, I've already got people
> wanting 5.5.x. Maybe a good compromise would be a snapshot at release
> time of the modules all on the install DVD, and an update repo gets added on
> registration?  Maybe a series of directories on the DVD that are added as
> repos at install-time, if one selects the particular module?  That would seem
> sensible to me.  It allows for offline installation from DVD, and continued
> implementation of this new direction.
> 
> There are many questions to be answered here by someone from SUSE:
> 
> 1.  Can someone give us details of  how the module system is supposed to be
> implemented?
> 2.  How does one go about knowing what modules are available?
> 3.  Will there be a php 5.5.x module, later one for 5.6.x, etc...  or will there be
> one big repo with php55* and php56&* packages?
> 4.  What other packages will be handled this way (python? ruby? tomcat?)
> 5.  If this is to be implemented, what will be the release cycle/lifecycle?  Are
> we going to get faster releases of php, etc...  via new repos or new packages
> in a repo?  If so, that would be great for fending off our Ubuntu-loving web
> developers.
> 6.  Is it going to be considered some sort of license violation or violation of
> terms of service if a person adds the "module", installs the RPMs, and then
> removes the repo?
> 7.  Is there some plan to completely modularize the distro, and have a
> stripped-down OS install, and everything provided as a series of modules?  If
> so, I personally think that would be horrible.
> 8.  Why spring this on everyone now, at beta 6, with no announcement, and
> it just gets discovered by a few of us in testing?  Was this planned all along, or
> was it a last minute inclusion?
> 
> Something else that should be addressed - I see as the next logical step, a
> model where suddenly certain modules require additional entitlements...
> Given that SLES has always been an OS where you pay one fee for all the
> features, please don't go down that road...please!  Does anyone remember
> having to pay extra per-CPU on RHEL to get XFS filesystem support?  Offering
> of features a la carte gets complex, and has been a particular sore spot with
> me when dealing with RHEL.
> 
> Allen Beddingfield
> Systems Engineer
> The University of Alabama
> 
> ________________________________________
> From: sles-beta-bounces at lists.suse.com [sles-beta-
> bounces at lists.suse.com] on behalf of Simon Flood
> [S.M.Flood at ucs.cam.ac.uk]
> Sent: Friday, May 16, 2014 8:11 AM
> To: sles-beta at lists.suse.com
> Subject: Re: [sles-beta] php disappeared in beta6?
> 
> On 16/05/2014 12:43, Matthias G. Eckermann wrote:
> 
> > I am afraid that you are contradicting yourself a bit:
> > if you are able to use OBS, you _are_ online, and thus
> > there is no reason to not use the Modules either from
> > SCC or from an SMT or SUSE Manager (both with the
> > appropriate repositories preloaded).
> 
> If that's the best response you (representing SUSE) can come up with
> then that concerns me greatly.
> 
> BTW I'm not the person who said they installed servers off-line - in an
> earlier response to this thread I said "Whilst the servers I build do
> have network access from the start (they PXE boot then install via
> AutoYaST) they don't all register against NCC/SCC or even SMT."
> 
> Simon
> --
> Simon Flood
> Senior Systems Specialist
> University of Cambridge
> United Kingdom
> 
> Novell/SUSE/NetIQ Knowledge Partner
> _______________________________________________
> 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

From jrd at netlab1.net  Fri May 16 09:30:56 2014
From: jrd at netlab1.net (Joe Doupnik)
Date: Fri, 16 May 2014 16:30:56 +0100
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <D5048769A89C5C40BAC8CD7E108BF5E824048144@CFWEX01.americas.cray.com>
References: <20140514153539.GC11257@sgi.com>	<20140514211427.GA5102@suse.com>	<53746E86.20401@netlab1.net>	<201405151304.26509.okir@suse.de>	<5374A231.6080108@netlab1.net>	<793d4b13bcf34209be5e668b8a512864@LGNMSXA01.prod.bk.dfs>	<5374C56D.3050509@ucs.cam.ac.uk>	<1400171679.24945.28.camel@ibrokeit.suse.de>	<5375ECDA.4070409@ucs.cam.ac.uk>	<20140516114349.GA5230@suse.com>,
	<53760E94.9030601@ucs.cam.ac.uk>	<AAD7066EC17A5541BF5145CD44BEFA72E68ECE85@EX10MBN01.ua-net.ua.edu>
	<D5048769A89C5C40BAC8CD7E108BF5E824048144@CFWEX01.americas.cray.com>
Message-ID: <53762F30.3080303@netlab1.net>

     Yes, Wendy, correct. There are clever nuances one discovers in the 
source RPM build sequences which may help put together a nice local 
version of something. Beyond that we are on our own again.
     In a back channel discussion today the topic of licensing and 
support level came up for Modules, SDK and related items. It can be 
non-intuitive. Thus when matters mature another couple of steps it would 
be good to review those items with us as a sounding board for what might 
occur in the field after release.
     Speaking personally, I can imagine Matthias groaning about all of 
this, thinking "This is Not how we wanted to introduce the ideas." True 
enough, but then the general customer may have similar reactions at 
first. We do, however, thank you for your forbearance thoughout this 
discussion.
     Thanks,
     Joe D.

On 16/05/2014 16:19, Wendy Palm wrote:
> If we have to build something locally, we might as well download the latest version in public domain.
> There's no net benefit to pulling from SuSE and building ourselves.
>
>
>> -----Original Message-----
>> From: sles-beta-bounces at lists.suse.com [mailto:sles-beta-
>> bounces at lists.suse.com] On Behalf Of Beddingfield, Allen
>> Sent: Friday, May 16, 2014 10:09 AM
>> To: sles-beta at lists.suse.com
>> Subject: Re: [sles-beta] php disappeared in beta6?
>>
>> I agree with Simon here in being "concerned greatly".  While I can go out and
>> build this package or that package in OBS, why should I have to?  I think that
>> pushing anyone to use custom OBS packaging over what is included with the
>> OS is going to be very counter productive in the long run.  I'm assuming that
>> each of these "modules" will add an additional repository per-module?  If
>> these are available as channels in SUSE Manager and SMT (or whatever
>> replaces SMT), my technical needs will be met on this issue, and it will just be
>> an annoyance to me.  However, for those with other requirements, it can be
>> more of a problem.
>> I can foresee a number of situations where this is going to be problematic.
>> 1.  I occasionally get the request for someone who just wants to do a quick
>> test of something on a Linux system.  In that case, I just clone the VM (we
>> usually use VMware cloning to deploy VMs) from my template, and send
>> them the info.  I don't bother with registering with SMT, SUSE Manager, etc...
>> since they are just going to test something quickly and tell me to delete the
>> VM.  That is all fine now, with SLES 11, but with SLES 12, PHP won't be
>> available in this case, unless I register the VM, or register my template first,
>> install it, and then unregister before prepping it to be a template.  In that
>> situation, I would need multiple templates, since not every VM will need
>> every module.
>> 2.  As much as we may not like it, we still have the stubborn vendors out
>> there who will say "we support exactly this patch level, and nothing more",
>> and we have to firewall the hell out of the system to keep it secure.  Well,
>> currently if that vendor says they support SLES 11 SP2 or RHEL 6.3, etc... that
>> would mean that they support the exact patch level that shipped on the
>> media.  Well, with a repo, who determines what version they will support?
>> In reality, over here in the U.S. where we constantly have to justify why we
>> "can't just run Red Hat like everyone else and quit being difficult", they are
>> just going to drop SLES support.
>>
>> What is the answer?  I'm not sure...  we definitely need something better
>> than the current situation.  The php5* packages (being 5.2.x) and php53
>> (being 5.3.x) on SLES 11 is problematic.  First of all, I've already got people
>> wanting 5.5.x. Maybe a good compromise would be a snapshot at release
>> time of the modules all on the install DVD, and an update repo gets added on
>> registration?  Maybe a series of directories on the DVD that are added as
>> repos at install-time, if one selects the particular module?  That would seem
>> sensible to me.  It allows for offline installation from DVD, and continued
>> implementation of this new direction.
>>
>> There are many questions to be answered here by someone from SUSE:
>>
>> 1.  Can someone give us details of  how the module system is supposed to be
>> implemented?
>> 2.  How does one go about knowing what modules are available?
>> 3.  Will there be a php 5.5.x module, later one for 5.6.x, etc...  or will there be
>> one big repo with php55* and php56&* packages?
>> 4.  What other packages will be handled this way (python? ruby? tomcat?)
>> 5.  If this is to be implemented, what will be the release cycle/lifecycle?  Are
>> we going to get faster releases of php, etc...  via new repos or new packages
>> in a repo?  If so, that would be great for fending off our Ubuntu-loving web
>> developers.
>> 6.  Is it going to be considered some sort of license violation or violation of
>> terms of service if a person adds the "module", installs the RPMs, and then
>> removes the repo?
>> 7.  Is there some plan to completely modularize the distro, and have a
>> stripped-down OS install, and everything provided as a series of modules?  If
>> so, I personally think that would be horrible.
>> 8.  Why spring this on everyone now, at beta 6, with no announcement, and
>> it just gets discovered by a few of us in testing?  Was this planned all along, or
>> was it a last minute inclusion?
>>
>> Something else that should be addressed - I see as the next logical step, a
>> model where suddenly certain modules require additional entitlements...
>> Given that SLES has always been an OS where you pay one fee for all the
>> features, please don't go down that road...please!  Does anyone remember
>> having to pay extra per-CPU on RHEL to get XFS filesystem support?  Offering
>> of features a la carte gets complex, and has been a particular sore spot with
>> me when dealing with RHEL.
>>
>> Allen Beddingfield
>> Systems Engineer
>> The University of Alabama
>>
>> ________________________________________
>> From: sles-beta-bounces at lists.suse.com [sles-beta-
>> bounces at lists.suse.com] on behalf of Simon Flood
>> [S.M.Flood at ucs.cam.ac.uk]
>> Sent: Friday, May 16, 2014 8:11 AM
>> To: sles-beta at lists.suse.com
>> Subject: Re: [sles-beta] php disappeared in beta6?
>>
>> On 16/05/2014 12:43, Matthias G. Eckermann wrote:
>>
>>> I am afraid that you are contradicting yourself a bit:
>>> if you are able to use OBS, you _are_ online, and thus
>>> there is no reason to not use the Modules either from
>>> SCC or from an SMT or SUSE Manager (both with the
>>> appropriate repositories preloaded).
>> If that's the best response you (representing SUSE) can come up with
>> then that concerns me greatly.
>>
>> BTW I'm not the person who said they installed servers off-line - in an
>> earlier response to this thread I said "Whilst the servers I build do
>> have network access from the start (they PXE boot then install via
>> AutoYaST) they don't all register against NCC/SCC or even SMT."
>>
>> Simon
>> --
>> Simon Flood
>> Senior Systems Specialist
>> University of Cambridge
>> United Kingdom
>>
>> Novell/SUSE/NetIQ Knowledge Partner
>> _______________________________________________
>> 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
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta


From tparker at cbnco.com  Fri May 16 09:33:13 2014
From: tparker at cbnco.com (Tom Parker)
Date: Fri, 16 May 2014 11:33:13 -0400
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <20140514211427.GA5102@suse.com>
References: <20140514153539.GC11257@sgi.com>	<AAD7066EC17A5541BF5145CD44BEFA72E68EAB70@EX10MBN01.ua-net.ua.edu>
	<20140514211427.GA5102@suse.com>
Message-ID: <53762FB9.8080006@cbnco.com>

Hello

My two cents on this issue...

I also agree with most of the other sysadmins on this list that removing
php and other "optional" items from the iso is not a reasonable option. 
I like the concept of modules and my servers are online but having
something that has been available out of the box with SLES 11 disappear
is problematic. 

If the same is being done to ruby then puppet (which I use to register
my clients to my smt server) will also not work out of the box.

The proposed solution of shipping a base version of php, ruby, etc and
then having the option to update with the add on modules seems to be the
sane option to me.

Tom
 
On 14/05/14 05:14 PM, Matthias G. Eckermann wrote:
> On 2014-05-14 T 15:55 +0000 Beddingfield, Allen wrote:
>
>> I can confirm this as an issue, too.  We
>> definitely require that PHP be included, since we
>> are hosting our web infrastructure on SLES.
> PHP is not on the "ISO" anymore, but in a "module",
> which is only delivered online. 
>
> To get PHP, please register your system during
> installation and chose the "Web & Scripting" module.
>
> More on the "Modules" concept I will explain in one
> of the next beta calls.
>
> so long -
> 	MgE
>  
>> From: sles-beta-bounces at lists.suse.com [sles-beta-bounces at lists.suse.com] on behalf of Tony Ernst [tee at sgi.com]
>> Sent: Wednesday, May 14, 2014 10:35 AM
>> To: sles-beta at lists.suse.com
>> Subject: [sles-beta] php disappeared in beta6?
>>
>> Sles12 beta5 had php (php5) rpms. They seem to have disappeared in beta6.
>> Was that intentional? Oddly enough, the php5-devel and the pcp .src rpm
>> are still in the beta6 SDK.


From S.M.Flood at ucs.cam.ac.uk  Fri May 16 09:56:42 2014
From: S.M.Flood at ucs.cam.ac.uk (Simon Flood)
Date: Fri, 16 May 2014 16:56:42 +0100
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <53762FB9.8080006@cbnco.com>
References: <20140514153539.GC11257@sgi.com>	<AAD7066EC17A5541BF5145CD44BEFA72E68EAB70@EX10MBN01.ua-net.ua.edu>	<20140514211427.GA5102@suse.com>
	<53762FB9.8080006@cbnco.com>
Message-ID: <5376353A.7040502@ucs.cam.ac.uk>

On 16/05/2014 16:33, Tom Parker wrote:

> If the same is being done to ruby then puppet (which I use to register
> my clients to my smt server) will also not work out of the box.

The same is true for Ansible (not included with SLES) if python is removed.

I mention this because Ansible is something some colleagues (and myself 
as an interested party) are looking at as an alternative to AutoYaST 
where a server PXE boots and installs a minimal OS (possibly via minimal 
AutoYaST file), chroot to OS and uses Ansible to then build the server 
according to profile(s) assigned to it. I don't yet know all the details 
but the reason for looking at this is to solve a problem of having 
multiple AutoYaST scripts.

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.

Simon
-- 
Simon Flood
Senior Systems Specialist
University of Cambridge
United Kingdom

Novell/SUSE/NetIQ Knowledge Partner

From mge at suse.com  Fri May 16 10:12:37 2014
From: mge at suse.com (Matthias G. Eckermann)
Date: Fri, 16 May 2014 18:12:37 +0200
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <AAD7066EC17A5541BF5145CD44BEFA72E68ECE85@EX10MBN01.ua-net.ua.edu>
References: <53746E86.20401@netlab1.net> <201405151304.26509.okir@suse.de>
	<5374A231.6080108@netlab1.net>
	<793d4b13bcf34209be5e668b8a512864@LGNMSXA01.prod.bk.dfs>
	<5374C56D.3050509@ucs.cam.ac.uk>
	<1400171679.24945.28.camel@ibrokeit.suse.de>
	<5375ECDA.4070409@ucs.cam.ac.uk> <20140516114349.GA5230@suse.com>
	<53760E94.9030601@ucs.cam.ac.uk>
	<AAD7066EC17A5541BF5145CD44BEFA72E68ECE85@EX10MBN01.ua-net.ua.edu>
Message-ID: <20140516161237.GN9872@suse.com>

Hello Alan,

On 2014-05-16 T 15:08 +0000 Beddingfield, Allen wrote:
  
> There are many questions to be answered here by
> someone from SUSE:

> 1.  Can someone give us details of  how the module
> system is supposed to be implemented?  

> 2.  How does one go about knowing what modules are
> available?

> 3.  Will there be a php 5.5.x module, later one for
> 5.6.x, etc...  or will there be one big repo with
> php55* and php56&* packages?

> 4.  What other packages will be handled this way
> (python? ruby? tomcat?)

> 5.  If this is to be implemented, what will be the
> release cycle/lifecycle?  Are we going to get faster
> releases of php, etc...  via new repos or new packages
> in a repo?  If so, that would be great for fending off
> our Ubuntu-loving web developers.

> 6.  Is it going to be considered some sort of license
> violation or violation of terms of service if a person
> adds the "module", installs the RPMs, and then removes
> the repo?

> 7.  Is there some plan to completely modularize the
> distro, and have a stripped-down OS install, and
> everything provided as a series of modules?  If so, I
> personally think that would be horrible.

Good questions, which I will answer either implicitly or
explicitly in my presentation on 2014-05-26. Which
brings us to the last question:

> 8.  Why spring this on everyone now, at beta 6, with
> no announcement, and it just gets discovered by a few
> of us in testing?  

Timing issues on multiple fronts (technology,
implementation, beta presentation session planning,
availability of people including myself), unfortunatly.
I apologize.

> Was this planned all along, or was it a last minute
> inclusion?

This was not planned short notice, but over a longer
period of time, otherwise the integration with the
SCC and all that stuff would not be there.

Let's continue to discuss Monday in 10 day.

so long -
	MgE

-- 
Matthias G. Eckermann     Senior Product Manager   SUSE? Linux Enterprise
Phone: +49 30 44315731    Mobile: +49 179 2949448    E-Mail: mge at suse.com
SUSE LINUX Products GmbH  Maxfeldstra?e 5          90409 N?rnberg Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg)

From lmb at suse.com  Fri May 16 15:52:22 2014
From: lmb at suse.com (Lars Marowsky-Bree)
Date: Fri, 16 May 2014 23:52:22 +0200
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <5376353A.7040502@ucs.cam.ac.uk>
References: <20140514153539.GC11257@sgi.com>
	<AAD7066EC17A5541BF5145CD44BEFA72E68EAB70@EX10MBN01.ua-net.ua.edu>
	<20140514211427.GA5102@suse.com> <53762FB9.8080006@cbnco.com>
	<5376353A.7040502@ucs.cam.ac.uk>
Message-ID: <20140516215222.GB4368@suse.de>

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

-- 
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


From jrd at netlab1.net  Sat May 17 02:40:34 2014
From: jrd at netlab1.net (Joe Doupnik)
Date: Sat, 17 May 2014 09:40:34 +0100
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <20140516215222.GB4368@suse.de>
References: <20140514153539.GC11257@sgi.com>	<AAD7066EC17A5541BF5145CD44BEFA72E68EAB70@EX10MBN01.ua-net.ua.edu>	<20140514211427.GA5102@suse.com>
	<53762FB9.8080006@cbnco.com>	<5376353A.7040502@ucs.cam.ac.uk>
	<20140516215222.GB4368@suse.de>
Message-ID: <53772082.3060904@netlab1.net>

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
>


From lmb at suse.com  Sun May 18 05:10:50 2014
From: lmb at suse.com (Lars Marowsky-Bree)
Date: Sun, 18 May 2014 13:10:50 +0200
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <53772082.3060904@netlab1.net>
References: <20140514153539.GC11257@sgi.com>
	<AAD7066EC17A5541BF5145CD44BEFA72E68EAB70@EX10MBN01.ua-net.ua.edu>
	<20140514211427.GA5102@suse.com> <53762FB9.8080006@cbnco.com>
	<5376353A.7040502@ucs.cam.ac.uk> <20140516215222.GB4368@suse.de>
	<53772082.3060904@netlab1.net>
Message-ID: <20140518111050.GF4368@suse.de>

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


From jrd at netlab1.net  Sun May 18 05:36:33 2014
From: jrd at netlab1.net (Joe Doupnik)
Date: Sun, 18 May 2014 12:36:33 +0100
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <20140518111050.GF4368@suse.de>
References: <20140514153539.GC11257@sgi.com>	<AAD7066EC17A5541BF5145CD44BEFA72E68EAB70@EX10MBN01.ua-net.ua.edu>	<20140514211427.GA5102@suse.com>
	<53762FB9.8080006@cbnco.com>	<5376353A.7040502@ucs.cam.ac.uk>
	<20140516215222.GB4368@suse.de>	<53772082.3060904@netlab1.net>
	<20140518111050.GF4368@suse.de>
Message-ID: <53789B41.1080604@netlab1.net>

     I think we are going in smaller circles while trying to describe 
installation procedures.
     Yours, and many others without doubt, do patching/updates at 
installation time.
     Mine, and many others without doubt, delay such patching and 
updating until later, for a variety of good reasons.
     Licensing is presumed to be done properly. Registration is a 
optional separate step.

     DVDs are readily available at no cost, by downloading, at meetings, 
from friends, and so on. Usually that is one disc. Hmm, ought that hold 
the basic installation in reasonably complete form?

     Presuming a good network connection to the world, a set of 
credentials, and shrewd guesses about which repositories hold what 
should not be requirements, but the present scheme is making be so.
     Presuming that patches and updates are done during installation is 
a bad idea.
     Offering version alternatives is a very good idea, but first 
removing the starting point from the basic installation is a very bad idea.

     I hope that all here can clearly identify those 
presumptions/preconditions/changes being proposed by the new scheme.
     I do not consider them to be slight as they put up a significant 
barrier which must be worked around by more manual labour.

     SMT is a gem, very much appreciated.

     There, shorter text than usual. Perhaps this is a sign of progress, 
but then one might need a note from Mother and register with various 
news channels to be certain.
     Joe D.

On 18/05/2014 12:10, Lars Marowsky-Bree 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
>


From darrent at akurit.com.au  Sun May 18 17:27:56 2014
From: darrent at akurit.com.au (Darren Thompson)
Date: Mon, 19 May 2014 09:27:56 +1000
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <20140518111050.GF4368@suse.de>
References: <20140514153539.GC11257@sgi.com>
	<AAD7066EC17A5541BF5145CD44BEFA72E68EAB70@EX10MBN01.ua-net.ua.edu>
	<20140514211427.GA5102@suse.com> <53762FB9.8080006@cbnco.com>
	<5376353A.7040502@ucs.cam.ac.uk> <20140516215222.GB4368@suse.de>
	<53772082.3060904@netlab1.net> <20140518111050.GF4368@suse.de>
Message-ID: <CAEUhfEdU-z5YUhxtr7S_V0Or9uHg-4UTfUPL1AMMX_-GSSE4zg@mail.gmail.com>

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>

From darrent at akurit.com.au  Sun May 18 19:16:01 2014
From: darrent at akurit.com.au (Darren Thompson)
Date: Mon, 19 May 2014 11:16:01 +1000
Subject: [sles-beta] YAST2 apps through SSH
Message-ID: <CAEUhfEfsSjK91Pxkd_GkF7kcymAuaps3EHwNdQXBuYg292UjyA@mail.gmail.com>

Team

I'm observing a recurring error in YAST2 apps via ssh

If I SSH to the SLES12 server (ssh -X root@{serverip} ) and then run yast2
I get the yast screen as expected.
If I then try to run one of the yast2 sub applications (e.g. disk
partitioner) the action seems to fail and never launches.

If i get the module list (yast2 -l) and then run the module directly from
the command prompt in the ssh session (e.g. yast2 disk) the module runs
correctly.

When the module actually fails, this is what appears in the ssh session:"
GTK GUI wanted but not found, falling back to Qt.

** (y2controlcenter-gnome:2206): WARNING **: Couldn't connect to
accessibility bus: Failed to connect to socket /tmp/dbus-qxvaBUyMzH:
Connection refused
/usr/bin/xdg-su: line 503:  2244 Segmentation fault      xterm -geom 60x5
-T "xdg-su: $cmd" -e su -c "$cmd"
"

When run from the command line (works) this is what I get: "
 GTK GUI wanted but not found, falling back to Qt.
libGL error: failed to load driver: i965
libGL error: Try again with LIBGL_DEBUG=verbose for more details."

Am I the only person seeing this and should I raise an SR for it?

Darren
-- 

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/cf43a799/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/cf43a799/attachment.jpg>

From darrent at akurit.com.au  Sun May 18 21:20:03 2014
From: darrent at akurit.com.au (Darren Thompson)
Date: Mon, 19 May 2014 13:20:03 +1000
Subject: [sles-beta] ISCSI-TARGET cannot be configured under SLES12 B6
Message-ID: <CAEUhfEfhJ6XLt7H-xD4RYctp=SwP3+J+ETr9Nu+Mpyx6_YwMZw@mail.gmail.com>

Team

It looks like the ISCS-Target software is not working under SLES12 B6.

The YAST configuration reports that a "sys-v init resource" is not able to
be run and I cannot find a systemd startup service that replaces the mising
sys-v script. (see screenshot)

Should I just raise a SR for this?


-- 

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/cab4a544/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/cab4a544/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ISCSI-TARGET.png
Type: image/png
Size: 28259 bytes
Desc: not available
URL: <http://lists.suse.com/mailman/private/sles-beta/attachments/20140519/cab4a544/attachment.png>

From darrent at akurit.com.au  Sun May 18 22:11:15 2014
From: darrent at akurit.com.au (Darren Thompson)
Date: Mon, 19 May 2014 14:11:15 +1000
Subject: [sles-beta] YAST2 apps through SSH
In-Reply-To: <CAEUhfEfsSjK91Pxkd_GkF7kcymAuaps3EHwNdQXBuYg292UjyA@mail.gmail.com>
References: <CAEUhfEfsSjK91Pxkd_GkF7kcymAuaps3EHwNdQXBuYg292UjyA@mail.gmail.com>
Message-ID: <CAEUhfEfvH2tk0qjrMecwz6pfHu7MmAjVsWX7ovAKrYjTRLN1ow@mail.gmail.com>

Team

If I run 'yast2' from the ssh shell the sub command work, if I run 'yast2
&' they work.

Running command with '&' is very common as it releaaes the ssh shell to run
other command lines. This is a new problem for SLES12 and I think it has to
do with the changes to yast

Darren


On 19 May 2014 11:16, Darren Thompson <darrent at akurit.com.au> wrote:

> Team
>
> I'm observing a recurring error in YAST2 apps via ssh
>
> If I SSH to the SLES12 server (ssh -X root@{serverip} ) and then run
> yast2 I get the yast screen as expected.
> If I then try to run one of the yast2 sub applications (e.g. disk
> partitioner) the action seems to fail and never launches.
>
> If i get the module list (yast2 -l) and then run the module directly from
> the command prompt in the ssh session (e.g. yast2 disk) the module runs
> correctly.
>
> When the module actually fails, this is what appears in the ssh session:"
> GTK GUI wanted but not found, falling back to Qt.
>
> ** (y2controlcenter-gnome:2206): WARNING **: Couldn't connect to
> accessibility bus: Failed to connect to socket /tmp/dbus-qxvaBUyMzH:
> Connection refused
> /usr/bin/xdg-su: line 503:  2244 Segmentation fault      xterm -geom 60x5
> -T "xdg-su: $cmd" -e su -c "$cmd"
> "
>
> When run from the command line (works) this is what I get: "
>  GTK GUI wanted but not found, falling back to Qt.
> libGL error: failed to load driver: i965
> libGL error: Try again with LIBGL_DEBUG=verbose for more details."
>
> Am I the only person seeing this and should I raise an SR for it?
>
> Darren
> --
>
> 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
>



-- 

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/7d27f0bc/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/7d27f0bc/attachment.jpg>

From darrent at akurit.com.au  Sun May 18 22:12:58 2014
From: darrent at akurit.com.au (Darren Thompson)
Date: Mon, 19 May 2014 14:12:58 +1000
Subject: [sles-beta] Cosmetic error in YAST,
	service manager appears twice in list
Message-ID: <CAEUhfEfKz3Hutw6yVPgb+C2v48v=-BfDYv0u9WG3EB3cuRMePg@mail.gmail.com>

Team

cosmetic issue, 'service manager' icon appears in yast twice (see attached
screenshot)

-- 

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/408ebe18/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/408ebe18/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: service-manager_appears_twice.png
Type: image/png
Size: 25888 bytes
Desc: not available
URL: <http://lists.suse.com/mailman/private/sles-beta/attachments/20140519/408ebe18/attachment.png>

From uwedr at suse.com  Sun May 18 23:49:34 2014
From: uwedr at suse.com (Uwe Drechsel)
Date: Mon, 19 May 2014 07:49:34 +0200
Subject: [sles-beta] Cosmetic error in YAST,
In-Reply-To: <CAEUhfEfKz3Hutw6yVPgb+C2v48v=-BfDYv0u9WG3EB3cuRMePg@mail.gmail.com>
References: <CAEUhfEfKz3Hutw6yVPgb+C2v48v=-BfDYv0u9WG3EB3cuRMePg@mail.gmail.com>
Message-ID: <20140519054934.GL6184@suse.de>

On Mon, May 19, Darren Thompson wrote:

> Team
> 
> cosmetic issue, 'service manager' icon appears in yast twice (see attached
> screenshot)
> 

That's known and going to be fixed in next beta.

Thanks
Uwe

From uwedr at suse.com  Sun May 18 23:49:40 2014
From: uwedr at suse.com (Uwe Drechsel)
Date: Mon, 19 May 2014 07:49:40 +0200
Subject: [sles-beta] ISCSI-TARGET cannot be configured under SLES12 B6
In-Reply-To: <CAEUhfEfhJ6XLt7H-xD4RYctp=SwP3+J+ETr9Nu+Mpyx6_YwMZw@mail.gmail.com>
References: <CAEUhfEfhJ6XLt7H-xD4RYctp=SwP3+J+ETr9Nu+Mpyx6_YwMZw@mail.gmail.com>
Message-ID: <20140519054940.GM6184@suse.de>

On Mon, May 19, Darren Thompson wrote:

> Team
> 
> It looks like the ISCS-Target software is not working under SLES12 B6.
> 
> The YAST configuration reports that a "sys-v init resource" is not able to
> be run and I cannot find a systemd startup service that replaces the mising
> sys-v script. (see screenshot)
> 
> Should I just raise a SR for this?
> 

Yes, please do so!

Thanks
Uwe

--
Uwe Drechsel
Project Manager              
SUSE Linux Products GmbH
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg)