From darrent at akurit.com.au  Mon May 19 00:37:02 2014
From: darrent at akurit.com.au (Darren Thompson)
Date: Mon, 19 May 2014 16:37:02 +1000
Subject: [sles-beta] ISCSI-TARGET cannot be configured under SLES12 B6
In-Reply-To: <20140519054940.GM6184@suse.de>
References: <CAEUhfEfhJ6XLt7H-xD4RYctp=SwP3+J+ETr9Nu+Mpyx6_YwMZw@mail.gmail.com>
	<20140519054940.GM6184@suse.de>
Message-ID: <CAEUhfEe69DEGpFLudLVdq-=13Pd155hTmLvLc2SbNcfXo9CQYA@mail.gmail.com>

OK SR10893020421 raised


On 19 May 2014 15:49, Uwe Drechsel <uwedr at suse.com> wrote:

> 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)
> _______________________________________________
> 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/8c594b17/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/8c594b17/attachment.jpg>

From mge at suse.com  Mon May 19 01:11:19 2014
From: mge at suse.com (Matthias G. Eckermann)
Date: Mon, 19 May 2014 09:11:19 +0200
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <CAEUhfEdU-z5YUhxtr7S_V0Or9uHg-4UTfUPL1AMMX_-GSSE4zg@mail.gmail.com>
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>
	<CAEUhfEdU-z5YUhxtr7S_V0Or9uHg-4UTfUPL1AMMX_-GSSE4zg@mail.gmail.com>
Message-ID: <20140519071119.GB4421@suse.com>

Hello Darren and all,

On 2014-05-19 T 09:27 +1000 Darren Thompson wrote:
 
> I have stood out of this discussion so far but feel I
> need to make a contribution.

[...] 
 
> 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"?).

you really should have a look how we have solved it,
before involving into the discussion. It's not that

If that were not enough, SMT or -- more powerful --
SUSE Manager will help you to manage your systems.

> 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.
[...]
> If the build process REQUIRES on-line registration
> and patching, then the build process is wrong.

I am afraid, this is contradicting the requirements we
get all over all: Isn't it fair to say that patching
via RPMs is the "industry standard"? And this is how we
provide fixes for any issues - and even features and
enhancements, if there is a critical mass of customers
requesting this.

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 jreidinger at suse.com  Mon May 19 01:23:32 2014
From: jreidinger at suse.com (Josef Reidinger)
Date: Mon, 19 May 2014 09:23:32 +0200
Subject: [sles-beta] YAST2 apps through SSH
In-Reply-To: <CAEUhfEfvH2tk0qjrMecwz6pfHu7MmAjVsWX7ovAKrYjTRLN1ow@mail.gmail.com>
References: <CAEUhfEfsSjK91Pxkd_GkF7kcymAuaps3EHwNdQXBuYg292UjyA@mail.gmail.com>
	<CAEUhfEfvH2tk0qjrMecwz6pfHu7MmAjVsWX7ovAKrYjTRLN1ow@mail.gmail.com>
Message-ID: <20140519092332.16be7d91@linux-5mqx.site>

On Mon, 19 May 2014 14:11:15 +1000
"Darren Thompson" <darrent at akurit.com.au> wrote:

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

I recommend to report SR and attach yast logs for it. It is possible to
be related to qt5 usage for GUI which have in some scenarios still some
problems on which we work.

Josef

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


From darrent at akurit.com.au  Mon May 19 01:24:57 2014
From: darrent at akurit.com.au (Darren Thompson)
Date: Mon, 19 May 2014 17:24:57 +1000
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <20140519071119.GB4421@suse.com>
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>
	<CAEUhfEdU-z5YUhxtr7S_V0Or9uHg-4UTfUPL1AMMX_-GSSE4zg@mail.gmail.com>
	<20140519071119.GB4421@suse.com>
Message-ID: <CAEUhfEdQP9PwGNrPgfnFx8isB4CcgCCpdeXMqQJrd6sndHjYzA@mail.gmail.com>

Matthias

There seems to be a disjoin in thinking between OS Install and OS patching.

SUSE provides very powerful patching tools and RPM based patching is very
good lately (I personally have very few issues with automatic dependency
resolution etc).

BUT, that is not what we are trying to discuss. What we are discussing is
the OS Instillation process. The vendor provided media really should be all
you require for a basic OS install.

The OS install workflow for SLES12 is starting to assume internet connected
servers which are registered back to Novell Immediately, and that is rarely
the reality of the server builds I have been involved with.

My "normal" build/workflow is more like:

1. Install server (either from Install media of via a pre-configured
"install server" on-site that has the installation media content).
2. Verify that the server is running correctly and no obvious
hardware/software issue are encountered.
3. Local customisations/configurations are applied
4. Register server to SMT server (I know that ZCM and/Or SUSE Manager could
be used, but that is not my "normal" workflow), apply all "know good"
patches.
5. Go to Novell Customer Centre Portal and ensure that server has
registered there (it normally is proxy registered through SMT).

In a lot of cases, these server do not and never have direct internet
access so cannot do the registration or on-line patching driectly.

Darren




On 19 May 2014 17:11, Matthias G. Eckermann <mge at suse.com> wrote:

> Hello Darren and all,
>
> On 2014-05-19 T 09:27 +1000 Darren Thompson wrote:
>
> > I have stood out of this discussion so far but feel I
> > need to make a contribution.
>
> [...]
>
> > 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"?).
>
> you really should have a look how we have solved it,
> before involving into the discussion. It's not that
>
> If that were not enough, SMT or -- more powerful --
> SUSE Manager will help you to manage your systems.
>
> > 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.
> [...]
> > If the build process REQUIRES on-line registration
> > and patching, then the build process is wrong.
>
> I am afraid, this is contradicting the requirements we
> get all over all: Isn't it fair to say that patching
> via RPMs is the "industry standard"? And this is how we
> provide fixes for any issues - and even features and
> enhancements, if there is a critical mass of customers
> requesting this.
>
> 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)
>



-- 

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

From rbrown at suse.de  Mon May 19 02:08:24 2014
From: rbrown at suse.de (Richard Brown)
Date: Mon, 19 May 2014 10:08:24 +0200
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <CAEUhfEdQP9PwGNrPgfnFx8isB4CcgCCpdeXMqQJrd6sndHjYzA@mail.gmail.com>
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>
	<CAEUhfEdU-z5YUhxtr7S_V0Or9uHg-4UTfUPL1AMMX_-GSSE4zg@mail.gmail.com>
	<20140519071119.GB4421@suse.com>
	<CAEUhfEdQP9PwGNrPgfnFx8isB4CcgCCpdeXMqQJrd6sndHjYzA@mail.gmail.com>
Message-ID: <1400486904.19291.8.camel@ibrokeit.suse.de>

Hello Darren,

> My "normal" build/workflow is more like:
> 
> 
> 1. Install server (either from Install media of via a pre-configured
> "install server" on-site that has the installation media content).
> 2. Verify that the server is running correctly and no obvious
> hardware/software issue are encountered.
> 3. Local customisations/configurations are applied
> 4. Register server to SMT server (I know that ZCM and/Or SUSE Manager
> could be used, but that is not my "normal" workflow), apply all "know
> good" patches.
> 5. Go to Novell Customer Centre Portal and ensure that server has
> registered there (it normally is proxy registered through SMT).
> 
> 
> In a lot of cases, these server do not and never have direct internet
> access so cannot do the registration or on-line patching driectly.

Can you explain to me the problems with the workflow I propose below?
This is how I'd imagine you'd accomplish the equivalent workflow with
SLE 12:

1. Install Server (either from Install media or via pre-configured
"install server")
2. During installation, register with SMT Server
3. Do not opt to patch during installation (the option is presented as
soon as you register)
4. Add Extensions/Modules as required - will be included in the
installation and pulled from SMT
5. Verify server is running correctly
6. Local customisations/configurations
7. Patch with "known good" patches from SMT
8. Go to SUSE Customer Center and ensure the server has registered there

While in terms of 'number of steps' the above process may seem more, but
in reality I think you'd find the 'real work' about the same

Regards,

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 urs.frey at post.ch  Mon May 19 02:09:20 2014
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Mon, 19 May 2014 08:09:20 +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: <40637DBB36AF3941B243A286A432CA0B0F998B69@HXMB12.pnet.ch>

Hi Matthias
Just opened the second SR on this issue

SUMMARY OF SR # 10893020611 
  * SR Severity Level: Medium  
  * SR Brief Description: SLES12 Beta6 x86_64 Btrfs snapper does not get initialized automated with autoyast

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 mge at suse.com  Mon May 19 02:18:31 2014
From: mge at suse.com (Matthias G. Eckermann)
Date: Mon, 19 May 2014 10:18:31 +0200
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <CAEUhfEdQP9PwGNrPgfnFx8isB4CcgCCpdeXMqQJrd6sndHjYzA@mail.gmail.com>
References: <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>
	<CAEUhfEdU-z5YUhxtr7S_V0Or9uHg-4UTfUPL1AMMX_-GSSE4zg@mail.gmail.com>
	<20140519071119.GB4421@suse.com>
	<CAEUhfEdQP9PwGNrPgfnFx8isB4CcgCCpdeXMqQJrd6sndHjYzA@mail.gmail.com>
Message-ID: <20140519081831.GB9787@suse.com>

Hello Darren and all,

On 2014-05-19 T 17:24 +1000 Darren Thompson wrote:

> There seems to be a disjoin in thinking between OS
> Install and OS patching.
> 
> SUSE provides very powerful patching tools and RPM
> based patching is very good lately (I personally have
> very few issues with automatic dependency resolution
> etc).
> 
> BUT, that is not what we are trying to discuss. What
> we are discussing is the OS Instillation process. The
> vendor provided media really should be all you
> require for a basic OS install.
> 
> The OS install workflow for SLES12 is starting to
> assume internet connected servers which are
> registered back to Novell Immediately, and that is
> rarely the reality of the server builds I have been
> involved with.

Relax! :-)

Calling my PM peers for witnesses: I am personally very
vocal about the requirement that we should never assume
that a system to be installed is directly connected to
the Internet.

However, we indeed assume that any system has access to
a "proxy server", i.e. either SMT or SUSE Manager,
which contains the update packages -- and going forward
also the "Modules"; patches to SMT 11 SP3 will be made
available later in summer to enable this, as I already
wrote in response to a question by Urs on this list.

And because SMT and SUSE Manager can also work in
"disconnected mode", security or privacy requirements
of any customer should be met.
 
> My "normal" build/workflow is more like:

> 1. Install server (either from Install media of via a
> pre-configured "install server" on-site that has the
> installation media content).
>
> 2. Verify that the server is running correctly and no
> obvious hardware/software issue are encountered.
>
> 3. Local customisations/configurations are applied
>
> 4. Register server to SMT server (I know that ZCM
> and/Or SUSE Manager could be used, but that is not my
> "normal" workflow), apply all "know good" patches.
>
> 5. Go to Novell Customer Centre Portal and ensure
> that server has registered there (it normally is
> proxy registered through SMT).

For the future the process might look like this:

1. Fill the (local, potentially disconnected) SMT
   with latest updates or (better) use SUSE Manager
   to create a custom set of packages.

   The process how to do that will not change from
   SLE 11 to SLE 12.

2. Install system, either from Install media of via a
   pre-configured "install server" on-site that has the
   installation media content (or via SUSE Manager).

   During installation, register the system to SMT
   or SUSE Manager and get all (provided) updates
   applied. In addition you automatically will get
   access to all Modules and can install them directly
   during the first run.

   As mentioned above, this step reqires updates to SMT
   which not yet have been delivered (unfortunately).

3. Local customisations/configurations are applied

4. Go to Novell Customer Centre Portal and ensure
   that server has registered there (it normally is
   proxy registered through SMT / SUSE Manager).

As you see, the workflow is not that significantly
different from your old workflow.  Because you can
configure the patches to be installed via SMT or more
comfortable via SUSE Manager, the result of the
installation is not different from the result of your
workflow today.

However, you have two advantages:

1. You save one update/reboot cycle, as you register
   and update directly during the first run. 

2. Your system will receive critical updates before
   the first reboot. This is important, if we would
   encounter issues with e.g. not yet released hardware,
   and we would need to release updates to "dracut"
   (just an example).
   Releasing new ISOs just is not an option usually
   due to certification requirements, ...

> In a lot of cases, these server do not and never have
> direct internet access so cannot do the registration
> or on-line patching driectly.

Understood -- and thanks for confirming my position
that "disconnected" installation is important!

so long -
	MgE


> On 19 May 2014 17:11, Matthias G. Eckermann <mge at suse.com> wrote:
> 
> > Hello Darren and all,
> >
> > On 2014-05-19 T 09:27 +1000 Darren Thompson wrote:
> >
> > > I have stood out of this discussion so far but feel I
> > > need to make a contribution.
> >
> > [...]
> >
> > > 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"?).
> >
> > you really should have a look how we have solved it,
> > before involving into the discussion. It's not that
> >
> > If that were not enough, SMT or -- more powerful --
> > SUSE Manager will help you to manage your systems.
> >
> > > 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.
> > [...]
> > > If the build process REQUIRES on-line registration
> > > and patching, then the build process is wrong.
> >
> > I am afraid, this is contradicting the requirements we
> > get all over all: Isn't it fair to say that patching
> > via RPMs is the "industry standard"? And this is how we
> > provide fixes for any issues - and even features and
> > enhancements, if there is a critical mass of customers
> > requesting this.
> >
> > 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)
> >
> 
> 
> 
> -- 
> 
> 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



-- 
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 mge at suse.com  Mon May 19 02:22:35 2014
From: mge at suse.com (Matthias G. Eckermann)
Date: Mon, 19 May 2014 10:22:35 +0200
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <1400486904.19291.8.camel@ibrokeit.suse.de>
References: <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>
	<CAEUhfEdU-z5YUhxtr7S_V0Or9uHg-4UTfUPL1AMMX_-GSSE4zg@mail.gmail.com>
	<20140519071119.GB4421@suse.com>
	<CAEUhfEdQP9PwGNrPgfnFx8isB4CcgCCpdeXMqQJrd6sndHjYzA@mail.gmail.com>
	<1400486904.19291.8.camel@ibrokeit.suse.de>
Message-ID: <20140519082235.GD9787@suse.com>

Hello Darren, Richard and all,

On 2014-05-19 T 10:08 +0200 Richard Brown wrote:

> > My "normal" build/workflow is more like:
> > 
> > 1. Install server (either from Install media of via
> > a pre-configured "install server" on-site that has
> > the installation media content).
> > 2. Verify that the server is running correctly and
> > no obvious hardware/software issue are encountered.
> > 3. Local customisations/configurations are applied
> > 4. Register server to SMT server (I know that ZCM
> > and/Or SUSE Manager could be used, but that is not
> > my "normal" workflow), apply all "know good"
> > patches.
> > 5. Go to Novell Customer Centre Portal and ensure
> > that server has registered there (it normally is
> > proxy registered through SMT).
> > 
> > In a lot of cases, these server do not and never
> > have direct internet access so cannot do the
> > registration or on-line patching driectly.
> 
> Can you explain to me the problems with the workflow
> I propose below?  This is how I'd imagine you'd
> accomplish the equivalent workflow with SLE 12:
> 
> 1. Install Server (either from Install media or via
> pre-configured "install server")
> 2. During installation, register with SMT Server
> 3. Do not opt to patch during installation (the
> option is presented as soon as you register)
> 4. Add Extensions/Modules as required - will be
> included in the installation and pulled from SMT
> 5. Verify server is running correctly
> 6. Local customisations/configurations
> 7. Patch with "known good" patches from SMT
> 8. Go to SUSE Customer Center and ensure the server
> has registered there
> 
> While in terms of 'number of steps' the above process
> may seem more, but in reality I think you'd find the
> 'real work' about the same

I claim that the new process is even shorter (see my
E-Mail just a minute ago), if you take advantage of the
option to apply the patches directly during the initial
installation. That's why we have changed the
installation workflow and removed the "second stage".

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 mge at suse.com  Mon May 19 03:51:06 2014
From: mge at suse.com (Matthias G. Eckermann)
Date: Mon, 19 May 2014 11:51:06 +0200
Subject: [sles-beta] Antwort: Re:  php disappeared in beta6?
In-Reply-To: <OF115EC1CF.ABCAEFB2-ONC1257CDA.0032B80D-C1257CDA.0033B2E3@dachser.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>
	<OF115EC1CF.ABCAEFB2-ONC1257CDA.0032B80D-C1257CDA.0033B2E3@dachser.com>
Message-ID: <20140519095106.GA11674@suse.com>

Hello Christian and all,

On 2014-05-16 T 11:24 +0200 Christian Woertz wrote:
 
> thanks for the information regarding SMT, but as we
> use ZCM for installation/updates, what is the time
> line there for the module integration?

at the moment, we are actively working in updating our
tools, namely SMT and SUSE Manager, to work with SUSE
Customer Center (SCC) and the additional/new APIs, as
discussed in the other E-Mails.

Any additional tools for mirroring SUSE Linux Enterprise
packages and patches should rely on the APIs provided.

Please contact you Novell account manager for further
info regarding ZCM.

HTH -
so long -
	MgE

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

From fcrozat at suse.com  Mon May 19 04:40:05 2014
From: fcrozat at suse.com (Frederic Crozat)
Date: Mon, 19 May 2014 12:40:05 +0200
Subject: [sles-beta] YAST2 apps through SSH
In-Reply-To: <20140519092332.16be7d91@linux-5mqx.site>
References: <CAEUhfEfsSjK91Pxkd_GkF7kcymAuaps3EHwNdQXBuYg292UjyA@mail.gmail.com>
	<CAEUhfEfvH2tk0qjrMecwz6pfHu7MmAjVsWX7ovAKrYjTRLN1ow@mail.gmail.com>
	<20140519092332.16be7d91@linux-5mqx.site>
Message-ID: <1400496005.2238.3.camel@par-r81vxc7.par.novell.com>

Le lundi 19 mai 2014 ? 09:23 +0200, Josef Reidinger a ?crit :
> On Mon, 19 May 2014 14:11:15 +1000
> "Darren Thompson" <darrent at akurit.com.au> wrote:
> 
> > 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
> > 
> 
> I recommend to report SR and attach yast logs for it. It is possible to
> be related to qt5 usage for GUI which have in some scenarios still some
> problems on which we work.

I've have integrated some fixes regarding similar issue for next beta
but a SR will be great of course.

-- 
Frederic Crozat
Project Manager Enterprise Desktop
SUSE


From gjn at gjn.priv.at  Mon May 19 07:46:35 2014
From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer)
Date: Mon, 19 May 2014 15:46:35 +0200
Subject: [sles-beta] SCC Broken ?
Message-ID: <28015455.3SP3Fr4YQZ@gjn.priv.at>

Hello,

I have same Day ago installed and Register my Test System

Now all repository like to have a Username and Password it is also not 
Possible to Re-Register, the Tool crash the same with Repository Manager?

I witch file is the Registration, to delete the repository for a new 
Registration?
-- 
mit freundlichen Gr??en / best Regards,

  G?nther J. Niederwimmer

From sarsene at suse.com  Mon May 19 08:23:50 2014
From: sarsene at suse.com (Simona Arsene)
Date: Mon, 19 May 2014 16:23:50 +0200
Subject: [sles-beta] SCC Broken ?
In-Reply-To: <28015455.3SP3Fr4YQZ@gjn.priv.at>
References: <28015455.3SP3Fr4YQZ@gjn.priv.at>
Message-ID: <537A30160200002200170745@smtp.nue.novell.com>

Hi G?nther, 

>>> On 5/19/2014 at 03:46 PM, in message <28015455.3SP3Fr4YQZ at gjn.priv.at>,
G?nther J.Niederwimmer <gjn at gjn.priv.at> wrote: 
> Hello,
>  
> I have same Day ago installed and Register my Test System
>  
> Now all repository like to have a Username and Password it is also not  
> Possible to Re-Register, the Tool crash the same with Repository Manager?
>  
> I witch file is the Registration, to delete the repository for a new  
> Registration? 

Unfortunately, we're facing some issues at the moment, but the teams here 
are working together to fix them. 

If you can open SR and add the log file, this will help us better understand 
your issue. 

Simona 

From darrent at akurit.com.au  Mon May 19 15:29:21 2014
From: darrent at akurit.com.au (Darren Thompson)
Date: Tue, 20 May 2014 07:29:21 +1000
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <1400486904.19291.8.camel@ibrokeit.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>
	<CAEUhfEdU-z5YUhxtr7S_V0Or9uHg-4UTfUPL1AMMX_-GSSE4zg@mail.gmail.com>
	<20140519071119.GB4421@suse.com>
	<CAEUhfEdQP9PwGNrPgfnFx8isB4CcgCCpdeXMqQJrd6sndHjYzA@mail.gmail.com>
	<1400486904.19291.8.camel@ibrokeit.suse.de>
Message-ID: <CAEUhfEf0uxeiioNj+QRd-4a6TQN2_YqYNSHwONkCdYL_0MJFfw@mail.gmail.com>

Richard

Good point and I will concede that the "outcome" seems to be identical.

1. How do you register the sever to SMT during the normal installation
workflow (I seem to have missed the option where you specify the SMT server
URL in that registration form)?
2  Now what about small sites that do not have SMT installed and don;t
allow internet access?
3. Fundamentally, what is "wrong" with assuming the installation media is
sufficient to build a server?

Darren


On 19 May 2014 18:08, Richard Brown <rbrown at suse.de> wrote:

> Hello Darren,
>
> > My "normal" build/workflow is more like:
> >
> >
> > 1. Install server (either from Install media of via a pre-configured
> > "install server" on-site that has the installation media content).
> > 2. Verify that the server is running correctly and no obvious
> > hardware/software issue are encountered.
> > 3. Local customisations/configurations are applied
> > 4. Register server to SMT server (I know that ZCM and/Or SUSE Manager
> > could be used, but that is not my "normal" workflow), apply all "know
> > good" patches.
> > 5. Go to Novell Customer Centre Portal and ensure that server has
> > registered there (it normally is proxy registered through SMT).
> >
> >
> > In a lot of cases, these server do not and never have direct internet
> > access so cannot do the registration or on-line patching driectly.
>
> Can you explain to me the problems with the workflow I propose below?
> This is how I'd imagine you'd accomplish the equivalent workflow with
> SLE 12:
>
> 1. Install Server (either from Install media or via pre-configured
> "install server")
> 2. During installation, register with SMT Server
> 3. Do not opt to patch during installation (the option is presented as
> soon as you register)
> 4. Add Extensions/Modules as required - will be included in the
> installation and pulled from SMT
> 5. Verify server is running correctly
> 6. Local customisations/configurations
> 7. Patch with "known good" patches from SMT
> 8. Go to SUSE Customer Center and ensure the server has registered there
>
> While in terms of 'number of steps' the above process may seem more, but
> in reality I think you'd find the 'real work' about the same
>
> Regards,
>
> 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://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/20140520/c6d4d8db/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/20140520/c6d4d8db/attachment.jpg>

From darrent at akurit.com.au  Mon May 19 15:35:21 2014
From: darrent at akurit.com.au (Darren Thompson)
Date: Tue, 20 May 2014 07:35:21 +1000
Subject: [sles-beta] Antwort: Re: php disappeared in beta6?
In-Reply-To: <20140519095106.GA11674@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>
	<OF115EC1CF.ABCAEFB2-ONC1257CDA.0032B80D-C1257CDA.0033B2E3@dachser.com>
	<20140519095106.GA11674@suse.com>
Message-ID: <CAEUhfEca8SBv-S75066jgfVSJ9dSaNUMNKuc40kZkO0JmRWatg@mail.gmail.com>

We have been here so long we have stopped talking to ourselves....
(Paraphrase of tortoise from "Never Ending Story")


On 19 May 2014 19:51, Matthias G. Eckermann <mge at suse.com> wrote:

> Hello Christian and all,
>
> On 2014-05-16 T 11:24 +0200 Christian Woertz wrote:
>
> > thanks for the information regarding SMT, but as we
> > use ZCM for installation/updates, what is the time
> > line there for the module integration?
>
> at the moment, we are actively working in updating our
> tools, namely SMT and SUSE Manager, to work with SUSE
> Customer Center (SCC) and the additional/new APIs, as
> discussed in the other E-Mails.
>
> Any additional tools for mirroring SUSE Linux Enterprise
> packages and patches should rely on the APIs provided.
>
> Please contact you Novell account manager for further
> info regarding ZCM.
>
> HTH -
> so long -
>         MgE
>
>
> > 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
>



-- 

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

From James.Taylor at eastcobbgroup.com  Mon May 19 15:57:28 2014
From: James.Taylor at eastcobbgroup.com (James Taylor)
Date: Mon, 19 May 2014 17:57:28 -0400
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <CAEUhfEf0uxeiioNj+QRd-4a6TQN2_YqYNSHwONkCdYL_0MJFfw@mail.gmail.com>
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>
	<CAEUhfEdU-z5YUhxtr7S_V0Or9uHg-4UTfUPL1AMMX_-GSSE4zg@mail.gmail.com>
	<20140519071119.GB4421@suse.com>
	<CAEUhfEdQP9PwGNrPgfnFx8isB4CcgCCpdeXMqQJrd6sndHjYzA@mail.gmail.com>
	<1400486904.19291.8.camel@ibrokeit.suse.de>
	<CAEUhfEf0uxeiioNj+QRd-4a6TQN2_YqYNSHwONkCdYL_0MJFfw@mail.gmail.com>
Message-ID: <537A4608020000750004918E@inet.eastcobbgroup.com>

We can argue semantics and logic until we're blue in the face.

The main issue I see here is a clash of two diametrically opposite philosophies.
The first is that your customers should be given the broadest options as to how they adapt your technology to meet their needs in their own environments.
The second is that you know what's best for them, and they should accept and adapt to what you decide they need.

Which do you think is more conducive to a linux based customer scenario?

-jt


James Taylor
678-697-9420
james.taylor at eastcobbgroup.com



>>> Darren Thompson <darrent at akurit.com.au> 5/19/2014 5:29 PM >>> 
Richard

Good point and I will concede that the "outcome" seems to be identical.

1. How do you register the sever to SMT during the normal installation
workflow (I seem to have missed the option where you specify the SMT server
URL in that registration form)?
2  Now what about small sites that do not have SMT installed and don;t
allow internet access?
3. Fundamentally, what is "wrong" with assuming the installation media is
sufficient to build a server?



From darrent at akurit.com.au  Mon May 19 15:59:40 2014
From: darrent at akurit.com.au (Darren Thompson)
Date: Tue, 20 May 2014 07:59:40 +1000
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <537A4608020000750004918E@inet.eastcobbgroup.com>
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>
	<CAEUhfEdU-z5YUhxtr7S_V0Or9uHg-4UTfUPL1AMMX_-GSSE4zg@mail.gmail.com>
	<20140519071119.GB4421@suse.com>
	<CAEUhfEdQP9PwGNrPgfnFx8isB4CcgCCpdeXMqQJrd6sndHjYzA@mail.gmail.com>
	<1400486904.19291.8.camel@ibrokeit.suse.de>
	<CAEUhfEf0uxeiioNj+QRd-4a6TQN2_YqYNSHwONkCdYL_0MJFfw@mail.gmail.com>
	<537A4608020000750004918E@inet.eastcobbgroup.com>
Message-ID: <CAEUhfEf3XPJrVMmUnqenSo5ptbm6jOwQU11Bj=i5Ek7kQM10wQ@mail.gmail.com>

James

Agreed, however my workflow worked correctly before the new SLES12 workflow
so it could also be argued that you have introduced a regression from
accepted normal behaviour.

Darren


On 20 May 2014 07:57, James Taylor <James.Taylor at eastcobbgroup.com> wrote:

> We can argue semantics and logic until we're blue in the face.
>
> The main issue I see here is a clash of two diametrically opposite
> philosophies.
> The first is that your customers should be given the broadest options as
> to how they adapt your technology to meet their needs in their own
> environments.
> The second is that you know what's best for them, and they should accept
> and adapt to what you decide they need.
>
> Which do you think is more conducive to a linux based customer scenario?
>
> -jt
>
>
> James Taylor
> 678-697-9420
> james.taylor at eastcobbgroup.com
>
>
>
> >>> Darren Thompson <darrent at akurit.com.au> 5/19/2014 5:29 PM >>>
> Richard
>
> Good point and I will concede that the "outcome" seems to be identical.
>
> 1. How do you register the sever to SMT during the normal installation
> workflow (I seem to have missed the option where you specify the SMT server
> URL in that registration form)?
> 2  Now what about small sites that do not have SMT installed and don;t
> allow internet access?
> 3. Fundamentally, what is "wrong" with assuming the installation media is
> sufficient to build a server?
>
>
> _______________________________________________
> 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/20140520/f319e278/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/20140520/f319e278/attachment.jpg>

From darrent at akurit.com.au  Mon May 19 16:08:51 2014
From: darrent at akurit.com.au (Darren Thompson)
Date: Tue, 20 May 2014 08:08:51 +1000
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <537A4608020000750004918E@inet.eastcobbgroup.com>
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>
	<CAEUhfEdU-z5YUhxtr7S_V0Or9uHg-4UTfUPL1AMMX_-GSSE4zg@mail.gmail.com>
	<20140519071119.GB4421@suse.com>
	<CAEUhfEdQP9PwGNrPgfnFx8isB4CcgCCpdeXMqQJrd6sndHjYzA@mail.gmail.com>
	<1400486904.19291.8.camel@ibrokeit.suse.de>
	<CAEUhfEf0uxeiioNj+QRd-4a6TQN2_YqYNSHwONkCdYL_0MJFfw@mail.gmail.com>
	<537A4608020000750004918E@inet.eastcobbgroup.com>
Message-ID: <CAEUhfEc96_FB5-FhoK0u_Y0Tk0g0-j8f=jZdKXrJkCXwsTLspg@mail.gmail.com>

Lets do a competitive comparison

Feature
               SLES12+                          REL
Can be installed without internet access
      -                                   Yes
Installable from supplied media without additional Infrastructure         -
                                  Yes


All previous versions of SLES...

Feature
               <SLES12                          REL
Can be installed without internet access
     Yes                               Yes
Installable from supplied media without additional Infrastructure
 Yes                               Yes

I'm in the "Pro SLES" camp and I can see how this could be spun as a
negative, imagine what the real marketing teams of your competitors will do
with this new requirment...

OK, I'll shut up about this now...

Darren



On 20 May 2014 07:57, James Taylor <James.Taylor at eastcobbgroup.com> wrote:

> We can argue semantics and logic until we're blue in the face.
>
> The main issue I see here is a clash of two diametrically opposite
> philosophies.
> The first is that your customers should be given the broadest options as
> to how they adapt your technology to meet their needs in their own
> environments.
> The second is that you know what's best for them, and they should accept
> and adapt to what you decide they need.
>
> Which do you think is more conducive to a linux based customer scenario?
>
> -jt
>
>
> James Taylor
> 678-697-9420
> james.taylor at eastcobbgroup.com
>
>
>
> >>> Darren Thompson <darrent at akurit.com.au> 5/19/2014 5:29 PM >>>
> Richard
>
> Good point and I will concede that the "outcome" seems to be identical.
>
> 1. How do you register the sever to SMT during the normal installation
> workflow (I seem to have missed the option where you specify the SMT server
> URL in that registration form)?
> 2  Now what about small sites that do not have SMT installed and don;t
> allow internet access?
> 3. Fundamentally, what is "wrong" with assuming the installation media is
> sufficient to build a server?
>
>
> _______________________________________________
> 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/20140520/bddf464c/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/20140520/bddf464c/attachment.jpg>

From rbrown at suse.de  Tue May 20 02:45:29 2014
From: rbrown at suse.de (Richard Brown)
Date: Tue, 20 May 2014 10:45:29 +0200
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <CAEUhfEf0uxeiioNj+QRd-4a6TQN2_YqYNSHwONkCdYL_0MJFfw@mail.gmail.com>
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>
	<CAEUhfEdU-z5YUhxtr7S_V0Or9uHg-4UTfUPL1AMMX_-GSSE4zg@mail.gmail.com>
	<20140519071119.GB4421@suse.com>
	<CAEUhfEdQP9PwGNrPgfnFx8isB4CcgCCpdeXMqQJrd6sndHjYzA@mail.gmail.com>
	<1400486904.19291.8.camel@ibrokeit.suse.de>
	<CAEUhfEf0uxeiioNj+QRd-4a6TQN2_YqYNSHwONkCdYL_0MJFfw@mail.gmail.com>
Message-ID: <1400575529.19291.46.camel@ibrokeit.suse.de>

Darren,

On Tue, 2014-05-20 at 07:29 +1000, Darren Thompson wrote:
> Richard
> 
> 
> Good point and I will concede that the "outcome" seems to be
> identical.
> 
> 
> 1. How do you register the sever to SMT during the normal installation
> workflow (I seem to have missed the option where you specify the SMT
> server URL in that registration form)?

It is my understanding (ie. do not consider this official or certain by
any means..speculation only!) that the forthcoming updates to SMT and
SUSE Manager will include a mechanism by which SLE 12 machines are able
to auto detect the presence of a nearby SMT/Manager machine.

I understand that the results of this auto detection are presented at
the point of registration (before SCC is contacted) with the user able
to choose to register against SMT/Manager instead

> 2  Now what about small sites that do not have SMT installed and don;t
> allow internet access

That's a good question, but it leads me to ask another one - how is this
small site expecting to patch their system?

Whatever the answer is to that question, is how I expect them to be able
to add the Module to their system.

One of the recurring trends in this discussion appears to be a
reluctance to install patches. I find this baffling. I understand the
realities of System Administration, having done it for over 10 years and
never managing to patch everything as fast as I wanted to, but I still
patch, and patch regularly.

This isn't just a counter to product defects and quirky scenarios, but
very real and ever present security risks - the kind of thing that
potential miscreants can and will try to use to get into your precious
SLE Server, regardless of whether it's Internet connected or 'just' on
your LAN. 
Heartbleed might not have impacted SLE 11, but there is always a chance
that the 'next big scare' could. Can you patch your systems fast enough?

I think it's probably safe to say that it is an assumption by myself and
my colleagues at SUSE that every one of our customers is going to patch
their machines, at least sometimes. That is, after all, something
customers are paying us for - the timely provision of tested patches for
the platform.

Modules (especially the Web Scripting Module which spawned this
discussion), fit into that assumption. You really don't want to run an
old version of PHP, do you?

> 3. Fundamentally, what is "wrong" with assuming the installation media
> is sufficient to build a server?

Nothing, but conversely, what is fundamentally wrong with assuming that
there is some mechanism available for patching, and using that as the
primary method of delivering a small subset of packages?
Especially when that small subset of packages is a fast-moving,
often-attacked, web software stack, where customers are likely to want
regular updates for both new features and security patches?

Regards,
	- 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 pieter.hollants at dfs.de  Tue May 20 03:06:47 2014
From: pieter.hollants at dfs.de (Pieter Hollants)
Date: Tue, 20 May 2014 09:06:47 +0000
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <1400575529.19291.46.camel@ibrokeit.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>
	<CAEUhfEdU-z5YUhxtr7S_V0Or9uHg-4UTfUPL1AMMX_-GSSE4zg@mail.gmail.com>
	<20140519071119.GB4421@suse.com>
	<CAEUhfEdQP9PwGNrPgfnFx8isB4CcgCCpdeXMqQJrd6sndHjYzA@mail.gmail.com>
	<1400486904.19291.8.camel@ibrokeit.suse.de>
	<CAEUhfEf0uxeiioNj+QRd-4a6TQN2_YqYNSHwONkCdYL_0MJFfw@mail.gmail.com>
	<1400575529.19291.46.camel@ibrokeit.suse.de>
Message-ID: <d06291f3bef74ea3b9eced06105b8a35@LGNMSXA01.prod.bk.dfs>

Pardon if I draw into reality again but as your said yourself, it's an _assumption_ that it would be naturally in every site's interest to install patches as fast as possible. And that very assumption does not hold true for most of our safety-relevant ATC systems (and likely for other high security sites as well).

As said before, by regulation and standards EVERY change, no matter how large or small, is subject to an intensive testing process that takes weeks to months. There is no such thing as "we trust our OS vendor, let's just click through these patches". And before someone points to the obvious contradiction of running unpatched systems: these systems have no external network connectivity whatsoever except serial interfaces and "enjoy" physical protection in such a way that even we as OS integrators have no access to the facilities (ie. no chance for live debugging). And yes, much of this is pretty braindead but it's the way things are for any near time to come.

So again, we need ISOs with defined content. Feel free to offer up-to-date {PHP,Python,Ruby} in separate repos with separate support policy but keep a base version on the installation media.

-----Urspr?ngliche Nachricht-----
Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Richard Brown
Gesendet: Dienstag, 20. Mai 2014 10:45
An: Darren Thompson
Cc: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] php disappeared in beta6?

Darren,

On Tue, 2014-05-20 at 07:29 +1000, Darren Thompson wrote:
> Richard
> 
> 
> Good point and I will concede that the "outcome" seems to be 
> identical.
> 
> 
> 1. How do you register the sever to SMT during the normal installation 
> workflow (I seem to have missed the option where you specify the SMT 
> server URL in that registration form)?

It is my understanding (ie. do not consider this official or certain by any means..speculation only!) that the forthcoming updates to SMT and SUSE Manager will include a mechanism by which SLE 12 machines are able to auto detect the presence of a nearby SMT/Manager machine.

I understand that the results of this auto detection are presented at the point of registration (before SCC is contacted) with the user able to choose to register against SMT/Manager instead

> 2  Now what about small sites that do not have SMT installed and don;t 
> allow internet access

That's a good question, but it leads me to ask another one - how is this small site expecting to patch their system?

Whatever the answer is to that question, is how I expect them to be able to add the Module to their system.

One of the recurring trends in this discussion appears to be a reluctance to install patches. I find this baffling. I understand the realities of System Administration, having done it for over 10 years and never managing to patch everything as fast as I wanted to, but I still patch, and patch regularly.

This isn't just a counter to product defects and quirky scenarios, but very real and ever present security risks - the kind of thing that potential miscreants can and will try to use to get into your precious SLE Server, regardless of whether it's Internet connected or 'just' on your LAN. 
Heartbleed might not have impacted SLE 11, but there is always a chance that the 'next big scare' could. Can you patch your systems fast enough?

I think it's probably safe to say that it is an assumption by myself and my colleagues at SUSE that every one of our customers is going to patch their machines, at least sometimes. That is, after all, something customers are paying us for - the timely provision of tested patches for the platform.

Modules (especially the Web Scripting Module which spawned this discussion), fit into that assumption. You really don't want to run an old version of PHP, do you?

> 3. Fundamentally, what is "wrong" with assuming the installation media 
> is sufficient to build a server?

Nothing, but conversely, what is fundamentally wrong with assuming that there is some mechanism available for patching, and using that as the primary method of delivering a small subset of packages?
Especially when that small subset of packages is a fast-moving, often-attacked, web software stack, where customers are likely to want regular updates for both new features and security patches?

Regards,
	- 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://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 jrd at netlab1.net  Tue May 20 04:02:29 2014
From: jrd at netlab1.net (Joe Doupnik)
Date: Tue, 20 May 2014 11:02:29 +0100
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <d06291f3bef74ea3b9eced06105b8a35@LGNMSXA01.prod.bk.dfs>
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>	<CAEUhfEdU-z5YUhxtr7S_V0Or9uHg-4UTfUPL1AMMX_-GSSE4zg@mail.gmail.com>	<20140519071119.GB4421@suse.com>	<CAEUhfEdQP9PwGNrPgfnFx8isB4CcgCCpdeXMqQJrd6sndHjYzA@mail.gmail.com>	<1400486904.19291.8.camel@ibrokeit.suse.de>	<CAEUhfEf0uxeiioNj+QRd-4a6TQN2_YqYNSHwONkCdYL_0MJFfw@mail.gmail.com>	<1400575529.19291.46.camel@ibrokeit.suse.de>
	<d06291f3bef74ea3b9eced06105b8a35@LGNMSXA01.prod.bk.dfs>
Message-ID: <537B2835.5030303@netlab1.net>

     As I review this thread I see two views, one certain and the other 
speculatively inferred.
     One is the patch-now approach pervades SUSE's comments, versus the 
patch-if&when-appropriate of many customer comments.
     The speculative one is hinted at in Matthias' recent comments, 
which is parts of SUSE really want SLE* to be tied to their 
SCC/SMT/Manager tool suites and are removing components to ensure this 
happens. I cannot understand otherwise the removal aspect.
     Joe D.

On 20/05/2014 10:06, Pieter Hollants wrote:
> Pardon if I draw into reality again but as your said yourself, it's an _assumption_ that it would be naturally in every site's interest to install patches as fast as possible. And that very assumption does not hold true for most of our safety-relevant ATC systems (and likely for other high security sites as well).
>
> As said before, by regulation and standards EVERY change, no matter how large or small, is subject to an intensive testing process that takes weeks to months. There is no such thing as "we trust our OS vendor, let's just click through these patches". And before someone points to the obvious contradiction of running unpatched systems: these systems have no external network connectivity whatsoever except serial interfaces and "enjoy" physical protection in such a way that even we as OS integrators have no access to the facilities (ie. no chance for live debugging). And yes, much of this is pretty braindead but it's the way things are for any near time to come.
>
> So again, we need ISOs with defined content. Feel free to offer up-to-date {PHP,Python,Ruby} in separate repos with separate support policy but keep a base version on the installation media.
>
> -----Urspr?ngliche Nachricht-----
> Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Richard Brown
> Gesendet: Dienstag, 20. Mai 2014 10:45
> An: Darren Thompson
> Cc: sles-beta at lists.suse.com
> Betreff: Re: [sles-beta] php disappeared in beta6?
>
> Darren,
>
> On Tue, 2014-05-20 at 07:29 +1000, Darren Thompson wrote:
>> Richard
>>
>>
>> Good point and I will concede that the "outcome" seems to be
>> identical.
>>
>>
>> 1. How do you register the sever to SMT during the normal installation
>> workflow (I seem to have missed the option where you specify the SMT
>> server URL in that registration form)?
> It is my understanding (ie. do not consider this official or certain by any means..speculation only!) that the forthcoming updates to SMT and SUSE Manager will include a mechanism by which SLE 12 machines are able to auto detect the presence of a nearby SMT/Manager machine.
>
> I understand that the results of this auto detection are presented at the point of registration (before SCC is contacted) with the user able to choose to register against SMT/Manager instead
>
>> 2  Now what about small sites that do not have SMT installed and don;t
>> allow internet access
> That's a good question, but it leads me to ask another one - how is this small site expecting to patch their system?
>
> Whatever the answer is to that question, is how I expect them to be able to add the Module to their system.
>
> One of the recurring trends in this discussion appears to be a reluctance to install patches. I find this baffling. I understand the realities of System Administration, having done it for over 10 years and never managing to patch everything as fast as I wanted to, but I still patch, and patch regularly.
>
> This isn't just a counter to product defects and quirky scenarios, but very real and ever present security risks - the kind of thing that potential miscreants can and will try to use to get into your precious SLE Server, regardless of whether it's Internet connected or 'just' on your LAN.
> Heartbleed might not have impacted SLE 11, but there is always a chance that the 'next big scare' could. Can you patch your systems fast enough?
>
> I think it's probably safe to say that it is an assumption by myself and my colleagues at SUSE that every one of our customers is going to patch their machines, at least sometimes. That is, after all, something customers are paying us for - the timely provision of tested patches for the platform.
>
> Modules (especially the Web Scripting Module which spawned this discussion), fit into that assumption. You really don't want to run an old version of PHP, do you?
>
>> 3. Fundamentally, what is "wrong" with assuming the installation media
>> is sufficient to build a server?
> Nothing, but conversely, what is fundamentally wrong with assuming that there is some mechanism available for patching, and using that as the primary method of delivering a small subset of packages?
> Especially when that small subset of packages is a fast-moving, often-attacked, web software stack, where customers are likely to want regular updates for both new features and security patches?
>
> Regards,
> 	- 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://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 kdupke at suse.com  Tue May 20 04:17:23 2014
From: kdupke at suse.com (Kai Dupke)
Date: Tue, 20 May 2014 12:17:23 +0200
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <537B2835.5030303@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>	<20140518111050.GF4368@suse.de>	<CAEUhfEdU-z5YUhxtr7S_V0Or9uHg-4UTfUPL1AMMX_-GSSE4zg@mail.gmail.com>	<20140519071119.GB4421@suse.com>	<CAEUhfEdQP9PwGNrPgfnFx8isB4CcgCCpdeXMqQJrd6sndHjYzA@mail.gmail.com>	<1400486904.19291.8.camel@ibrokeit.suse.de>	<CAEUhfEf0uxeiioNj+QRd-4a6TQN2_YqYNSHwONkCdYL_0MJFfw@mail.gmail.com>	<1400575529.19291.46.camel@ibrokeit.suse.de>	<d06291f3bef74ea3b9eced06105b8a35@LGNMSXA01.prod.bk.dfs>
	<537B2835.5030303@netlab1.net>
Message-ID: <537B2BB3.7060807@suse.com>

On 05/20/2014 12:02 PM, Joe Doupnik wrote:
> I cannot understand otherwise the removal aspect.

It's not about removal of something but about to provide more.

More up-to-date version of PHP for example, as requested by many customers.

Having such on-line makes it much more convenient to provide such with a
recent patch level.

I have understood that some of you seeing difficulties in using such
repositories, don't want to interfere with this discussion, but wanted
to answer this assumption.

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 okir at suse.de  Tue May 20 04:36:15 2014
From: okir at suse.de (Olaf Kirch)
Date: Tue, 20 May 2014 12:36:15 +0200
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <4c3641b0b0a84805b7fb10afe11b1cb2@LGNMSXA01.prod.bk.dfs>
References: <20140514153539.GC11257@sgi.com> <20140514211427.GA5102@suse.com>
	<4c3641b0b0a84805b7fb10afe11b1cb2@LGNMSXA01.prod.bk.dfs>
Message-ID: <201405201236.15141.okir@suse.de>


Hi Pieter,

On Thursday 15 May 2014 11:46:46 Pieter Hollants wrote:
> 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.

Would it help these use cases if we document how to take a copy of the 
repo, and create an ISO from that which is recognized by the 
installer?

Olaf

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

-- 
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 jrd at netlab1.net  Tue May 20 04:57:30 2014
From: jrd at netlab1.net (Joe Doupnik)
Date: Tue, 20 May 2014 11:57:30 +0100
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <537B2BB3.7060807@suse.com>
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>	<CAEUhfEdU-z5YUhxtr7S_V0Or9uHg-4UTfUPL1AMMX_-GSSE4zg@mail.gmail.com>	<20140519071119.GB4421@suse.com>	<CAEUhfEdQP9PwGNrPgfnFx8isB4CcgCCpdeXMqQJrd6sndHjYzA@mail.gmail.com>	<1400486904.19291.8.camel@ibrokeit.suse.de>	<CAEUhfEf0uxeiioNj+QRd-4a6TQN2_YqYNSHwONkCdYL_0MJFfw@mail.gmail.com>	<1400575529.19291.46.camel@ibrokeit.suse.de>	<d06291f3bef74ea3b9eced06105b8a35@LGNMSXA01.prod.bk.dfs>	<537B2835.5030303@netlab1.net>
	<537B2BB3.7060807@suse.com>
Message-ID: <537B351A.7040409@netlab1.net>

     Thanks for chiming in Kai. Your comments simply reinforce what I 
speculated about. Removal has nothing, nada, to do with offering more, 
as anyone can see at first glance. It has everything to do with the 
people who want customers to use the "more" facility. Thus the attempts 
at gloss and justification continue.

     While here, addressing points by Richard Brown today. Auto 
discovery of services is basically "designed to fail." One would not 
want that rating in one's engineering copybook.
     Broadcast/multicast are normally terminated at routers, often 
terminated upon entry to servers as well. A person/box which naively 
believes what arrives from goodness knows where gets what they deserve. 
The broad/multicast approach went out more than 20 years ago when MS 
Windows and Novell IPX traffic flooded our networks.
     May I recommend sound engineering practice here, unicast using 
known destinations. No "Click Here" for our servers.
     Joe D.

On 20/05/2014 11:17, Kai Dupke wrote:
> On 05/20/2014 12:02 PM, Joe Doupnik wrote:
>> I cannot understand otherwise the removal aspect.
> It's not about removal of something but about to provide more.
>
> More up-to-date version of PHP for example, as requested by many customers.
>
> Having such on-line makes it much more convenient to provide such with a
> recent patch level.
>
> I have understood that some of you seeing difficulties in using such
> repositories, don't want to interfere with this discussion, but wanted
> to answer this assumption.
>
> greetings
> Kai Dupke
> Senior Product Manager
> Server Product Line


From jreidinger at suse.com  Tue May 20 05:05:28 2014
From: jreidinger at suse.com (Josef Reidinger)
Date: Tue, 20 May 2014 13:05:28 +0200
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <537B351A.7040409@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> <20140518111050.GF4368@suse.de>
	<CAEUhfEdU-z5YUhxtr7S_V0Or9uHg-4UTfUPL1AMMX_-GSSE4zg@mail.gmail.com>
	<20140519071119.GB4421@suse.com>
	<CAEUhfEdQP9PwGNrPgfnFx8isB4CcgCCpdeXMqQJrd6sndHjYzA@mail.gmail.com>
	<1400486904.19291.8.camel@ibrokeit.suse.de>
	<CAEUhfEf0uxeiioNj+QRd-4a6TQN2_YqYNSHwONkCdYL_0MJFfw@mail.gmail.com>
	<1400575529.19291.46.camel@ibrokeit.suse.de>
	<d06291f3bef74ea3b9eced06105b8a35@LGNMSXA01.prod.bk.dfs>
	<537B2835.5030303@netlab1.net> <537B2BB3.7060807@suse.com>
	<537B351A.7040409@netlab1.net>
Message-ID: <20140520130528.3ed8e9d4@dhcp150.suse.cz>

On Tue, 20 May 2014 11:57:30 +0100
"Joe Doupnik" <jrd at netlab1.net> wrote:

>      Thanks for chiming in Kai. Your comments simply reinforce what I 
> speculated about. Removal has nothing, nada, to do with offering
> more, as anyone can see at first glance. It has everything to do with
> the people who want customers to use the "more" facility. Thus the
> attempts at gloss and justification continue.
> 
>      While here, addressing points by Richard Brown today. Auto 
> discovery of services is basically "designed to fail." One would not 
> want that rating in one's engineering copybook.
>      Broadcast/multicast are normally terminated at routers, often 
> terminated upon entry to servers as well. A person/box which naively 
> believes what arrives from goodness knows where gets what they
> deserve. The broad/multicast approach went out more than 20 years ago
> when MS Windows and Novell IPX traffic flooded our networks.
>      May I recommend sound engineering practice here, unicast using 
> known destinations. No "Click Here" for our servers.
>      Joe D.
> 

Well, we use well known
SLP protocol ( http://en.wikipedia.org/wiki/Service_Location_Protocol )
and it do multicasting. If SLP (multicasting) is disabled in your
network, then you still can pass on boot command line url to such
server. So I hope even super paranoic networks should work fine.
Of course there can be bugs, but I think general design is not bad.

Josef

From lmb at suse.com  Tue May 20 05:12:17 2014
From: lmb at suse.com (Lars Marowsky-Bree)
Date: Tue, 20 May 2014 13:12:17 +0200
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <537B351A.7040409@netlab1.net>
References: <CAEUhfEdU-z5YUhxtr7S_V0Or9uHg-4UTfUPL1AMMX_-GSSE4zg@mail.gmail.com>
	<20140519071119.GB4421@suse.com>
	<CAEUhfEdQP9PwGNrPgfnFx8isB4CcgCCpdeXMqQJrd6sndHjYzA@mail.gmail.com>
	<1400486904.19291.8.camel@ibrokeit.suse.de>
	<CAEUhfEf0uxeiioNj+QRd-4a6TQN2_YqYNSHwONkCdYL_0MJFfw@mail.gmail.com>
	<1400575529.19291.46.camel@ibrokeit.suse.de>
	<d06291f3bef74ea3b9eced06105b8a35@LGNMSXA01.prod.bk.dfs>
	<537B2835.5030303@netlab1.net> <537B2BB3.7060807@suse.com>
	<537B351A.7040409@netlab1.net>
Message-ID: <20140520111217.GA2882@suse.de>

On 2014-05-20T11:57:30, Joe Doupnik <jrd at netlab1.net> wrote:

>     Thanks for chiming in Kai. Your comments simply reinforce what I
> speculated about. Removal has nothing, nada, to do with offering more, as
> anyone can see at first glance. It has everything to do with the people who
> want customers to use the "more" facility. Thus the attempts at gloss and
> justification continue.

Joe, I'm extremely sorry you feel this way, but this is simply not true.

We've heard you that our assumption that every server must have *some*
way of deploying updates to it at install and/or runtime in a
not-too-troublesome way was too strong and will consider what we can do
to make it easier to package/bundle those modules somehow, I'm sure.

(Assuming that some party wants to merely gloss over and/or justify
their process/engineering decisions is a double-edged sword.)


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  Tue May 20 05:18:07 2014
From: jrd at netlab1.net (Joe Doupnik)
Date: Tue, 20 May 2014 12:18:07 +0100
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <20140520130528.3ed8e9d4@dhcp150.suse.cz>
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>	<CAEUhfEdU-z5YUhxtr7S_V0Or9uHg-4UTfUPL1AMMX_-GSSE4zg@mail.gmail.com>	<20140519071119.GB4421@suse.com>	<CAEUhfEdQP9PwGNrPgfnFx8isB4CcgCCpdeXMqQJrd6sndHjYzA@mail.gmail.com>	<1400486904.19291.8.camel@ibrokeit.suse.de>	<CAEUhfEf0uxeiioNj+QRd-4a6TQN2_YqYNSHwONkCdYL_0MJFfw@mail.gmail.com>	<1400575529.19291.46.camel@ibrokeit.suse.de>	<d06291f3bef74ea3b9eced06105b8a35@LGNMSXA01.prod.bk.dfs>	<537B2835.5030303@netlab1.net>
	<537B2BB3.7060807@suse.com>	<537B351A.7040409@netlab1.net>
	<20140520130528.3ed8e9d4@dhcp150.suse.cz>
Message-ID: <537B39EF.6080803@netlab1.net>

On 20/05/2014 12:05, Josef Reidinger wrote:
> On Tue, 20 May 2014 11:57:30 +0100
> "Joe Doupnik" <jrd at netlab1.net> wrote:
>
>>       Thanks for chiming in Kai. Your comments simply reinforce what I
>> speculated about. Removal has nothing, nada, to do with offering
>> more, as anyone can see at first glance. It has everything to do with
>> the people who want customers to use the "more" facility. Thus the
>> attempts at gloss and justification continue.
>>
>>       While here, addressing points by Richard Brown today. Auto
>> discovery of services is basically "designed to fail." One would not
>> want that rating in one's engineering copybook.
>>       Broadcast/multicast are normally terminated at routers, often
>> terminated upon entry to servers as well. A person/box which naively
>> believes what arrives from goodness knows where gets what they
>> deserve. The broad/multicast approach went out more than 20 years ago
>> when MS Windows and Novell IPX traffic flooded our networks.
>>       May I recommend sound engineering practice here, unicast using
>> known destinations. No "Click Here" for our servers.
>>       Joe D.
>>
> Well, we use well known
> SLP protocol ( http://en.wikipedia.org/wiki/Service_Location_Protocol )
> and it do multicasting. If SLP (multicasting) is disabled in your
> network, then you still can pass on boot command line url to such
> server.
      You can't be serious. A server needs booting, and we are supposed 
to remember to add a particular chunky command line in the middle of 
that process? Not likely to be accepted in the field. Nor will be SLP; 
too may variations about its use, and its *cast radar range is severely 
limited at routers.
     Long term experience with SLP indicates that it is best ignored 
entirely. I gave a Brainshare talk on its short comings and offered a 
better design many many years ago.
     Thanks,
     Joe D.


> So I hope even super paranoic networks should work fine.
> Of course there can be bugs, but I think general design is not bad.
>
> Josef
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta


From pieter.hollants at dfs.de  Tue May 20 05:21:39 2014
From: pieter.hollants at dfs.de (Pieter Hollants)
Date: Tue, 20 May 2014 11:21:39 +0000
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <201405201236.15141.okir@suse.de>
References: <20140514153539.GC11257@sgi.com> <20140514211427.GA5102@suse.com>
	<4c3641b0b0a84805b7fb10afe11b1cb2@LGNMSXA01.prod.bk.dfs>
	<201405201236.15141.okir@suse.de>
Message-ID: <d609f589990c4d1bbbaeca0444bb53a1@LGNMSXA01.prod.bk.dfs>

Well, in the end you're transferring more and more packaging work to the end customer, which, at some point, leaves the question why we shouldn't just use CoreOS anyway. Especially considering the fact that you just removed KDE without any recently timely announcement that would have saved us from investing ??? on porting a critical internal project from fvwm to kdm/kwin.

Why so complicated? Why not just leave the medium as it was AND go the modules route for additional/updated packages? That way everyone has a choice and SUSE can fulfill both existing support expections AND requests for newer packages.

-----Urspr?ngliche Nachricht-----
Von: Olaf Kirch [mailto:okir at suse.de] 
Gesendet: Dienstag, 20. Mai 2014 12:36
An: sles-beta at lists.suse.com
Cc: Pieter Hollants; tee at sgi.com; Matthias Eckermann; Allen Beddingfield
Betreff: Re: [sles-beta] php disappeared in beta6?


Hi Pieter,

On Thursday 15 May 2014 11:46:46 Pieter Hollants wrote:
> 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.

Would it help these use cases if we document how to take a copy of the repo, and create an ISO from that which is recognized by the installer?

Olaf

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

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

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 pieter.hollants at dfs.de  Tue May 20 05:24:07 2014
From: pieter.hollants at dfs.de (Pieter Hollants)
Date: Tue, 20 May 2014 11:24:07 +0000
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <537B351A.7040409@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>	<20140518111050.GF4368@suse.de>
	<CAEUhfEdU-z5YUhxtr7S_V0Or9uHg-4UTfUPL1AMMX_-GSSE4zg@mail.gmail.com>
	<20140519071119.GB4421@suse.com>
	<CAEUhfEdQP9PwGNrPgfnFx8isB4CcgCCpdeXMqQJrd6sndHjYzA@mail.gmail.com>
	<1400486904.19291.8.camel@ibrokeit.suse.de>
	<CAEUhfEf0uxeiioNj+QRd-4a6TQN2_YqYNSHwONkCdYL_0MJFfw@mail.gmail.com>
	<1400575529.19291.46.camel@ibrokeit.suse.de>
	<d06291f3bef74ea3b9eced06105b8a35@LGNMSXA01.prod.bk.dfs>
	<537B2835.5030303@netlab1.net>	<537B2BB3.7060807@suse.com>
	<537B351A.7040409@netlab1.net>
Message-ID: <0c8ef4d9ace9454eb87a158496586305@LGNMSXA01.prod.bk.dfs>

For discovery, have a look at "serf" (http://www.serfdom.io/) and "consul" (http://www.consul.io/) together with multicast groups. It doesn't get any easier.

-----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: Dienstag, 20. Mai 2014 12:58
An: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] php disappeared in beta6?

     Thanks for chiming in Kai. Your comments simply reinforce what I speculated about. Removal has nothing, nada, to do with offering more, as anyone can see at first glance. It has everything to do with the people who want customers to use the "more" facility. Thus the attempts at gloss and justification continue.

     While here, addressing points by Richard Brown today. Auto discovery of services is basically "designed to fail." One would not want that rating in one's engineering copybook.
     Broadcast/multicast are normally terminated at routers, often terminated upon entry to servers as well. A person/box which naively believes what arrives from goodness knows where gets what they deserve. 
The broad/multicast approach went out more than 20 years ago when MS Windows and Novell IPX traffic flooded our networks.
     May I recommend sound engineering practice here, unicast using known destinations. No "Click Here" for our servers.
     Joe D.

On 20/05/2014 11:17, Kai Dupke wrote:
> On 05/20/2014 12:02 PM, Joe Doupnik wrote:
>> I cannot understand otherwise the removal aspect.
> It's not about removal of something but about to provide more.
>
> More up-to-date version of PHP for example, as requested by many customers.
>
> Having such on-line makes it much more convenient to provide such with 
> a recent patch level.
>
> I have understood that some of you seeing difficulties in using such 
> repositories, don't want to interfere with this discussion, but wanted 
> to answer this assumption.
>
> greetings
> Kai Dupke
> Senior Product Manager
> Server Product Line

_______________________________________________
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 jreidinger at suse.cz  Tue May 20 05:29:25 2014
From: jreidinger at suse.cz (Josef Reidinger)
Date: Tue, 20 May 2014 13:29:25 +0200
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <537B39EF.6080803@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> <20140518111050.GF4368@suse.de>
	<CAEUhfEdU-z5YUhxtr7S_V0Or9uHg-4UTfUPL1AMMX_-GSSE4zg@mail.gmail.com>
	<20140519071119.GB4421@suse.com>
	<CAEUhfEdQP9PwGNrPgfnFx8isB4CcgCCpdeXMqQJrd6sndHjYzA@mail.gmail.com>
	<1400486904.19291.8.camel@ibrokeit.suse.de>
	<CAEUhfEf0uxeiioNj+QRd-4a6TQN2_YqYNSHwONkCdYL_0MJFfw@mail.gmail.com>
	<1400575529.19291.46.camel@ibrokeit.suse.de>
	<d06291f3bef74ea3b9eced06105b8a35@LGNMSXA01.prod.bk.dfs>
	<537B2835.5030303@netlab1.net> <537B2BB3.7060807@suse.com>
	<537B351A.7040409@netlab1.net>
	<20140520130528.3ed8e9d4@dhcp150.suse.cz>
	<537B39EF.6080803@netlab1.net>
Message-ID: <20140520132925.3a7a16cb@dhcp150.suse.cz>

On Tue, 20 May 2014 12:18:07 +0100
"Joe Doupnik" <jrd at netlab1.net> wrote:

> On 20/05/2014 12:05, Josef Reidinger wrote:
> > On Tue, 20 May 2014 11:57:30 +0100
> > "Joe Doupnik" <jrd at netlab1.net> wrote:
> >
> >>       Thanks for chiming in Kai. Your comments simply reinforce
> >> what I speculated about. Removal has nothing, nada, to do with
> >> offering more, as anyone can see at first glance. It has
> >> everything to do with the people who want customers to use the
> >> "more" facility. Thus the attempts at gloss and justification
> >> continue.
> >>
> >>       While here, addressing points by Richard Brown today. Auto
> >> discovery of services is basically "designed to fail." One would
> >> not want that rating in one's engineering copybook.
> >>       Broadcast/multicast are normally terminated at routers, often
> >> terminated upon entry to servers as well. A person/box which
> >> naively believes what arrives from goodness knows where gets what
> >> they deserve. The broad/multicast approach went out more than 20
> >> years ago when MS Windows and Novell IPX traffic flooded our
> >> networks. May I recommend sound engineering practice here, unicast
> >> using known destinations. No "Click Here" for our servers.
> >>       Joe D.
> >>
> > Well, we use well known
> > SLP protocol
> > ( http://en.wikipedia.org/wiki/Service_Location_Protocol ) and it
> > do multicasting. If SLP (multicasting) is disabled in your network,
> > then you still can pass on boot command line url to such server.
>       You can't be serious. A server needs booting, and we are
> supposed to remember to add a particular chunky command line in the
> middle of that process?

There is probably misunderstanding. You need it only during
installation. For massive installation often is used PXE boot with
predefined parameters. So you need to manually type it only when doing
installation without PXE, without SLP and without registering against
scc.suse.com

> Not likely to be accepted in the field. Nor
> will be SLP; too may variations about its use, and its *cast radar
> range is severely limited at routers.
>      Long term experience with SLP indicates that it is best ignored 
> entirely. I gave a Brainshare talk on its short comings and offered a 
> better design many many years ago.

I wasn't on Brainshare and did not hear your talk. Can you share with us
what is such better design and if is standartized and documented
similar like SLP with its RFCs?

Josef

From jrd at netlab1.net  Tue May 20 05:32:53 2014
From: jrd at netlab1.net (Joe Doupnik)
Date: Tue, 20 May 2014 12:32:53 +0100
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <20140520111217.GA2882@suse.de>
References: <CAEUhfEdU-z5YUhxtr7S_V0Or9uHg-4UTfUPL1AMMX_-GSSE4zg@mail.gmail.com>	<20140519071119.GB4421@suse.com>	<CAEUhfEdQP9PwGNrPgfnFx8isB4CcgCCpdeXMqQJrd6sndHjYzA@mail.gmail.com>	<1400486904.19291.8.camel@ibrokeit.suse.de>	<CAEUhfEf0uxeiioNj+QRd-4a6TQN2_YqYNSHwONkCdYL_0MJFfw@mail.gmail.com>	<1400575529.19291.46.camel@ibrokeit.suse.de>	<d06291f3bef74ea3b9eced06105b8a35@LGNMSXA01.prod.bk.dfs>	<537B2835.5030303@netlab1.net>
	<537B2BB3.7060807@suse.com>	<537B351A.7040409@netlab1.net>
	<20140520111217.GA2882@suse.de>
Message-ID: <537B3D65.3060102@netlab1.net>

Lars,
     We all understand that SUSE is trying to offer improved patch 
services. That is very good. Better engineering seems needed though.
     We do not agree with the compulsive patch now approach. We 
certainly do not agree with the removal approach and have yet to see a 
credible reason for the removals.
     There is no "must" in the patching business. Prudent managers pick 
and choose both content and timing.

     I have a mental picture of today's shopper behaviour: when a Sale! 
sign appears there arises a compulsive desire to Buy Now! Similarly in 
the software world with version chasing.
     Thanks,
     Joe D.

On 20/05/2014 12:12, Lars Marowsky-Bree wrote:
> On 2014-05-20T11:57:30, Joe Doupnik <jrd at netlab1.net> wrote:
>
>>      Thanks for chiming in Kai. Your comments simply reinforce what I
>> speculated about. Removal has nothing, nada, to do with offering more, as
>> anyone can see at first glance. It has everything to do with the people who
>> want customers to use the "more" facility. Thus the attempts at gloss and
>> justification continue.
> Joe, I'm extremely sorry you feel this way, but this is simply not true.
>
> We've heard you that our assumption that every server must have *some*
> way of deploying updates to it at install and/or runtime in a
> not-too-troublesome way was too strong and will consider what we can do
> to make it easier to package/bundle those modules somehow, I'm sure.
>
> (Assuming that some party wants to merely gloss over and/or justify
> their process/engineering decisions is a double-edged sword.)
>
>
> Regards,
>      Lars
>


From jrd at netlab1.net  Tue May 20 07:01:55 2014
From: jrd at netlab1.net (Joe Doupnik)
Date: Tue, 20 May 2014 14:01:55 +0100
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <20140520132925.3a7a16cb@dhcp150.suse.cz>
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>	<CAEUhfEdU-z5YUhxtr7S_V0Or9uHg-4UTfUPL1AMMX_-GSSE4zg@mail.gmail.com>	<20140519071119.GB4421@suse.com>	<CAEUhfEdQP9PwGNrPgfnFx8isB4CcgCCpdeXMqQJrd6sndHjYzA@mail.gmail.com>	<1400486904.19291.8.camel@ibrokeit.suse.de>	<CAEUhfEf0uxeiioNj+QRd-4a6TQN2_YqYNSHwONkCdYL_0MJFfw@mail.gmail.com>	<1400575529.19291.46.camel@ibrokeit.suse.de>	<d06291f3bef74ea3b9eced06105b8a35@LGNMSXA01.prod.bk.dfs>	<537B2835.5030303@netlab1.net>
	<537B2BB3.7060807@suse.com>	<537B351A.7040409@netlab1.net>	<20140520130528.3ed8e9d4@dhcp150.suse.cz>	<537B39EF.6080803@netlab1.net>
	<20140520132925.3a7a16cb@dhcp150.suse.cz>
Message-ID: <537B5243.2070701@netlab1.net>

Josef,
     I have dealt with SLP since it first arose decades ago as a way of 
finding printers with duplex printing and colour.
     First, do not use multicast or broadcast for services. Those are 
dandy on a home/SOHO network. They don't work or survive when routers 
are encountered nor when the local wires have lots of other strange 
things (think running in the rack of an ISP somewhere). It may work in 
one spot but not in the room across the hall (different subnets). Many 
servers reject multi/broadcast traffic. Thus dependence on 
multi/broadcast is to ensure failure, and you designed it that way.
     As stated previously, believing and acting on multi/broadcast 
traffic is naive (at best). It is akin to "Click Here." Sound 
engineering practice does not countenance such acts.
     Second, SLP has the loose notion of SCOPES where both clients and 
servers can rendezvous on one of many SCOPE names. That means 
configuration details, else failure. It does not scale at all. But you 
designed it that way.
     Third, SLP requires existing SLP serving software be running on the 
network and within radar range of all clients. That becomes an 
assumption without which many SLP clients will fail, and you designed it 
that way.
     DNS has the facilities to resolve names to numbers. It scales. It 
is already present. Use unicast to speak to known points.
     These matters were understood about twenty years ago. My Brainshare 
presentation on SLP is long since lost in the mists of time. The above 
points should be sufficient warning to abandon it. Auto discovery is 
designed to fail, as I may have mentioned.
     Joe D.

On 20/05/2014 12:29, Josef Reidinger wrote:
> On Tue, 20 May 2014 12:18:07 +0100
> "Joe Doupnik" <jrd at netlab1.net> wrote:
>
>> On 20/05/2014 12:05, Josef Reidinger wrote:
>>> On Tue, 20 May 2014 11:57:30 +0100
>>> "Joe Doupnik" <jrd at netlab1.net> wrote:
>>>
>>>>        Thanks for chiming in Kai. Your comments simply reinforce
>>>> what I speculated about. Removal has nothing, nada, to do with
>>>> offering more, as anyone can see at first glance. It has
>>>> everything to do with the people who want customers to use the
>>>> "more" facility. Thus the attempts at gloss and justification
>>>> continue.
>>>>
>>>>        While here, addressing points by Richard Brown today. Auto
>>>> discovery of services is basically "designed to fail." One would
>>>> not want that rating in one's engineering copybook.
>>>>        Broadcast/multicast are normally terminated at routers, often
>>>> terminated upon entry to servers as well. A person/box which
>>>> naively believes what arrives from goodness knows where gets what
>>>> they deserve. The broad/multicast approach went out more than 20
>>>> years ago when MS Windows and Novell IPX traffic flooded our
>>>> networks. May I recommend sound engineering practice here, unicast
>>>> using known destinations. No "Click Here" for our servers.
>>>>        Joe D.
>>>>
>>> Well, we use well known
>>> SLP protocol
>>> ( http://en.wikipedia.org/wiki/Service_Location_Protocol ) and it
>>> do multicasting. If SLP (multicasting) is disabled in your network,
>>> then you still can pass on boot command line url to such server.
>>        You can't be serious. A server needs booting, and we are
>> supposed to remember to add a particular chunky command line in the
>> middle of that process?
> There is probably misunderstanding. You need it only during
> installation. For massive installation often is used PXE boot with
> predefined parameters. So you need to manually type it only when doing
> installation without PXE, without SLP and without registering against
> scc.suse.com
>
>> Not likely to be accepted in the field. Nor
>> will be SLP; too may variations about its use, and its *cast radar
>> range is severely limited at routers.
>>       Long term experience with SLP indicates that it is best ignored
>> entirely. I gave a Brainshare talk on its short comings and offered a
>> better design many many years ago.
> I wasn't on Brainshare and did not hear your talk. Can you share with us
> what is such better design and if is standartized and documented
> similar like SLP with its RFCs?
>
> Josef
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta


From lmb at suse.com  Tue May 20 07:05:55 2014
From: lmb at suse.com (Lars Marowsky-Bree)
Date: Tue, 20 May 2014 15:05:55 +0200
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <537B5243.2070701@netlab1.net>
References: <CAEUhfEf0uxeiioNj+QRd-4a6TQN2_YqYNSHwONkCdYL_0MJFfw@mail.gmail.com>
	<1400575529.19291.46.camel@ibrokeit.suse.de>
	<d06291f3bef74ea3b9eced06105b8a35@LGNMSXA01.prod.bk.dfs>
	<537B2835.5030303@netlab1.net> <537B2BB3.7060807@suse.com>
	<537B351A.7040409@netlab1.net>
	<20140520130528.3ed8e9d4@dhcp150.suse.cz>
	<537B39EF.6080803@netlab1.net>
	<20140520132925.3a7a16cb@dhcp150.suse.cz>
	<537B5243.2070701@netlab1.net>
Message-ID: <20140520130555.GE2882@suse.de>

On 2014-05-20T14:01:55, Joe Doupnik <jrd at netlab1.net> wrote:

SLES/SMT *supports* SLP discovery, but I'm pretty sure that it can also
be directly configured with explicit names/addresses and pointed at a
networked installation source. (Or at a local one, CDs, DVD, USB, disk
...)

I'm not sure I follow why this storm arises. Nobody forces you to use
SLP.


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 meissner at suse.de  Tue May 20 07:49:54 2014
From: meissner at suse.de (Marcus Meissner)
Date: Tue, 20 May 2014 15:49:54 +0200
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <537B3D65.3060102@netlab1.net>
References: <CAEUhfEdQP9PwGNrPgfnFx8isB4CcgCCpdeXMqQJrd6sndHjYzA@mail.gmail.com>
	<1400486904.19291.8.camel@ibrokeit.suse.de>
	<CAEUhfEf0uxeiioNj+QRd-4a6TQN2_YqYNSHwONkCdYL_0MJFfw@mail.gmail.com>
	<1400575529.19291.46.camel@ibrokeit.suse.de>
	<d06291f3bef74ea3b9eced06105b8a35@LGNMSXA01.prod.bk.dfs>
	<537B2835.5030303@netlab1.net> <537B2BB3.7060807@suse.com>
	<537B351A.7040409@netlab1.net> <20140520111217.GA2882@suse.de>
	<537B3D65.3060102@netlab1.net>
Message-ID: <20140520134954.GF17401@suse.de>

On Tue, May 20, 2014 at 12:32:53PM +0100, Joe Doupnik wrote:
> Lars,
>     We all understand that SUSE is trying to offer improved patch services. 
> That is very good. Better engineering seems needed though.
>     We do not agree with the compulsive patch now approach. We certainly do 
> not agree with the removal approach and have yet to see a credible reason 
> for the removals.
>     There is no "must" in the patching business. Prudent managers pick and 
> choose both content and timing.
>
>     I have a mental picture of today's shopper behaviour: when a Sale! sign 
> appears there arises a compulsive desire to Buy Now! Similarly in the 
> software world with version chasing.
>     Thanks,
>     Joe D.

I am not sure where the "compulsive patch" thing is coming from.

For supportability concerns we ask you to reproduce issues you have on
the latest update of at least the affected (and potentially dependend)
packages.

We do never (to my knowledge) force you into applying updates except when
opening support issues.

Ciao, Marcus

> On 20/05/2014 12:12, Lars Marowsky-Bree wrote:
>> On 2014-05-20T11:57:30, Joe Doupnik <jrd at netlab1.net> wrote:
>>
>>>      Thanks for chiming in Kai. Your comments simply reinforce what I
>>> speculated about. Removal has nothing, nada, to do with offering more, as
>>> anyone can see at first glance. It has everything to do with the people who
>>> want customers to use the "more" facility. Thus the attempts at gloss and
>>> justification continue.
>> Joe, I'm extremely sorry you feel this way, but this is simply not true.
>>
>> We've heard you that our assumption that every server must have *some*
>> way of deploying updates to it at install and/or runtime in a
>> not-too-troublesome way was too strong and will consider what we can do
>> to make it easier to package/bundle those modules somehow, I'm sure.
>>
>> (Assuming that some party wants to merely gloss over and/or justify
>> their process/engineering decisions is a double-edged sword.)
>>
>>
>> Regards,
>>      Lars
>>
>
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta
>

From jrd at netlab1.net  Tue May 20 08:03:08 2014
From: jrd at netlab1.net (Joe Doupnik)
Date: Tue, 20 May 2014 15:03:08 +0100
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <20140520134954.GF17401@suse.de>
References: <CAEUhfEdQP9PwGNrPgfnFx8isB4CcgCCpdeXMqQJrd6sndHjYzA@mail.gmail.com>
	<1400486904.19291.8.camel@ibrokeit.suse.de>
	<CAEUhfEf0uxeiioNj+QRd-4a6TQN2_YqYNSHwONkCdYL_0MJFfw@mail.gmail.com>
	<1400575529.19291.46.camel@ibrokeit.suse.de>
	<d06291f3bef74ea3b9eced06105b8a35@LGNMSXA01.prod.bk.dfs>
	<537B2835.5030303@netlab1.net> <537B2BB3.7060807@suse.com>
	<537B351A.7040409@netlab1.net> <20140520111217.GA2882@suse.de>
	<537B3D65.3060102@netlab1.net> <20140520134954.GF17401@suse.de>
Message-ID: <537B609C.3000506@netlab1.net>

     Golly, this particular discussion has focused on the SUSE strong 
preference to patch instantly, the removal of some functionality, and 
patching to regain it. If we want what's been removed (PHP so far, 
Matthias will likely tell us more next week) then we are obliged to use 
the patch channels to regain it. In my view all told that's rather 
compelling, or if you prefer coercive.
     As to where this is coming from, it's SUSE, but beyond that we in 
the field do not know and many of us are distinctly unhappy about the 
matter.
     Joe D.

On 20/05/2014 14:49, Marcus Meissner wrote:
> On Tue, May 20, 2014 at 12:32:53PM +0100, Joe Doupnik wrote:
>> Lars,
>>      We all understand that SUSE is trying to offer improved patch services.
>> That is very good. Better engineering seems needed though.
>>      We do not agree with the compulsive patch now approach. We certainly do
>> not agree with the removal approach and have yet to see a credible reason
>> for the removals.
>>      There is no "must" in the patching business. Prudent managers pick and
>> choose both content and timing.
>>
>>      I have a mental picture of today's shopper behaviour: when a Sale! sign
>> appears there arises a compulsive desire to Buy Now! Similarly in the
>> software world with version chasing.
>>      Thanks,
>>      Joe D.
> I am not sure where the "compulsive patch" thing is coming from.
>
> For supportability concerns we ask you to reproduce issues you have on
> the latest update of at least the affected (and potentially dependend)
> packages.
>
> We do never (to my knowledge) force you into applying updates except when
> opening support issues.
>
> Ciao, Marcus
>
>> On 20/05/2014 12:12, Lars Marowsky-Bree wrote:
>>> On 2014-05-20T11:57:30, Joe Doupnik <jrd at netlab1.net> wrote:
>>>
>>>>       Thanks for chiming in Kai. Your comments simply reinforce what I
>>>> speculated about. Removal has nothing, nada, to do with offering more, as
>>>> anyone can see at first glance. It has everything to do with the people who
>>>> want customers to use the "more" facility. Thus the attempts at gloss and
>>>> justification continue.
>>> Joe, I'm extremely sorry you feel this way, but this is simply not true.
>>>
>>> We've heard you that our assumption that every server must have *some*
>>> way of deploying updates to it at install and/or runtime in a
>>> not-too-troublesome way was too strong and will consider what we can do
>>> to make it easier to package/bundle those modules somehow, I'm sure.
>>>
>>> (Assuming that some party wants to merely gloss over and/or justify
>>> their process/engineering decisions is a double-edged sword.)
>>>
>>>
>>> Regards,
>>>       Lars
>>>
>> _______________________________________________
>> sles-beta mailing list
>> sles-beta at lists.suse.com
>> http://lists.suse.com/mailman/listinfo/sles-beta
>>


From mge at suse.com  Tue May 20 08:19:16 2014
From: mge at suse.com (Matthias G. Eckermann)
Date: Tue, 20 May 2014 16:19:16 +0200
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <537B609C.3000506@netlab1.net>
References: <CAEUhfEf0uxeiioNj+QRd-4a6TQN2_YqYNSHwONkCdYL_0MJFfw@mail.gmail.com>
	<1400575529.19291.46.camel@ibrokeit.suse.de>
	<d06291f3bef74ea3b9eced06105b8a35@LGNMSXA01.prod.bk.dfs>
	<537B2835.5030303@netlab1.net> <537B2BB3.7060807@suse.com>
	<537B351A.7040409@netlab1.net> <20140520111217.GA2882@suse.de>
	<537B3D65.3060102@netlab1.net> <20140520134954.GF17401@suse.de>
	<537B609C.3000506@netlab1.net>
Message-ID: <20140520141916.GD15986@suse.com>

Hello Joe and all,

On 2014-05-20 T 15:03 +0100 Joe Doupnik wrote:

> [...] If we want what's been removed [...]

have you considered that we are doing this to be able
to "add" - in a more flexible manner than we could do
in the past?

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 fcrozat at suse.com  Tue May 20 08:43:10 2014
From: fcrozat at suse.com (Frederic Crozat)
Date: Tue, 20 May 2014 16:43:10 +0200
Subject: [sles-beta] Gnome termnal
In-Reply-To: <2AF8F70C6D885349B9EEFBA28F99F150185F2F@XCH-PHX-403.sw.nos.boeing.com>
References: <2AF8F70C6D885349B9EEFBA28F99F150185F2F@XCH-PHX-403.sw.nos.boeing.com>
Message-ID: <1400596990.2064.4.camel@par-r81vxc7.par.novell.com>

Le mardi 20 mai 2014 ? 14:31 +0000, Fisher, Mark S a ?crit :
> I was not able to get gnome terminal to work properly under ICEWM. The
> colors would not change and I could not see a prompt or anything. If I
> did an ls anyway I did see some files but not all of them.  Should a
> ticket be opened on this? 

Please do.


-- 
Frederic Crozat
Project Manager Enterprise Desktop
SUSE


From jweber at suse.com  Tue May 20 08:43:24 2014
From: jweber at suse.com (Jan Weber)
Date: Tue, 20 May 2014 16:43:24 +0200
Subject: [sles-beta] Gnome termnal
In-Reply-To: <2AF8F70C6D885349B9EEFBA28F99F150185F2F@XCH-PHX-403.sw.nos.boeing.com>
References: <2AF8F70C6D885349B9EEFBA28F99F150185F2F@XCH-PHX-403.sw.nos.boeing.com>
Message-ID: <537B6A0C.7010300@suse.com>

On 05/20/2014 04:31 PM, Fisher, Mark S wrote:
> I was not able to get gnome terminal to work properly under ICEWM. The
> colors would not change and I could not see a prompt or anything. If I
> did an ls anyway I did see some files but not all of them.  Should a
> ticket be opened on this?

Yes, please open a service request for this issue.

Thanks,

Jan

>  
> 
> On a side note the omission of KDE 4 for the desktop is going to be a
> show stopper for us.
> 
> 
> 
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta
> 

-- 
Jan Weber          E jweber at suse.com      SUSE Linux Products GmbH
Product Manager    M +49(179)4573255      HRB 16746 (AG N?rnberg)
SUSE Linux Enterprise                     GF: Jeff Hawn, Jennifer Guild
http://www.suse.com/                          Felix Imend?rffer

From jrd at netlab1.net  Tue May 20 08:48:11 2014
From: jrd at netlab1.net (Joe Doupnik)
Date: Tue, 20 May 2014 15:48:11 +0100
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <537B609C.3000506@netlab1.net>
References: <CAEUhfEdQP9PwGNrPgfnFx8isB4CcgCCpdeXMqQJrd6sndHjYzA@mail.gmail.com>	<1400486904.19291.8.camel@ibrokeit.suse.de>	<CAEUhfEf0uxeiioNj+QRd-4a6TQN2_YqYNSHwONkCdYL_0MJFfw@mail.gmail.com>	<1400575529.19291.46.camel@ibrokeit.suse.de>	<d06291f3bef74ea3b9eced06105b8a35@LGNMSXA01.prod.bk.dfs>	<537B2835.5030303@netlab1.net>
	<537B2BB3.7060807@suse.com>	<537B351A.7040409@netlab1.net>
	<20140520111217.GA2882@suse.de>	<537B3D65.3060102@netlab1.net>
	<20140520134954.GF17401@suse.de> <537B609C.3000506@netlab1.net>
Message-ID: <537B6B2B.3010103@netlab1.net>

     A short levity break in this thread as all of us could use a little 
relief just about now. This is partly for Richard Brown & Co.

     Mission to Mars. We are on the launch pad, in the capsule at the 
top, one hour before launch and things are looking good. Auto Update of 
systems software is engaged (MicroSoft does it, what could possibly go 
wrong). An amber caution light comes on the panel saying an update is in 
progress. It finishes soon enough to not cause a hold and the light goes 
off. The count down continues. "6 5 4 3 ignition, and liftoff!" Mission 
control broadcasts "Mission STM01 is on its way to Mars at 2358 on 31 
Dec 1999."
     Two minutes later the vehicle turns over and dives for the earth. 
Oh dear, must be another Y2K problem.

     Least some think this is pure fantasy, see the film Gravity about 
unexpected consequences.
     Joe D. (ex-NASA)

From S.M.Flood at ucs.cam.ac.uk  Tue May 20 08:54:52 2014
From: S.M.Flood at ucs.cam.ac.uk (Simon Flood)
Date: Tue, 20 May 2014 15:54:52 +0100
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: <537B6CBC.7010208@ucs.cam.ac.uk>

I was keeping quiet after my last set of messages in this thread as I 
was going to wait until Matthias' Modules presentation in the hope that 
would explain everything and answer any possible questions.

However it seems some of this thread is going around in circles 
(customers want packages available at installation which may be done 
off-line, SUSE say no or perhaps now maybe) so I have a practical example:

Having just done a basic install of SLES12 Beta6 I want to test PHP. 
Since it's not included in ISO (I did a network install, booting from 
mini ISO but referencing DVD ISO accessible via HTTP) I thought I'd try 
the registration process (other than preferring SUSEConnect was all 
lowercase that seems to have gone well) thinking that would then allow 
me access to the Modules whereby I can get PHP. It didn't so I patched, 
first zypper then everything else which required a reboot. Oh great my 
VM won't subsequently boot due to a kernel panic!

Grr this is one of the reasons why I have a problem with the suggested 
process. I can't now test PHP with SLES12 Beta 6 because SUSE isn't 
offering PHP packages that I can install. Whilst I realise we're in beta 
testing phase (so things are in flux) withholding what I would consider 
essential packages that might be involved in testing is not a smart 
idea. I would've thought at the point packages were removed from ISO 
they should be available via the new way.

Oh and I've just thought how I can test PHP with SLES12 (assuming I can 
fix or reinstall my VM) ... by downloading the source and compiling 
myself, something I thought SUSE wanted to help me avoid!

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

Novell/SUSE/NetIQ Knowledge Partner

From rbrown at suse.de  Tue May 20 09:07:06 2014
From: rbrown at suse.de (Richard Brown)
Date: Tue, 20 May 2014 17:07:06 +0200
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <537B6B2B.3010103@netlab1.net>
References: <CAEUhfEdQP9PwGNrPgfnFx8isB4CcgCCpdeXMqQJrd6sndHjYzA@mail.gmail.com>
	<1400486904.19291.8.camel@ibrokeit.suse.de>
	<CAEUhfEf0uxeiioNj+QRd-4a6TQN2_YqYNSHwONkCdYL_0MJFfw@mail.gmail.com>
	<1400575529.19291.46.camel@ibrokeit.suse.de>
	<d06291f3bef74ea3b9eced06105b8a35@LGNMSXA01.prod.bk.dfs>
	<537B2835.5030303@netlab1.net> <537B2BB3.7060807@suse.com>
	<537B351A.7040409@netlab1.net> <20140520111217.GA2882@suse.de>
	<537B3D65.3060102@netlab1.net> <20140520134954.GF17401@suse.de>
	<537B609C.3000506@netlab1.net> <537B6B2B.3010103@netlab1.net>
Message-ID: <1400598426.19291.76.camel@ibrokeit.suse.de>

On Tue, 2014-05-20 at 15:48 +0100, Joe Doupnik wrote:
>      A short levity break in this thread as all of us could use a little 
> relief just about now. This is partly for Richard Brown & Co.
> 
>      Mission to Mars. We are on the launch pad, in the capsule at the 
> top, one hour before launch and things are looking good. Auto Update of 
> systems software is engaged (MicroSoft does it, what could possibly go 
> wrong). An amber caution light comes on the panel saying an update is in 
> progress. It finishes soon enough to not cause a hold and the light goes 
> off. The count down continues. "6 5 4 3 ignition, and liftoff!" Mission 
> control broadcasts "Mission STM01 is on its way to Mars at 2358 on 31 
> Dec 1999."
>      Two minutes later the vehicle turns over and dives for the earth. 
> Oh dear, must be another Y2K problem.
> 
>      Least some think this is pure fantasy, see the film Gravity about 
> unexpected consequences.
>      Joe D. (ex-NASA)
> _____________________________

An cautionary tale belying the importance of good QA, something which I
hope myself and my colleagues already know a fair bit about :)

Wouldn't the scenario be more apt if it addressed the choice of
installation methods rather than the timing?

Updating 10 seconds before launch probably isn't the smartest idea
regardless of method, but applying that software patch over radio as in
the tale is probably a bit more convenient than trying to swap out the
Command Module computer while it's 111m above the ground, attached to a
scaffold, with over 2.3 million KG of fuel beneath it...



-- 
-------------------------------------------------------------------
  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 mge at suse.com  Tue May 20 09:18:15 2014
From: mge at suse.com (Matthias G. Eckermann)
Date: Tue, 20 May 2014 17:18:15 +0200
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <537B6CBC.7010208@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> <537B6CBC.7010208@ucs.cam.ac.uk>
Message-ID: <20140520151815.GE16236@suse.com>

Hello Simon and all,

On 2014-05-20 T 15:54 +0100 Simon Flood wrote:

> I was keeping quiet after my last set of messages in
> this thread as I was going to wait until Matthias'
> Modules presentation in the hope that would explain
> everything and answer any possible questions.

I appreciate that, and looking forward to provide and
discuss that presentation. However, you may have run
into a bug, thus I am commenting now as well.
 
> Having just done a basic install of SLES12 Beta6 I
> want to test PHP.  Since it's not included in ISO (I
> did a network install, booting from mini ISO but
> referencing DVD ISO accessible via HTTP) I thought I'd
> try the registration process (other than preferring
> SUSEConnect was all lowercase that seems to have gone
> well) thinking that would then allow me access to the
> Modules whereby I can get PHP.

So, you registered after the initial installation?

> It didn't so I patched, first zypper then everything
> else which required a reboot.  Oh great my VM won't
> subsequently boot due to a kernel panic!

Just in case you have the chance to register at
installation time: in this case you will see a
check-box asking you, if you want to update directly
at installation time or not.

The access to the modules is _independent_ of your
choice there. Once you have registered, you have access
to the modules, the update channels, as well as the SDK
and extensions.  You are free to chose and skip those
independently of each other. -- If this is not
independent, you found a bug, and we'd appreciate a
Service Request.

If you register in an already installed system, the
process includes calling the repository management (YaST
or zypper) afterwards, to enable / disable the
respective channels.

And yes, agreed, documentation about this is due.
 
> Oh and I've just thought how I can test PHP with
> SLES12 (assuming I can fix or reinstall my VM) ... by
> downloading the source and compiling myself, something
> I thought SUSE wanted to help me avoid!

We definitely provide supported PHP packages, and we
don't want you to compile, indeed. 

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 S.M.Flood at ucs.cam.ac.uk  Tue May 20 09:32:02 2014
From: S.M.Flood at ucs.cam.ac.uk (Simon Flood)
Date: Tue, 20 May 2014 16:32:02 +0100
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <20140520151815.GE16236@suse.com>
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> <537B6CBC.7010208@ucs.cam.ac.uk>
	<20140520151815.GE16236@suse.com>
Message-ID: <537B7572.4080905@ucs.cam.ac.uk>

On 20/05/2014 16:18, Matthias G. Eckermann wrote:

> So, you registered after the initial installation?

Yes as that's the way I choose for my personal installs (that is, 
installs tied to me personally as Knowledge Partner, beta tester, etc. 
as opposed to work installs which are not registered with NCC/SCC, SMT, 
etc.).

> Just in case you have the chance to register at
> installation time: in this case you will see a
> check-box asking you, if you want to update directly
> at installation time or not.

Since it's a (broken) VM I'll try reinstalling and registering during 
install.

> The access to the modules is _independent_ of your
> choice there. Once you have registered, you have access
> to the modules, the update channels, as well as the SDK
> and extensions.  You are free to chose and skip those
> independently of each other. -- If this is not
> independent, you found a bug, and we'd appreciate a
> Service Request.
>
> If you register in an already installed system, the
> process includes calling the repository management (YaST
> or zypper) afterwards, to enable / disable the
> respective channels.

Well it added some repos but PHP was still not found so I suspect 
SUSEConnect didn't handle access to Modules.

Note this was all done via text-mode terminal with no GUI in sight (it's 
a server!) or use of YaST - literally just zypper and SUSEConnect commands.

> And yes, agreed, documentation about this is due.

That would help as I hope will your beta presentation.

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

Novell/SUSE/NetIQ Knowledge Partner

From S.M.Flood at ucs.cam.ac.uk  Tue May 20 09:34:31 2014
From: S.M.Flood at ucs.cam.ac.uk (Simon Flood)
Date: Tue, 20 May 2014 16:34:31 +0100
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <537B7572.4080905@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>
	<537B6CBC.7010208@ucs.cam.ac.uk>	<20140520151815.GE16236@suse.com>
	<537B7572.4080905@ucs.cam.ac.uk>
Message-ID: <537B7607.20302@ucs.cam.ac.uk>

On 20/05/2014 16:32, Simon Flood wrote:

> Since it's a (broken) VM I'll try reinstalling and registering during
> install.

Hmm and that highlights a difference with registering post-install where 
SUSEConnect requires just a registration code yet during install I'm 
asked to provide both an email address and registration code ...

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

Novell/SUSE/NetIQ Knowledge Partner

From S.M.Flood at ucs.cam.ac.uk  Tue May 20 10:37:15 2014
From: S.M.Flood at ucs.cam.ac.uk (Simon Flood)
Date: Tue, 20 May 2014 17:37:15 +0100
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <20140520151815.GE16236@suse.com>
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> <537B6CBC.7010208@ucs.cam.ac.uk>
	<20140520151815.GE16236@suse.com>
Message-ID: <537B84BB.9080500@ucs.cam.ac.uk>

On 20/05/2014 16:18, Matthias G. Eckermann wrote:

> Just in case you have the chance to register at
> installation time: in this case you will see a
> check-box asking you, if you want to update directly
> at installation time or not.

Once I fixed my VM kernel panic (note to self - don't pick SLES 64-bit 
as Guest OS in VMware Player but use SLES11 64-bit instead) that worked 
as outlined.

> The access to the modules is _independent_ of your
> choice there. Once you have registered, you have access
> to the modules, the update channels, as well as the SDK
> and extensions.  You are free to chose and skip those
> independently of each other. -- If this is not
> independent, you found a bug, and we'd appreciate a
> Service Request.
>
> If you register in an already installed system, the
> process includes calling the repository management (YaST
> or zypper) afterwards, to enable / disable the
> respective channels.
>
> And yes, agreed, documentation about this is due.

What hasn't worked is access to PHP which is where I started today - I 
registered during install but didn't select any extensions or modules 
during install (because I didn't want all web tools).

So post-install I expected "zypper se php" to find php. It doesn't. 
"zypper lr -u" and "zypper ca" don't reveal anything Modules-related. 
Checking YaST that also doesn't find php.

This therefore highlights missing knowledge and/or tools to handle 
adding Modules to an already installed (SLES12) system (people might 
want to add Modules to an existing server to change/expand it's use).

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

Novell/SUSE/NetIQ Knowledge Partner

From tee at sgi.com  Tue May 20 11:52:20 2014
From: tee at sgi.com (Tony Ernst)
Date: Tue, 20 May 2014 12:52:20 -0500
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <20140520151815.GE16236@suse.com>
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> <537B6CBC.7010208@ucs.cam.ac.uk>
	<20140520151815.GE16236@suse.com>
Message-ID: <20140520175220.GJ6491@sgi.com>

On Tue, May 20, 2014 at 05:18:15PM +0200, Matthias G. Eckermann wrote:
> If you register in an already installed system, the
> process includes calling the repository management (YaST
> or zypper) afterwards, to enable / disable the
> respective channels.

Hi Matthias,

I just registered an already installed system. It gave me a list of modules
to choose from, including the SDK. I added the Web Scripting module.

I then fired up yast and opened Software Management. I see that I now have
a channel called SLE-MODULE-WEB-SCRIPTING12-Pool. The channel contains both
python and php packages.

I was suprised to see that the python packages were already installed.
I found that they were installed as part of base SLES12. But they will
presumably get updates via the Web Scripting channel. That's exactly 
the model that people have been asking for with php! Just ship a base
version in SLES12, and updates via the Web Scripting channel. Yes, the
base packages will be outdated soon after the release, but so will python
(and all of the other sles12 packages). Why is php treated differently
than python?

I understand that you're reluctant to put php in the base because you're
afraid that customers won't update it. But forcing a customer to add the
Web Scripting module doesn't make them any more likely to install future
updates later.

I'd like to explain our particular use case, because I think it's different
than most of the people who have been commenting on this.

When we install a machine in Manufacturing, we do a default base install.
We can't register the system, because the customer needs to be able to do
that with their own account. We have software that requires php, so that
means we are going to have to get the php packages from somewhere (SMT?)
and manually install them on all systems before they ship. That has the
same result as Suse including php in the SLES12 base, except now it will
just be more work for us.

Regards,
Tony

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


From tee at sgi.com  Tue May 20 12:02:31 2014
From: tee at sgi.com (Tony Ernst)
Date: Tue, 20 May 2014 13:02:31 -0500
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <20140520175220.GJ6491@sgi.com>
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> <537B6CBC.7010208@ucs.cam.ac.uk>
	<20140520151815.GE16236@suse.com> <20140520175220.GJ6491@sgi.com>
Message-ID: <20140520180230.GK6491@sgi.com>

One more data point...

I originally discovered that php was missing when I tried to build a
package that has the dependency BuildRequires:php5-devel

The build is done in a chroot using packages from the SLES12 and SDK12 media.

The php5-devel rpm is on the SDK12 Beta6 media. But it turns out that it's
uninstallable, because php5-devel has a dependency on php5, which is not
on any of the media. This just seems wrong.

Tony

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


From rbrown at suse.de  Tue May 20 12:35:17 2014
From: rbrown at suse.de (Richard Brown)
Date: Tue, 20 May 2014 20:35:17 +0200
Subject: [sles-beta] =?utf-8?q?php_disappeared_in_beta6=3F?=
In-Reply-To: <20140520180230.GK6491@sgi.com>
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> <537B6CBC.7010208@ucs.cam.ac.uk>
	<20140520151815.GE16236@suse.com> <20140520175220.GJ6491@sgi.com>
	<20140520180230.GK6491@sgi.com>
Message-ID: <2900eb0de0e5bc06b49d9cf32421f5a7@suse.de>

On 2014-05-20 20:02, Tony Ernst wrote:
> One more data point...
> 
> I originally discovered that php was missing when I tried to build a
> package that has the dependency BuildRequires:php5-devel
> 
> The build is done in a chroot using packages from the SLES12 and SDK12 
> media.
> 
> The php5-devel rpm is on the SDK12 Beta6 media. But it turns out that 
> it's
> uninstallable, because php5-devel has a dependency on php5, which is 
> not
> on any of the media. This just seems wrong.
> 
> Tony

I sympathize, I found a very similar issue with the HA Extension, the 
solution being adding the HA Extension in order to be able to make the 
correct use of the relevant SDK packages.

This is actually covered in the SDK readme, which explains that the SDK 
is for SLES, SLED, and it's extensions, and some packages may not work 
without the the presence of the appropriate product.

When it comes to this kind of thing, I find it beneficial to think of 
Modules very much like I think of SLE Extensions

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 mark.s.fisher at boeing.com  Tue May 20 13:11:55 2014
From: mark.s.fisher at boeing.com (Fisher, Mark S)
Date: Tue, 20 May 2014 19:11:55 +0000
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <20140520175220.GJ6491@sgi.com>
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> <537B6CBC.7010208@ucs.cam.ac.uk>
	<20140520151815.GE16236@suse.com> <20140520175220.GJ6491@sgi.com>
Message-ID: <2AF8F70C6D885349B9EEFBA28F99F1501861A2@XCH-PHX-403.sw.nos.boeing.com>

It asks for a code, what to you use for that?

-----Original Message-----
From: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] On Behalf Of Tony Ernst
Sent: Tuesday, May 20, 2014 12:52 PM
To: Matthias G. Eckermann
Cc: sles-beta at lists.suse.com
Subject: Re: [sles-beta] php disappeared in beta6?

On Tue, May 20, 2014 at 05:18:15PM +0200, Matthias G. Eckermann wrote:
> If you register in an already installed system, the process includes 
> calling the repository management (YaST or zypper) afterwards, to 
> enable / disable the respective channels.

Hi Matthias,

I just registered an already installed system. It gave me a list of modules to choose from, including the SDK. I added the Web Scripting module.

I then fired up yast and opened Software Management. I see that I now have a channel called SLE-MODULE-WEB-SCRIPTING12-Pool. The channel contains both python and php packages.

I was suprised to see that the python packages were already installed.
I found that they were installed as part of base SLES12. But they will presumably get updates via the Web Scripting channel. That's exactly the model that people have been asking for with php! Just ship a base version in SLES12, and updates via the Web Scripting channel. Yes, the base packages will be outdated soon after the release, but so will python (and all of the other sles12 packages). Why is php treated differently than python?

I understand that you're reluctant to put php in the base because you're afraid that customers won't update it. But forcing a customer to add the Web Scripting module doesn't make them any more likely to install future updates later.

I'd like to explain our particular use case, because I think it's different than most of the people who have been commenting on this.

When we install a machine in Manufacturing, we do a default base install.
We can't register the system, because the customer needs to be able to do that with their own account. We have software that requires php, so that means we are going to have to get the php packages from somewhere (SMT?) and manually install them on all systems before they ship. That has the same result as Suse including php in the SLES12 base, except now it will just be more work for us.

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 S.M.Flood at ucs.cam.ac.uk  Tue May 20 15:57:17 2014
From: S.M.Flood at ucs.cam.ac.uk (Simon Flood)
Date: Tue, 20 May 2014 22:57:17 +0100
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <2AF8F70C6D885349B9EEFBA28F99F1501861A2@XCH-PHX-403.sw.nos.boeing.com>
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> <537B6CBC.7010208@ucs.cam.ac.uk>
	<20140520151815.GE16236@suse.com> <20140520175220.GJ6491@sgi.com>
	<2AF8F70C6D885349B9EEFBA28F99F1501861A2@XCH-PHX-403.sw.nos.boeing.com>
Message-ID: <0a96936f-f25d-42f3-9efb-5ca50dd77595@email.android.com>

On 20 May 2014 20:11:55 BST, "Fisher, Mark S" wrote:

>It asks for a code, what to you use for that?

Not having seen/heard of a SLES12 beta-specific registration code I wondered the same then tried using a SLES11 code which worked.

HTH, 
Simon
Simon Flood
Senior Systems Specialist
University of Cambridge
United Kingdom

Novell/SUSE/NetIQ Knowledge Partner

From darrent at akurit.com.au  Tue May 20 16:13:35 2014
From: darrent at akurit.com.au (Darren Thompson)
Date: Wed, 21 May 2014 08:13:35 +1000
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <2900eb0de0e5bc06b49d9cf32421f5a7@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> <537B6CBC.7010208@ucs.cam.ac.uk>
	<20140520151815.GE16236@suse.com> <20140520175220.GJ6491@sgi.com>
	<20140520180230.GK6491@sgi.com>
	<2900eb0de0e5bc06b49d9cf32421f5a7@suse.de>
Message-ID: <CAEUhfEew1=dMP0RcC25eaijY3tVPANeGLDBLJDjm-frjDRj3gA@mail.gmail.com>

Bingo

The answer was right in front of us all the time, why not package them as
an extension ISO?

Darren


On 21 May 2014 04:35, Richard Brown <rbrown at suse.de> wrote:

> On 2014-05-20 20:02, Tony Ernst wrote:
>
>> One more data point...
>>
>> I originally discovered that php was missing when I tried to build a
>> package that has the dependency BuildRequires:php5-devel
>>
>> The build is done in a chroot using packages from the SLES12 and SDK12
>> media.
>>
>> The php5-devel rpm is on the SDK12 Beta6 media. But it turns out that it's
>> uninstallable, because php5-devel has a dependency on php5, which is not
>> on any of the media. This just seems wrong.
>>
>> Tony
>>
>
> I sympathize, I found a very similar issue with the HA Extension, the
> solution being adding the HA Extension in order to be able to make the
> correct use of the relevant SDK packages.
>
> This is actually covered in the SDK readme, which explains that the SDK is
> for SLES, SLED, and it's extensions, and some packages may not work without
> the the presence of the appropriate product.
>
> When it comes to this kind of thing, I find it beneficial to think of
> Modules very much like I think of SLE Extensions
>
> 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://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/20140521/96816bde/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/20140521/96816bde/attachment.jpg>

From urs.frey at post.ch  Wed May 21 01:51:20 2014
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Wed, 21 May 2014 07:51:20 +0000
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <CAEUhfEew1=dMP0RcC25eaijY3tVPANeGLDBLJDjm-frjDRj3gA@mail.gmail.com>
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> <537B6CBC.7010208@ucs.cam.ac.uk>
	<20140520151815.GE16236@suse.com> <20140520175220.GJ6491@sgi.com>
	<20140520180230.GK6491@sgi.com>	<2900eb0de0e5bc06b49d9cf32421f5a7@suse.de>
	<CAEUhfEew1=dMP0RcC25eaijY3tVPANeGLDBLJDjm-frjDRj3gA@mail.gmail.com>
Message-ID: <40637DBB36AF3941B243A286A432CA0B0F99BB1F@HXMB12.pnet.ch>

Hi
When guessing and discussing about the new ideas of SUSE delivering software and trying to register against NCC or SCC whatever..

We do have already an example in the present SLES12 Beta6 YAST installer. When initializing the software manager, there is a hard coded download of the release notes from https://www.suse.com; - timeout 5minutes.
This timeout of course gets multiplied by the number of network interfaces physically present on the server.


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

So within the YAST installer the priority is set to the release notes instead of a smooth installation.

My simple question is:
When does SUSE finally understand that in a high productivity environment security and firewalls do play a crucial role?

A high productivity environment is what the majority of us end-users are faced with. No internet access on all servers. So with the above hard coded download the majority of us gets bored with waiting for nothing. Why: just because it is simpler to download well formatted rtf release notes from www.suse.com<http://www.suse.com>, than to deal with rpms.
I need to deploy within minutes I will never be reading release notes while installing.
Here from my point of view SUSE does set the priority on the wrong part.

I technically understand, why a subscription registration is important to get my php channel delivered. This has to do with the NU mechanism getting zypper and therefore the software manager all allowed NU repositories upon registration, making php available.
BUT from my point of view, making the download of opensource software dependent of a subscription registration is contradictory to the opensource license and opensource idea itself.

To download opensource software, there must not be any registration dependency. Only when there is need for support and updates, this needs a support service and therefore a subscription registration.

So in my place I need to deploy fast and smooth and afterwards, when everything is set up I will register against SMT.
SMT is the only connector to SUSE allowed here.
My SMT is physically separated in a DMZ and also physically separated from the frozen SUSE production update repositories.
In fact, SMT does download the updates and register etc, but all services used for production are physically separated in a different zone from SMT for security reasons.

When looking at SUSEConnect there is really no usable help around about what to enter when trying to register. It is the same pain as I had with suse_register and dealing with firewalls etc.

So once again:
When does SUSE finally understand that in a high productivity environment security and firewalls do play a crucial role?

Thanks


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>

Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Darren Thompson
Gesendet: Wednesday, May 21, 2014 12:14 AM
An: Richard Brown; sles-beta at lists.suse.com
Cc: sles-beta at suse.com
Betreff: Re: [sles-beta] php disappeared in beta6?

Bingo

The answer was right in front of us all the time, why not package them as
an extension ISO?

Darren

On 21 May 2014 04:35, Richard Brown <rbrown at suse.de<mailto:rbrown at suse.de>> wrote:
On 2014-05-20 20:02, Tony Ernst wrote:
One more data point...

I originally discovered that php was missing when I tried to build a
package that has the dependency BuildRequires:php5-devel

The build is done in a chroot using packages from the SLES12 and SDK12 media.

The php5-devel rpm is on the SDK12 Beta6 media. But it turns out that it's
uninstallable, because php5-devel has a dependency on php5, which is not
on any of the media. This just seems wrong.

Tony

I sympathize, I found a very similar issue with the HA Extension, the solution being adding the HA Extension in order to be able to make the correct use of the relevant SDK packages.

This is actually covered in the SDK readme, which explains that the SDK is for SLES, SLED, and it's extensions, and some packages may not work without the the presence of the appropriate product.

When it comes to this kind of thing, I find it beneficial to think of Modules very much like I think of SLE Extensions

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<mailto:sles-beta at lists.suse.com>
http://lists.suse.com/mailman/listinfo/sles-beta



--

Darren Thompson

Professional Services Engineer / Consultant

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

Level 3, 60 City Road

Southgate, VIC 3006

Mb: 0400 640 414

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

From urs.frey at post.ch  Wed May 21 03:46:48 2014
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Wed, 21 May 2014 09:46:48 +0000
Subject: [sles-beta] php disappeared in beta6?
In-Reply-To: <1424694.5RaOaYg8ZW@whistler.site>
References: <20140514153539.GC11257@sgi.com>
	<CAEUhfEew1=dMP0RcC25eaijY3tVPANeGLDBLJDjm-frjDRj3gA@mail.gmail.com>
	<40637DBB36AF3941B243A286A432CA0B0F99BB1F@HXMB12.pnet.ch>
	<1424694.5RaOaYg8ZW@whistler.site>
Message-ID: <40637DBB36AF3941B243A286A432CA0B0F99BD79@HXMB12.pnet.ch>

Hello Will

Thank you
With SMT I got a script called clientSetup4SMT.sh which I could wget from the SMT.
This Script then did set the URL and necessary entry into the local file /etc/suseRegister.conf
Personally I only understand the parameter url and hostGUID in this /etc/suseRegister.conf file.
The rest I take as "undocumented" feature, because I did not find a real description of suse_register and the config parameters.
After I got it to work I did not search further, I admit.

v063o7:~ # cat /etc/suseRegister.conf
url=https://172.31.40.8/center/regsvc
listParams = command=listparams
register   = command=register
listProducts = command=listproducts
#hostGUID = 122354

# add update sources provided by the registration server
#
addRegSrvSrc = true

# add additional update sources (only type zypp is supported)
# addAdSrc can be used multiple times
#
#addAdSrc = http://you.suse.de/updates/test?alias=someName
#addAdSrc = http://you.suse.de/updates/test2

hostGUID = 0ed6b3efa4ba41c6ada9b4f57ec68b58
v063o7:~ #

Then with this information I can run suse_register against my internal SMT using my NCC Mail account and the subscription code I need to register on as paframeter
suse_register --no-refresh -a email=urs.frey at post.ch -a regcode-sles=2087161FC7B45F -L /root/suse_register.log

In the code below you can see the shell script I use to register against my internal SMT in autoyast init-script phase

         # if there is /etc/wgetrc active, deactivate for suse_register
         if [ -e /etc/wgetrc ] ; then
           mv -v /etc/wgetrc /etc/_wgetrc
         fi
         #
         # download clientconfig4SMT-Script always the latest version
         cd ${basedir}/bin
         rm -f clientSetup4SMT.sh
         wget --proxy=off -nd -t5 http://${smtserver}/smt/repo/tools/clientSetup4SMT.sh
         if [ -e ./clientSetup4SMT.sh ] ; then
           #
           # only if there was no error with download, do attempt to register
           #
           chmod 755 clientSetup4SMT.sh
           echo "y" | ${basedir}/bin/clientSetup4SMT.sh  --host ${smtserver} --regcert http://${smtserver}/smt/smt/smt.crt
           if [ "${vmwarecl}" != "" ] ; then
             #
             # for virtual clients we put in the hypervirsors, deviceid
             # for NCC will count the license correctly
             hostguid=`grep -v "#" /etc/suseRegister.conf | grep ^hostGUID`
             if [ "${hostguid}" == "" ] ; then
               #
               # we configure Hypervisor hostGUID
               #
               echo "" >> /etc/suseRegister.conf
               echo "hostGUID = 0ed6b3efa4ba41c6ada9b4f57ec68b58" >> /etc/suseRegister.conf
             fi
             licensecode="${licensecode_vmv}"
           else
             #
             licensecode="${licensecode_srv}"
           fi
           suse_register ${suseregparam} -a email=urs.frey at post.ch -a regcode-sles=${licensecode} -L /root/suse_register.log
           #
         fi
         # re-activate
         if [ -e /etc/_wgetrc ] ; then
           mv -v /etc/_wgetrc /etc/wgetrc
         fi


The challenge was to find out how the entire process with suse_register is done.
Our firewalls do allow communication only one way.
One has to define who does open the connection on which protocol and which way the data flow is.
Which way does suse_register open a connection, which protocol to SMT to upload information?
Firewalls do drop packages in silent way, no error code nothing, just no communication and wait for timeout.

One thing you can see above is the use of the --no-refresh parameter.
We cannot use the NU mechanism internally as we specify the repositories used on our production platform ourselves for security reasons.
Our servers do have only specifically granted repositories connected.
So there is a real need for a parameter allowing no refresh of libzypp and connect of NU repositories

So I need again with SUSEConnect a description of the handshake with SMT and I need to know the protocol used.
Within SUSEConnect I miss the parameter --no-refresh
Protocols http, https, are allowed to upload to SMT DMZ

Currently on my SLES12 Beta6 x86_64 I see these SUSEConnect manpages. The SUSEConnect.8.gz I copied manually to /usr/share/man/man8/
h063ur:~ # man SUSEConnect
Man: find all matching manual pages (set MAN_POSIXLY_CORRECT to avoid this)
 * SUSEConnect (1)
   SUSEConnect (8)
Man: What manual page do you want?

Currently SUSEConnect (1) contains some rake command I do not really understand or find a context to.

SUSEConnect (8) is a good step forward

Especially:
COMPARED TO SUSE_REGISTER
   BEFORE
       suse_register -a email=<email> -a regcode-sles=<regcode> -L <logfile>

   AFTER
       SUSEConnect --url <registration-server-url> -r <regcode> >> <logfile>

But the entire process and handshaking is missing. 
How can SUSEConnect find out the correct NCC / SCC account by not providing a NCC account credential as the email address?

Until SMT on SLES11-SP3 works with SLES12 I will not be able to test channels or register or use SUSEConnect in any way
DMZ is a security zone, no way to place Lab servers there.


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 Will Stephenson
Gesendet: Wednesday, May 21, 2014 10:38 AM
An: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] php disappeared in beta6?

On Wednesday 21 May 2014 07:51:20 urs.frey at post.ch wrote:
> When looking at SUSEConnect there is really no usable help around about what
> to enter when trying to register. It is the same pain as I had with
> suse_register and dealing with firewalls etc.

Urs,

I've updated the --help output and manpage for SUSEConnect for beta7 in line 
with your earlier feedback.   An additional section covers using it with SMT. 
However this is currently just a wordy version of  'SUSEConnect registers 
systems via SCC on the internet or a local SMT server using a RESTful JSON api 
over https.  Use SUSEConnect --url <url-of-smt> to register systems with SMT 
instead of SCC, and set proxies in YaST as needed'.

It would help me to know what other steps you had to take to make registration 
work in your firewalled SMT deployment.

I've attached the current (beta7) state of the manpage for your feedback.  
Read with man -l SUSEConnect.8.gz. A second manpage for SUSEConnect.5 (its 
config file) is still to be started. 

best regards

Will Stephenson

--
Will Stephenson | SCC Team
SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 21284 
(AG N?rnberg)
Maxfeldstra?e 5
90409 N?rnberg
Germany

From markus.hubler at isc-ejpd.admin.ch  Wed May 21 08:25:21 2014
From: markus.hubler at isc-ejpd.admin.ch (markus.hubler at isc-ejpd.admin.ch)
Date: Wed, 21 May 2014 14:25:21 +0000
Subject: [sles-beta] sssd hassle
Message-ID: <59462F911036934D8BF6834B607DD7CE7EAF9757@sb00106a.adb.intra.admin.ch>

Hi Peter

I have tried to find out  more about sssd in the last week. However I still have somewhere a hassle in my config.
Do you have an idea how I have to set the filter correctly, that all the users who are in the netgroup (named by after current host) get correctly mapped to the system.

The server being t9002. I have a perfect access to the ldap server as getent netgroup <servername> works.

So it seems as my basic pain is to get a working filter.


1)      # getent netgroup t9002
        t9002            ( ,user1,) ( ,user2,)
        works fine

2)      enumerate=True shows all the users (even those that should not have access) enumerate= false does show only local users


3)      Filter: Is it wise to adopt the search base (as I tried to do? Or would you take ldap_access_filter)


4)      Desired state would be:
        getent passwd show local users and user1 and user2

5)      before we had

        + at t9002:::::: (in /etc/passwd)
        + at t9002::0:0:0:::: (in /etc/shadow)


Any suggestions about documentation???


ldapsearch gives out the following

# t9002, netgroup, test.test.ch
dn: cn=ejpdxt9002,ou=netgroup,dc=test,dc=test,dc=ch
memberNisNetgroup: netgroup-ux
cn: t9002
objectClass: nisNetgroup
objectClass: top


/etc/sssd/sssd.conf
===================

[sssd]
default_domain_suffix = LDAP
config_file_version = 2
services = nss, pam
domains = LDAP
full_name_format = %1$s@%2$s
[nss]
filter_groups = root
filter_users = root

[pam]
[domain/LDAP]
id_provider = ldap
auth_provider = ldap
ldap_group_member = uniquemember
chpass_provider = ldap
ldap_uri = ldap://t4113.test.ch
ldap_chass_uri = ldap://t4113.test.ch
ldap_schema = rfc2307bis

ldap_search_base = cn=t9002,ou=netgroup,dc=test,dc=test,dc=ch?one?|(objectClass=nisNetgroup)
ldap_netgroup_search_base = ou=netgroup,dc=test,dc=test,dc=ch

access_provider = ldap
ldap_access_filter =  (|(ou=netgroup,dc=test,dc=test,dc=ch)(cn=t9002))

ldap_group_search_base = ou=group,dc=test,dc=test,dc=ch
ldap_user_search_base = ou=people,dc=test,dc=test,dc=ch
enumerate = True
ldap_tls_reqcert = never
ldap_tls_cacertdir = /etc/ssl/certs


/etc/nsswitch.conf
==================


passwd: files sss
shadow: files sss
group:  files sss

hosts:  files dns
networks:       files

services:       files
protocols:      files
rpc:    files
ethers: files
netmasks:       files
netgroup:       sss
publickey:      files

bootparams:     files
automount:      files
aliases:        files
passwd_compat:  ldap
shadow_compat:  ldap
group_compat:   files


Best regards
Markus





From mjedamzik at novell.com  Thu May 22 06:17:24 2014
From: mjedamzik at novell.com (Martin Jedamzik)
Date: Thu, 22 May 2014 13:17:24 +0100
Subject: [sles-beta] adding disks online to btrfs filesystem
Message-ID: <537E06F4020000810004D8E5@mail.emea.novell.com>

Hi all,

maybe this is a question for product managment, but I think the answer is interesting for all of us.

Is the capability of btfrs to add disks online supported ? No, nothing fancy about striping or Raid, just adding a disk
to enlarge the filesystem ;-)

Best regards,

Martin


Martin Jedamzik
Primary Support Engineer
mjedamzik at novell.com
Office  ++49 (0)211-5631-1601
Mobile       ++49 173-5876966
NetIQ | Novell | SUSE

Attachmate Group Germany GmbH
N?rdlicher Zubringer 9-11,
D-40470 D?sseldorf
Attachmate Group Germany, GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 202401 (AG M?nchen) 
 
 



From uwedr at suse.com  Thu May 22 06:38:26 2014
From: uwedr at suse.com (Uwe Drechsel)
Date: Thu, 22 May 2014 14:38:26 +0200
Subject: [sles-beta] SLES12 Beta5 x86_64 question concerning puppet
In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0EFB3BE1@HXMB12.pnet.ch>
References: <40637DBB36AF3941B243A286A432CA0B0EFB3BE1@HXMB12.pnet.ch>
Message-ID: <20140522123826.GD6184@suse.de>

On Fri, May 09, urs.frey at post.ch wrote:

> Hi
> 
> On SLES12 beta5 x86_64 there I can find puppet version: puppet-3.3.1-2.4.x86_64
> I do also see, that puppet Is not yet integrated in system. There is still an /etc/init.d/puppet sysvinit startscript
> 
> Question:
> Will puppet be updated to a later version working with systemd?
> 

Yes, that bug is still open, will be fixed in a later release.

Thanks
Uwe

From mge at suse.com  Thu May 22 06:49:55 2014
From: mge at suse.com (Matthias G. Eckermann)
Date: Thu, 22 May 2014 14:49:55 +0200
Subject: [sles-beta] adding disks online to btrfs filesystem
In-Reply-To: <537E06F4020000810004D8E5@mail.emea.novell.com>
References: <537E06F4020000810004D8E5@mail.emea.novell.com>
Message-ID: <20140522124955.GA2563@suse.com>

Hello Martin,

On 2014-05-22 T 13:17 +0100 Martin Jedamzik wrote:
 
> maybe this is a question for product managment, but I
> think the answer is interesting for all of us.

Yep, this is an excellent question.
 
> Is the capability of btfrs to add disks online
> supported ? No, nothing fancy about striping or Raid,
> just adding a disk to enlarge the filesystem ;-)

The original plan was, not to support _any_ "RAID"ish
capabilities: and adding disks is in that area.

However, I heard from our Engineering team that this
is an area where we are investigating, and quality
might be on enterprise level already.

Let me go back and ask. Stay tuned....

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  Thu May 22 06:56:05 2014
From: lmb at suse.com (Lars Marowsky-Bree)
Date: Thu, 22 May 2014 14:56:05 +0200
Subject: [sles-beta] adding disks online to btrfs filesystem
In-Reply-To: <537E06F4020000810004D8E5@mail.emea.novell.com>
References: <537E06F4020000810004D8E5@mail.emea.novell.com>
Message-ID: <20140522125605.GU4050@suse.de>

On 2014-05-22T13:17:24, Martin Jedamzik <mjedamzik at novell.com> wrote:

> Is the capability of btfrs to add disks online supported ? No, nothing fancy about striping or Raid, just adding a disk
> to enlarge the filesystem ;-)

You can for sure resize/grow btrfs if you have it on top of LVM2 VG and
grow the VG. I quite enjoy the mature feature set and flexilibity this
provides over traditional partitioning, and has the advantage of being
fs independent.

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 gregg at ricis.com  Thu May 22 06:58:18 2014
From: gregg at ricis.com (Gregory D. Rosenberg)
Date: Thu, 22 May 2014 07:58:18 -0500
Subject: [sles-beta] adding disks online to btrfs filesystem
In-Reply-To: <20140522125605.GU4050@suse.de>
References: <537E06F4020000810004D8E5@mail.emea.novell.com>
	<20140522125605.GU4050@suse.de>
Message-ID: <05A131E9-FED5-4683-8037-E4D156AB114E@ricis.com>

Good morning everyone,

Does BTRS support thin provisioning?
Are their any limitations in using a BTRS volume in conjunction with UEFI or EFI?

On May 22, 2014, at 07:56 CDT, Lars Marowsky-Bree <lmb at suse.com> wrote:

> On 2014-05-22T13:17:24, Martin Jedamzik <mjedamzik at novell.com> wrote:
> 
>> Is the capability of btfrs to add disks online supported ? No, nothing fancy about striping or Raid, just adding a disk
>> to enlarge the filesystem ;-)
> 
> You can for sure resize/grow btrfs if you have it on top of LVM2 VG and
> grow the VG. I quite enjoy the mature feature set and flexilibity this
> provides over traditional partitioning, and has the advantage of being
> fs independent.
> 
> 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://cp.mcafee.com/d/FZsScz9J5yZNPzb8VMTsSztdNx5VUsYrhKCUMyqekm6jqdS3hOCqenzhOMqejqdQT7PhOCMO-r8NYyh1kpmBjBPspmBjBPtTmnk1Pb_nVwsyMCeWZOW8UQszKspKevoVqWdAkRkkhTaxVZicHs3jq9J4TsTsS03fBiteETj-nMjlS67OFek7qVg_W5O7PQTg_W5O7PQKgGT2TQ1hYGjFR6WvOVJB6XVI5-Aq83iTg_W5O7PQQKCy3k49g8Cy12l2J3h1m1YEuq89Rd412snq6y1Sh_QbkDWFJZYSoMkgAI7_1n4



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 jeffm at suse.com  Thu May 22 06:54:47 2014
From: jeffm at suse.com (Jeff Mahoney)
Date: Thu, 22 May 2014 08:54:47 -0400
Subject: [sles-beta] adding disks online to btrfs filesystem
In-Reply-To: <20140522124955.GA2563@suse.com>
References: <537E06F4020000810004D8E5@mail.emea.novell.com>
	<20140522124955.GA2563@suse.com>
Message-ID: <537DF397.9000805@suse.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 5/22/14, 8:49 AM, Matthias G. Eckermann wrote:
> Hello Martin,
> 
> On 2014-05-22 T 13:17 +0100 Martin Jedamzik wrote:
> 
>> maybe this is a question for product managment, but I think the
>> answer is interesting for all of us.
> 
> Yep, this is an excellent question.
> 
>> Is the capability of btfrs to add disks online supported ? No,
>> nothing fancy about striping or Raid, just adding a disk to
>> enlarge the filesystem ;-)
> 
> The original plan was, not to support _any_ "RAID"ish capabilities:
> and adding disks is in that area.
> 
> However, I heard from our Engineering team that this is an area
> where we are investigating, and quality might be on enterprise
> level already.

Hi folks -

With SLE11, we don't allow multi-disk file systems at all. For SLE12,
we'll support RAID0/1/10.

- -Jeff

- -- 
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQIcBAEBAgAGBQJTffOXAAoJEB57S2MheeWytMMQAL57B5iBijUnbe9jxiANl7/h
Uyjk99KtfnErOUt2KBRWIxuQz54XgB3rjcWalknCb9UyzeqsACl4HN1meLCuWDxg
hxIB/v8New20XXrSDNEVUGfEspWiol+ixTeQFCdZxgT9LZd8Nbswceufsr7WxPkL
p8gfHw0Hj3VUEkJqiYSV5SMav9I3QxdyDUrjwSCcx638CqGRkaVNlV+ytngDMf7H
DErSeIYO/cM7+D5UA+dirX4QV5xtEKYRvXffgbh1VU4BMjcEW0iiwYUHo59ULIXZ
XaUSoRsqLw4knQ/Fb86WkzwwcHM08sLnCT4bQuTwuv+9FFaM6a0FgVrh3orS6LnY
zGxPYzDY9q07S5v7J0WZnPVZqIMEUBK/Y8bYk70NhWKiKk0pI7O1eEkCXqP0mvbU
uOvENdElNkI45k84Z1934inzWa49/yOeAWIOgeflRv6jTduMTV93JxU/kQoF/BKI
jaIRJRBpuM6mJ8rQmYfxY7zYEvOal+cOfhf0+u5vs0I8ngl6WG+FxuPFf87k4FX6
4PjFYKK+SY/k0aqy/R1JDCkAwhTnmgkGUoH+hHUcXEZKQrECLJpoFIaVYWU4/pLt
89D9gypwL9cp66gjiRw1tIX0QqCcJ/KzuIuXyExxPxiQlgwJVGbK2SCMnH5+N+ib
rK3wQgEPWjJt092X/0Hg
=lBi5
-----END PGP SIGNATURE-----

From mjedamzik at novell.com  Thu May 22 07:18:26 2014
From: mjedamzik at novell.com (Martin Jedamzik)
Date: Thu, 22 May 2014 14:18:26 +0100
Subject: [sles-beta] Antw: Re:  adding disks online to btrfs filesystem
In-Reply-To: <20140522125605.GU4050@suse.de>
References: <537E06F4020000810004D8E5@mail.emea.novell.com>
	<20140522125605.GU4050@suse.de>
Message-ID: <537E1542020000810004D925@mail.emea.novell.com>

>>> Lars Marowsky-Bree <lmb at suse.com> schrieb am 22.5.2014 um 02:56 PM in Nachricht
> You can for sure resize/grow btrfs if you have it on top of LVM2 VG and
> grow the VG. I quite enjoy the mature feature set and flexilibity this
> provides over traditional partitioning, and has the advantage of being
> fs independent.

This is what I wanted to avoid. Sure, LVM gives much flexibility ( I'm using it for the same reasons you describe) ,
but as far as I understand btrfs it is incorporating the functions of LVM ( adding disks, grow the availabe space etc.)
Why use a stack if all can be done via the filesystem ? ;-)

Regards,

Martin

 


Martin Jedamzik
Primary Support Engineer
mjedamzik at novell.com
Office  ++49 (0)211-5631-1601
Mobile       ++49 173-5876966
NetIQ | Novell | SUSE

Attachmate Group Germany GmbH
N?rdlicher Zubringer 9-11,
D-40470 D?sseldorf
Attachmate Group Germany, GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 202401 (AG M?nchen) 
 
 



From urs.frey at post.ch  Thu May 22 07:18:58 2014
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Thu, 22 May 2014 13:18:58 +0000
Subject: [sles-beta] SLES12 Beta5 x86_64 question concerning puppet
In-Reply-To: <20140522123826.GD6184@suse.de>
References: <40637DBB36AF3941B243A286A432CA0B0EFB3BE1@HXMB12.pnet.ch>
	<20140522123826.GD6184@suse.de>
Message-ID: <40637DBB36AF3941B243A286A432CA0B0F99C50A@HXMB12.pnet.ch>

Hello Uwe

When looking at SLES12 Beta6 I can see NEW puppet Version 3.5.1 and also a full intergration to Systemd
/usr/lib/systemd/system/puppet.service

h05cni:~ # systemctl status puppet
puppet.service - Puppet agent
   Loaded: loaded (/usr/lib/systemd/system/puppet.service; disabled)
   Active: inactive (dead)

h05cni:~ #

h05cni:~ # rpm -qa | grep puppet
puppet-3.5.1-2.6.x86_64
h05cni:~ #

So from my point of view: well done, issue resolved.
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

-----Urspr?ngliche Nachricht-----
Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Uwe Drechsel
Gesendet: Thursday, May 22, 2014 2:38 PM
An: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] SLES12 Beta5 x86_64 question concerning puppet

On Fri, May 09, urs.frey at post.ch wrote:

> Hi
> 
> On SLES12 beta5 x86_64 there I can find puppet version: puppet-3.3.1-2.4.x86_64
> I do also see, that puppet Is not yet integrated in system. There is still an /etc/init.d/puppet sysvinit startscript
> 
> Question:
> Will puppet be updated to a later version working with systemd?
> 

Yes, that bug is still open, will be fixed in a later release.

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

From Dick.Waite at softwareag.com  Fri May 23 08:55:05 2014
From: Dick.Waite at softwareag.com (Waite, Dick)
Date: Fri, 23 May 2014 14:55:05 +0000
Subject: [sles-beta] Beta 7
Message-ID: <20140523145504.5824657.73184.3242@softwareag.com>

?On the road again but I have not seen any word about Beta7 which I thought was today, could have missed it I have been under the earth most of the day.
__R

Sent from my BlackBerry 10 smartphone.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.suse.com/mailman/private/sles-beta/attachments/20140523/35ad916a/attachment.htm>

From uwedr at suse.com  Fri May 23 09:06:04 2014
From: uwedr at suse.com (Uwe Drechsel)
Date: Fri, 23 May 2014 17:06:04 +0200
Subject: [sles-beta] Beta 7
In-Reply-To: <20140523145504.5824657.73184.3242@softwareag.com>
References: <20140523145504.5824657.73184.3242@softwareag.com>
Message-ID: <20140523150604.GT6184@suse.de>

On Fri, May 23, Dick Waite wrote:

> the road again but I have not seen any word about Beta7 which I
> thought was today, could have missed it I have been under the earth
> most of the day.

We are currently uploading, stay tuned...

(We'll send out announcements later)


Uwe 

-- 
mathematician, n:
   Someone who believes imaginary things appear right before your i's.

From fcrozat at suse.com  Fri May 23 10:58:24 2014
From: fcrozat at suse.com (Frederic Crozat)
Date: Fri, 23 May 2014 18:58:24 +0200
Subject: [sles-beta] [ANNOUNCE] SLED Extension 12 Beta7 is available
Message-ID: <1400864304.16414.95.camel@par-r81vxc7.par.novell.com>


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

Dear Beta participants,

we are happy to announce Beta 7 release of

         SUSE Linux Enterprise Desktop Extension 12.

ISO images will be now available for download in a few hours (CDN is syncing). 
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, the second
DVD the sources and debuginfo packages.
The final product will not contain the debuginfo packages on the media.

To use this extension (together with upcoming SLES 12 Beta7):
 - start SLES installation
 - 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
  - Improvement in upgrade from SLED 11 SP3 to SLED12 (not yet fully
functional)

Known problems:
 bnc#865339 - Secure Boot not working on some systems (HP z220 for sure)
 bnc#861543 - ICAClient not installable
 bnc#871808 - VT freeze when switcing from runlevel 5 to runlevel 3
 - upgrading from SLE 11 SP3 is not yet working flawlessly, requiring
manual fixes

Happy testing!

        Your SUSE Linux Enterprise Team


-- 
Frederic Crozat
Project Manager Enterprise Desktop
SUSE


From behlert at suse.com  Fri May 23 13:40:28 2014
From: behlert at suse.com (Stefan Behlert)
Date: Fri, 23 May 2014 21:40:28 +0200
Subject: [sles-beta] [ANNOUNCE] SLES 12 Beta7 is available
Message-ID: <20140523194028.GC29389@suse.de>

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


Dear Beta participants,

we are happy to announce the seventh 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#871808 - SLES12 will halt at the enter runlevel 3 via the init 3 command
              (For both xdm and gdm)

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 Beta7 snapshot we have reached several milestones:
    o Continue update, performance and regression tests.
    o Continue intense 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.


Be aware that we have provided snapshots of two 'modules' at the download page
with this Beta 7:
  Module "Legacy":
      The Legacy Module supports your migration from SUSE Linux Enterprise 10
      and 11 and other systems to SUSE Linux Enterprise 12, by providing
      packages which are discontinued on SUSE Linux Enterprise Server, but
      which you may rely on, such as: CyrusIMAP, BSD like ftp client, sendmail,
      IBM Java6.
      Access to the Legacy Module is included in your SUSE Linux Enterprise
      Server subscription. The module has a different lifecycle than SUSE Linux
      Enterprise Server itself; please check the Release Notes for further
      details.

  Module "Web & Scripting":
        The SUSE Linux Enterprise Web and Scripting Module delivers a
        comprehensive suite of scripting languages, frameworks, and related tools
        helping developers and systems administrators accelerate the creation of
        stable, modern web applications.
        Access to the Web and Scripting Module is included in your SUSE Linux
        Enterprise Server subscription. The module has a different lifecycle
        than SUSE Linux Enterprise Server itself; please check the Release
        Notes for further details.

Note that both are provided "as is" and not all packages that will go into them
are already contained in them. We recommend to use them through the
repositories available online after registration. 



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 Dick.Waite at softwareag.com  Sat May 24 00:45:43 2014
From: Dick.Waite at softwareag.com (Waite, Dick)
Date: Sat, 24 May 2014 06:45:43 +0000
Subject: [sles-beta] Beta 7 - Manual Interaction
Message-ID: <46AC8C81C10B8C48820201DF2AE1D76D537B98BB@hqmbx6.eur.ad.sag>

Grand New Damp Day in Darmstadt,

Known issues (selection):
 (several)  - upgrading from SLE 11 SP3 is not working flawlessly, requiring manual interaction;

Downloading now, but we have all seen there are issues running the "upgrade". Would a A4 page of notes from your good developers / QE staff giving us a little "cheat sheet" on what and when the manual interactions are required. They have managed to get an upgrade to work, so why not give us some of the bits and bobs they have had to do to achieve and good upgrade. Without that info each of us is going to fall into the same hole, say some words we should not and work out our own work-a-round. Some might even send some words back to the grand list, some might not.

Give us the benefits of your own experiences please so we all don't fall into the same holes.

Wishing you all a grand day with Beta7

__R

________________________________________
From: sles-beta-bounces at lists.suse.com [sles-beta-bounces at lists.suse.com] on behalf of Uwe Drechsel [uwedr at suse.com]
Sent: 23 May 2014 17:06
To: sles-beta at lists.suse.com
Subject: Re: [sles-beta] Beta 7

On Fri, May 23, Dick Waite wrote:

> the road again but I have not seen any word about Beta7 which I
> thought was today, could have missed it I have been under the earth
> most of the day.

We are currently uploading, stay tuned...

(We'll send out announcements later)


Uwe

--
mathematician, n:
   Someone who believes imaginary things appear right before your i's.
_______________________________________________
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 rbrown at suse.de  Sat May 24 05:58:51 2014
From: rbrown at suse.de (Richard Brown)
Date: Sat, 24 May 2014 13:58:51 +0200
Subject: [sles-beta] Beta 7 - Manual Interaction
In-Reply-To: <46AC8C81C10B8C48820201DF2AE1D76D537B98BB@hqmbx6.eur.ad.sag>
References: <46AC8C81C10B8C48820201DF2AE1D76D537B98BB@hqmbx6.eur.ad.sag>
Message-ID: <237af846bd86b19d4b7053296d265d34@suse.de>

On 2014-05-24 08:45, Waite, Dick wrote:
> Grand New Damp Day in Darmstadt,
> 
> Known issues (selection):
>  (several)  - upgrading from SLE 11 SP3 is not working flawlessly,
> requiring manual interaction;
> 
> Downloading now, but we have all seen there are issues running the
> "upgrade". Would a A4 page of notes from your good developers / QE
> staff giving us a little "cheat sheet" on what and when the manual
> interactions are required. They have managed to get an upgrade to
> work, so why not give us some of the bits and bobs they have had to do
> to achieve and good upgrade. Without that info each of us is going to
> fall into the same hole, say some words we should not and work out our
> own work-a-round. Some might even send some words back to the grand
> list, some might not.
> 
> Give us the benefits of your own experiences please so we all don't
> fall into the same holes.
> 
> Wishing you all a grand day with Beta7
> 
> __R
> 

Good Day,

My colleagues and I test many different permutations of upgrades, 
starting with different versions, filesystems, package selections, and 
then upgrading. From what I can tell, it seems to me that it is specific 
combinations that are presenting issues, but I cant easily find which 
ones have what issues to share with you.

Speaking from my own experience, here's how my upgrade test using Beta 7 
went - I primarily test the HA Extension and therefore test the upgrade 
of both SLES and HA at the same time

* Starting with two servers running SLES 11 SP3, installed on ext3 with 
the Minimal & Base software patterns, as well as the HA Extension with 
the High Availability pattern.
* Both have configured iSCSI initiators talking to a iSCSI LIO Target
* Servers are configured in a simple 2 Node HA Cluster, with a SBD 
STONITH resource and the resources required for a shared ocfs2 volume, 
the storage for both provided by the iSCSI configuration.
* Upgraded started from the SLE 12 Server Beta 7 ISO
* Configured Network
* Skipped SCC Registration on one server, registered on the other. 
(Wanted to test whether that caused differences in upgrade - it did not)
* Added SLE 12 HA Extension Beta 7 as an Add-On product from a Network 
Installation server on one server, as an ISO on the other (Wanted to 
test whether that caused differences in upgrade - it did not)
* Reviewed upgrade proposal on the 'Installation Summary' page, looked 
sane, so proceeded
* Upgrade completed without any reported issue, both systems booted into 
SLES 12 + HA 12 Beta 7
* Tests on the 'Base System' (SLES 12) all passed, even some expected 
issues such as the iSCSI device names changing (old names were still 
present for compatibility)
* Tests on HA weren't as successful - it looks like the 
/etc/corosync/corosync.conf file needs manual interaction to upgrade it 
to SLE 12's expected structure and parameters
  - "aisexec" section of the configuration file is obsolete and needs to 
be removed
  - "quorum" section of the configuration file required in SLE 12 is 
missing and needs to be added manually
  - "cluster_name" parameter in the totem section of the configuration 
file is missing and needs to be added manually
* OCFS2 also requires some manual interaction to upgrade the filesystem 
before ocfs2 can be mounted (This was expected, and should be documented 
for SLE 12 HA upgrades)
  - tune.ocfs2 --update-cluster-stack

I expect we might also find a few other manual steps for upgrading SLE 
11 SP3 HA clusters to SLE 12, but that is the story so far.

So from my perspective, a basic SLES 11 to SLES 12 upgrade works fine, 
I'd recommend that you go ahead and try it yourself, along with any 
local procedures you regularly follow during upgrades. It will help us 
get a better picture of the current state of upgrades, and if you do run 
into issues that we've already found, we should be in a position to help 
with everything we've found once you report them.

-- 
-------------------------------------------------------------------
   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 gregg at ricis.com  Sat May 24 11:34:14 2014
From: gregg at ricis.com (Gregory D. Rosenberg)
Date: Sat, 24 May 2014 12:34:14 -0500
Subject: [sles-beta] Beta 7 - Manual Interaction
In-Reply-To: <46AC8C81C10B8C48820201DF2AE1D76D537B98BB@hqmbx6.eur.ad.sag>
References: <46AC8C81C10B8C48820201DF2AE1D76D537B98BB@hqmbx6.eur.ad.sag>
Message-ID: <AE89DDD5-ABE7-448A-A00B-A2AD87054D53@ricis.com>

Good afternoon Waite,

I second that notion. I would love to see the developers post any issues to the site in near-real time and maybe offer a summary at the end of some interval of time. One or Two weeks might be worth considering. Alternatively a simple web page could be setup where the developers can post issues and we can reference those daily or periodically at least.

I have to say that I am really darned impressed with the work the SuSE developers have done in SLES 12. I plan to do lots of AD, DFS, remote access using different scenarios, and testing remote management.

I wish all a happy Memorial Day Weekend :-)

The joy of playing with SLES 12 for a good part of this weekend will make for a great undisturbed time in kicking the tires. TCFN

On May 24, 2014, at 01:45 CDT, Waite, Dick <Dick.Waite at softwareag.com> wrote:

> Grand New Damp Day in Darmstadt,
> 
> Known issues (selection):
> (several)  - upgrading from SLE 11 SP3 is not working flawlessly, requiring manual interaction;
> 
> Downloading now, but we have all seen there are issues running the "upgrade". Would a A4 page of notes from your good developers / QE staff giving us a little "cheat sheet" on what and when the manual interactions are required. They have managed to get an upgrade to work, so why not give us some of the bits and bobs they have had to do to achieve and good upgrade. Without that info each of us is going to fall into the same hole, say some words we should not and work out our own work-a-round. Some might even send some words back to the grand list, some might not.
> 
> Give us the benefits of your own experiences please so we all don't fall into the same holes.
> 
> Wishing you all a grand day with Beta7
> 
> __R
> 
> ________________________________________
> From: sles-beta-bounces at lists.suse.com [sles-beta-bounces at lists.suse.com] on behalf of Uwe Drechsel [uwedr at suse.com]
> Sent: 23 May 2014 17:06
> To: sles-beta at lists.suse.com
> Subject: Re: [sles-beta] Beta 7
> 
> On Fri, May 23, Dick Waite wrote:
> 
>> the road again but I have not seen any word about Beta7 which I
>> thought was today, could have missed it I have been under the earth
>> most of the day.
> 
> We are currently uploading, stay tuned...
> 
> (We'll send out announcements later)
> 
> 
> Uwe
> 
> --
> mathematician, n:
>   Someone who believes imaginary things appear right before your i's.
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://cp.mcafee.com/d/1jWVIp4x0SyNuVEVhpd7bXxKVJ6Wrz2bPMVUSztdNx4QsEIcCQrI6zBcQsL6zBwQsCQrFKfCzBdxBYShzV4y2EOJaDbCUOJaDbCSkXInupvW_9TKOYO_RXBQQmnej7cLcLfsJt6OaqGabfaxVZicHs3jq9JATsTsS03fBiteETj-nMjlS67OFek7qVg_W5O7PQTg_W5O7PQKgGT2TQ1hYGjFR6WvOVJZYsCr1vF6y0QJQf-xsxYZdbFEw6vDFEw76y0Kq81LodWuq80S4_zJFOH0SMOrD9ad
> 
> 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://cp.mcafee.com/d/k-Kr6hAg6hESyNuVEVhpd7bXxKVJ6Wrz2bPMVUSztdNx4QsEIcCQrI6zBcQsL6zBwQsCQrFKfCzBdxBYShzV4y2EOJaDbCUOJaDbCSkXInupvW_9TKOYO_RXBQQmnej7cLcLfsJt6OaqGabfaxVZicHs3jqpJATsTsS02FlSpzo_F7BPt3_En8vfiV2Hsbvg57OFeDkrF_bCTTNOpI5-Aq83iTg_W5O7PQQKCy0p-uCy0sq82VEw6ZwTFVEw3oj-eSDaI3r39LQ6sKr_B9o2u
> 
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://cp.mcafee.com/d/1jWVIgdEInKqekmjhO-UrKrhKCUMyYYeudETjsohd7ab39J6X1EVjd7bNEVod79J6WrzVEVjopvdAo-h8wGcHiFOVKcHiFOVJBeX5TCn-LOtXILcLZuVtd5BPANPbPbPTbnhIyCGyyPOEuvkzaT0QSOrpdTdTdw0PVkDjGdQ_BY4RtxxYGjB1SKkf-xsxYZdQf-xsxYZbAaJMJZ0kvaAWthKDYKrvv79CMnWhEwdbt3_En8vfjiWq81DVWq81NEwbCy0rS3uDCy0dxfUXqsGMdIcCUzInkQDGWXtA



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 darrent at akurit.com.au  Sun May 25 01:15:19 2014
From: darrent at akurit.com.au (Darren Thompson)
Date: Sun, 25 May 2014 17:15:19 +1000
Subject: [sles-beta] GEO Clusters, where to get basic information
Message-ID: <CAEUhfEfzjD8Y2Jk7n34Y8=8TA3hCWG6-4QNnsT9RhQruzNvt2w@mail.gmail.com>

Team

I have been using SLES HA for some time but have no exposure to SLES GEO
Clusters.

Where is a good source of "basic/orientation' information for someone
familiar with HA but no exposure to GEO?

What is it?
What are it's use cases and where should it NOT bet used?
What is the basic principle on which it operates?
Are there configuration example/templates?

Thanks in advance.
-- 

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/20140525/5ba4a110/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/20140525/5ba4a110/attachment.jpg>

From darrent at akurit.com.au  Sun May 25 01:57:23 2014
From: darrent at akurit.com.au (Darren Thompson)
Date: Sun, 25 May 2014 17:57:23 +1000
Subject: [sles-beta] SLE release notes still refer to SLES11
Message-ID: <CAEUhfEdMF8RntkVVyxVa26JM4zKiv+ZPbJzu6+xCM_4QZ836sg@mail.gmail.com>

Hi team

Just a small point, the SLES release notes still refer to SLES11 (at least
as far as "Introduction/Chnatper1" section... I'll read through to see if
there are other SLES11 references).

-- 

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

From rbrown at suse.de  Sun May 25 02:01:05 2014
From: rbrown at suse.de (Richard Brown)
Date: Sun, 25 May 2014 10:01:05 +0200
Subject: [sles-beta] GEO Clusters, where to get basic information
In-Reply-To: <CAEUhfEfzjD8Y2Jk7n34Y8=8TA3hCWG6-4QNnsT9RhQruzNvt2w@mail.gmail.com>
References: <CAEUhfEfzjD8Y2Jk7n34Y8=8TA3hCWG6-4QNnsT9RhQruzNvt2w@mail.gmail.com>
Message-ID: <3261cdbdcf6c9a3cd57d3c63b542280c@suse.de>

On 2014-05-25 09:15, Darren Thompson wrote:
> Team
> 
> I have been using SLES HA for some time but have no exposure to SLES
> GEO Clusters.
> 
> Where is a good source of "basic/orientation' information for someone
> familiar with HA but no exposure to GEO?

The manual is pretty good :) 
https://www.suse.com/documentation/sle_ha/singlehtml/book_sleha/book_sleha.html#cha.ha.geo

> What is it?

GEO is an Extension to the SLE HA Extension, which enables you to build 
'A Cluster of Clusters' spread across large Geographic distances 
(Separate Cities/States/Countries/Continents) with services being 
started/stopped on the separate cluster based on the network 
availability (or lack thereof) of the other locations.

> What are it's use cases and where should it NOT bet used?

Its typical use case is 'Disaster Recovery' or 'Business Continuity'. A 
cluster at Site A also has its HA resources and data replicated/mirrored 
at Site B which is many miles away (eg. over 30km) with high latency 
connection (eg over 15ms, too high for 'traditional' HA Local or Metro 
Area clusters). In the event of Site A 'failing', all of the resources 
that usually 'live' at Site A can be started at Site B, providing your 
business with a way to continue operating despite the loss of Site A.

It probably shouldn't be used when you're clusters are on the same local 
subnet and/or when latency is sufficiently low to make Metro clustering 
viable - why complicate matters if a simple option is available?

> What is the basic principle on which it operates?

GEO introduces the concept of 'Tickets' - Tickets are tokens which can 
be granted/revoked from a Cluster, and used as a dependency for the 
operation of Cluster Resources. eg. a ticket called TicketA might be 
required by all the Resources that are typically at Site A. When the 
Ticket is revoked from Site A and granted to the Cluster at Site B, Site 
B is then the only cluster able to operate the services that rely on 
TicketA's presence. The distribution of Tickets is handled by a piece of 
software called the 'booth'

Booth is an agent which runs on each cluster, and is configured to be 
aware of the other sites involved in your Geo cluster. Using UDP, it's 
designed to work in high latency environments. Booth usually has long 
expiration times on Tickets, given significant protection against brief 
connectivity issues. This comes at the potential expense of taking 
longer before automatically failing over, but this isn't the sort of 
thing you'd want the software to make a mistake about - more rapid 
allocation of tickets can of course be done by sysadmins.

Arbitrators are special machines running Booth but not running HA 
Clusters. This allows you to avoid split brain scenarios by having a 3rd 
independent server arbitrate about the status of the other Sites. 
Arbitrators are not necessary if you have an odd number of Clusters in 
your Geo Cluster.
Taking my simple 2 site example from earlier, if Sites A and B can't 
communicate with each other, there is no way Booth on either cluster can 
automatically figure out which site is operational. An arbitrator 
running elsewhere however should be able to provide enough information 
to determine whether Site A or B is 'down' or that both sites are 
actually 'up' and it's just a failure of the network link between Site A 
and B.

> Are there configuration example/templates?

As the details depend totally on the structure of your network and the 
local resources you want to enable for Geo clustering, templates are a 
tricky thing to provide.
The manual has some very simple examples which should be enough to get 
you started.

Best Regards,

- 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 darrent at akurit.com.au  Sun May 25 03:02:14 2014
From: darrent at akurit.com.au (Darren Thompson)
Date: Sun, 25 May 2014 19:02:14 +1000
Subject: [sles-beta] GEO Clusters, where to get basic information
In-Reply-To: <3261cdbdcf6c9a3cd57d3c63b542280c@suse.de>
References: <CAEUhfEfzjD8Y2Jk7n34Y8=8TA3hCWG6-4QNnsT9RhQruzNvt2w@mail.gmail.com>
	<3261cdbdcf6c9a3cd57d3c63b542280c@suse.de>
Message-ID: <CAEUhfEdisJMJzPOAXkUqmrQwnErx__ijz5O34FpH-Wtuw+fJtQ@mail.gmail.com>

Richard

A very detailed and informative answer; Thank you.

Darren


On 25 May 2014 18:01, Richard Brown <rbrown at suse.de> wrote:

> On 2014-05-25 09:15, Darren Thompson wrote:
>
>> Team
>>
>> I have been using SLES HA for some time but have no exposure to SLES
>> GEO Clusters.
>>
>> Where is a good source of "basic/orientation' information for someone
>> familiar with HA but no exposure to GEO?
>>
>
> The manual is pretty good :) https://www.suse.com/documentation/sle_ha/
> singlehtml/book_sleha/book_sleha.html#cha.ha.geo
>
>  What is it?
>>
>
> GEO is an Extension to the SLE HA Extension, which enables you to build 'A
> Cluster of Clusters' spread across large Geographic distances (Separate
> Cities/States/Countries/Continents) with services being started/stopped
> on the separate cluster based on the network availability (or lack thereof)
> of the other locations.
>
>  What are it's use cases and where should it NOT bet used?
>>
>
> Its typical use case is 'Disaster Recovery' or 'Business Continuity'. A
> cluster at Site A also has its HA resources and data replicated/mirrored at
> Site B which is many miles away (eg. over 30km) with high latency
> connection (eg over 15ms, too high for 'traditional' HA Local or Metro Area
> clusters). In the event of Site A 'failing', all of the resources that
> usually 'live' at Site A can be started at Site B, providing your business
> with a way to continue operating despite the loss of Site A.
>
> It probably shouldn't be used when you're clusters are on the same local
> subnet and/or when latency is sufficiently low to make Metro clustering
> viable - why complicate matters if a simple option is available?
>
>  What is the basic principle on which it operates?
>>
>
> GEO introduces the concept of 'Tickets' - Tickets are tokens which can be
> granted/revoked from a Cluster, and used as a dependency for the operation
> of Cluster Resources. eg. a ticket called TicketA might be required by all
> the Resources that are typically at Site A. When the Ticket is revoked from
> Site A and granted to the Cluster at Site B, Site B is then the only
> cluster able to operate the services that rely on TicketA's presence. The
> distribution of Tickets is handled by a piece of software called the 'booth'
>
> Booth is an agent which runs on each cluster, and is configured to be
> aware of the other sites involved in your Geo cluster. Using UDP, it's
> designed to work in high latency environments. Booth usually has long
> expiration times on Tickets, given significant protection against brief
> connectivity issues. This comes at the potential expense of taking longer
> before automatically failing over, but this isn't the sort of thing you'd
> want the software to make a mistake about - more rapid allocation of
> tickets can of course be done by sysadmins.
>
> Arbitrators are special machines running Booth but not running HA
> Clusters. This allows you to avoid split brain scenarios by having a 3rd
> independent server arbitrate about the status of the other Sites.
> Arbitrators are not necessary if you have an odd number of Clusters in your
> Geo Cluster.
> Taking my simple 2 site example from earlier, if Sites A and B can't
> communicate with each other, there is no way Booth on either cluster can
> automatically figure out which site is operational. An arbitrator running
> elsewhere however should be able to provide enough information to determine
> whether Site A or B is 'down' or that both sites are actually 'up' and it's
> just a failure of the network link between Site A and B.
>
>  Are there configuration example/templates?
>>
>
> As the details depend totally on the structure of your network and the
> local resources you want to enable for Geo clustering, templates are a
> tricky thing to provide.
> The manual has some very simple examples which should be enough to get you
> started.
>
> Best Regards,
>
> - 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)
> -------------------------------------------------------------------
>



-- 

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

From darrent at akurit.com.au  Sun May 25 03:04:27 2014
From: darrent at akurit.com.au (Darren Thompson)
Date: Sun, 25 May 2014 19:04:27 +1000
Subject: [sles-beta] ISNS server software not installable/configurable in
	YAST on SLES12B7
Message-ID: <CAEUhfEd2gK6uzvFndO5OdwVr7S+NxSRECa+M4pQwST4j-wqHbw@mail.gmail.com>

Team

Looks like there is still an issue with the ISNS server installation
process in SLES12B7.

I get a "service start" error during YAST2 ISNS configuration and it does
not seem to "take" any settings.

-- 

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

From mge at suse.com  Sun May 25 11:10:49 2014
From: mge at suse.com (Matthias G. Eckermann)
Date: Sun, 25 May 2014 19:10:49 +0200
Subject: [sles-beta] SLE release notes still refer to SLES11
In-Reply-To: <CAEUhfEdMF8RntkVVyxVa26JM4zKiv+ZPbJzu6+xCM_4QZ836sg@mail.gmail.com>
References: <CAEUhfEdMF8RntkVVyxVa26JM4zKiv+ZPbJzu6+xCM_4QZ836sg@mail.gmail.com>
Message-ID: <20140525171049.GB4508@suse.com>

Hello Darren and all,

On 2014-05-25 T 17:57 Darren Thompson wrote:

> Just a small point, the SLES release notes still refer
> to SLES11 (at least as far as "Introduction/Chnatper1"
> section... I'll read through to see if there are other
> SLES11 references).

thanks, and yes, this is known: the Release Notes
still contain SLE 11 parts while we are transitioning
the information from 11 to 12. This way we can track
that no relevant information is lost.

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 darrent at akurit.com.au  Sun May 25 22:44:48 2014
From: darrent at akurit.com.au (Darren Thompson)
Date: Mon, 26 May 2014 14:44:48 +1000
Subject: [sles-beta] Disc config error in Autoyast execution
Message-ID: <CAEUhfEcfm+d1t8o0xBxrZ8-8KOrJLkBbgddsPx+ue2mzeCUPMg@mail.gmail.com>

Team

I did a default SLES12B7 install.

I then took the autoinstall.xml file, opened it in the "autoinstallation"
yast2 module. (BTW, it looks like there is a type on the Yast2 option as it
seems to be called autoinstallatior <= notice the ending 'r' and not 'n' )

I made minor modifications (cloned the machines actual disk config, added a
couple of users, set Root password and change language setting).

All of this passed the "syntax parser" of the "autoinstalltion" module.

When I do an autoyast install using the resulting autoyast file it errors
on the disk configuration (see attached screen shot and copy of autoyast
file).

Could someone more familiar with these files please review to see if the
syntax is correct etc.

If syntax is correct then there is a bug in the autoyast installer, when
processing config files.

If the symtax is incorrect then there is a bug in the "autoinstallation"
yast2 module, in that it allows the creation of an invalid syntax file.

I can raise a SR but would like confirmation as to which of these two
options it should be raised against.

Regards
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/20140526/b39fb28e/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/20140526/b39fb28e/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AutoYast-error.png
Type: image/png
Size: 36167 bytes
Desc: not available
URL: <http://lists.suse.com/mailman/private/sles-beta/attachments/20140526/b39fb28e/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test01-autoyast.xml
Type: text/xml
Size: 13903 bytes
Desc: not available
URL: <http://lists.suse.com/mailman/private/sles-beta/attachments/20140526/b39fb28e/attachment.xml>