From fcrozat at suse.com  Mon Mar 24 02:31:04 2014
From: fcrozat at suse.com (Frederic Crozat)
Date: Mon, 24 Mar 2014 09:31:04 +0100
Subject: [sles-beta] SLES12 Beta3 x86_64 shutdown ?
In-Reply-To: <532C74FC.1050100@netlab1.net>
References: <40637DBB36AF3941B243A286A432CA0B0EFA7852@HXMB12.pnet.ch>
	<532C74FC.1050100@netlab1.net>
Message-ID: <1395649864.6754.65.camel@par-r81vxc7.par.novell.com>

Le vendredi 21 mars 2014 ? 17:21 +0000, Joe Doupnik a ?crit :
> Urs,
>     I share the same worry about the rapid shutdown, and the
> apparently lacking final sync. I was going to wait awhile until I have
> a fail-over cluster installed with my stuff for which a graceful
> plodding shutdown is far better than pretending we closed the cover of
> a laptop. "My stuff" also uses regular start/stop scripts with shell
> programming innards, and I will be curious to know how that is handled
> by systemd.

Why do you think it is missing a final sync ?

systemd does a final sync before shutdown is complete..

-- 
Frederic Crozat <fcrozat at suse.com>
SUSE


From jrd at netlab1.net  Mon Mar 24 02:34:13 2014
From: jrd at netlab1.net (Joe Doupnik)
Date: Mon, 24 Mar 2014 08:34:13 +0000
Subject: [sles-beta] SLES12 Beta3 x86_64 shutdown ?
In-Reply-To: <1395649864.6754.65.camel@par-r81vxc7.par.novell.com>
References: <40637DBB36AF3941B243A286A432CA0B0EFA7852@HXMB12.pnet.ch>	<532C74FC.1050100@netlab1.net>
	<1395649864.6754.65.camel@par-r81vxc7.par.novell.com>
Message-ID: <532FEE05.6010100@netlab1.net>

On 24/03/2014 08:31, Frederic Crozat wrote:
> Le vendredi 21 mars 2014 ? 17:21 +0000, Joe Doupnik a ?crit :
>> Urs,
>>      I share the same worry about the rapid shutdown, and the
>> apparently lacking final sync. I was going to wait awhile until I have
>> a fail-over cluster installed with my stuff for which a graceful
>> plodding shutdown is far better than pretending we closed the cover of
>> a laptop. "My stuff" also uses regular start/stop scripts with shell
>> programming innards, and I will be curious to know how that is handled
>> by systemd.
> Why do you think it is missing a final sync ?
>
> systemd does a final sync before shutdown is complete..
>
-------------
     Because with our feeble human eyes we don't see it. Perhaps we 
blink at the wrong moment.
     Joe D.

From gjn at gjn.priv.at  Mon Mar 24 03:41:20 2014
From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer)
Date: Mon, 24 Mar 2014 10:41:20 +0100
Subject: [sles-beta] grub2-efi install Beta 3
Message-ID: <2468522.paB1yiRxCv@gjn.priv.at>

hello,

is it possible that are dependencies to GNOME in grub2-efi ?

I make a new installation on my system but three times when I unmark the Gnome 
Software i have a stop by the installation with the grub2-efi Packet, when I 
don't unmark the GNOME the installation is OK ?
-- 
mit freundlichen Gr??en / best Regards,

  G?nther J. Niederwimmer

From fcrozat at suse.com  Mon Mar 24 03:55:53 2014
From: fcrozat at suse.com (Frederic Crozat)
Date: Mon, 24 Mar 2014 10:55:53 +0100
Subject: [sles-beta] grub2-efi install Beta 3
In-Reply-To: <2468522.paB1yiRxCv@gjn.priv.at>
References: <2468522.paB1yiRxCv@gjn.priv.at>
Message-ID: <1395654953.6754.74.camel@par-r81vxc7.par.novell.com>

Le lundi 24 mars 2014 ? 10:41 +0100, G?nther J. Niederwimmer a ?crit :
> hello,
> 
> is it possible that are dependencies to GNOME in grub2-efi ?

No :)

> I make a new installation on my system but three times when I unmark the Gnome 
> Software i have a stop by the installation with the grub2-efi Packet, when I 
> don't unmark the GNOME the installation is OK ?

Maybe another package in the GNOME dependency tree is changing grub2-efi
behaviour but that looks strange.

Please open a service request to track this issue.

-- 
Frederic Crozat <fcrozat at suse.com>
SUSE


From mbrookhuis at suse.com  Mon Mar 24 04:08:11 2014
From: mbrookhuis at suse.com (Michael Brookhuis)
Date: Mon, 24 Mar 2014 10:08:11 +0000
Subject: [sles-beta] SLES12 network interface names
In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0EFA83C2@HXMB12.pnet.ch>
References: <40637DBB36AF3941B243A286A432CA0B0EFA83C2@HXMB12.pnet.ch>
Message-ID: <5330121B020000A8000A7C6B@nat28.tlf.novell.com>

Hi,

I have a least 2 other big customers that will run into this same problem.

Michael

>>> On Mon, Mar 24, 2014 at 10:38, <urs.frey at post.ch> wrote: 
> Hi 
>  
> I had a look at the wiki you provided. 
> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterface 
> Names/ 
>  
> My concern is, that I have to know the proper network interface name before  
> I create the autoyast autoinst.xml profile. 
> This could be accomplished perfectly when having the eth names. 
>  
> Now with the new naming rules I run into problems as I do not know the pci  
> bus number before powering the server. 
> I sometimes do not even know the kind of network interface HW built in in my  
> ProLiant servers. Sometimes Broadcom, sometimes, Intel sometimes Emulex NIC,  
> who knows. 
>  
> Even when having installed on VMWare and changing the HW emulation level,  
> the NIC name changes. 
> This is really not a way to go, as with every ESXi update the HW emulation  
> level may change. 
> I would like to have my VMware installation living over years with no manual  
> interaction necessary 
>  
> I see a big challenge to get autoyast running .. 
>  
> Best regards 
>  
>  
> Urs Frey 
> Post CH AG 
> Informationstechnologie 
> IT Betrieb 
> Webergutstrasse 12 
> 3030 Bern (Zollikofen) 
> Telefon : ++41 (0)58 338 58 70 
> FAX     : ++41 (0)58 667 30 07 
> E-Mail:   urs.frey at post.ch<mailto:urs.frey at post.ch> 
>  
>  
>  
>  



From mge at suse.com  Mon Mar 24 04:22:16 2014
From: mge at suse.com (Matthias G. Eckermann)
Date: Mon, 24 Mar 2014 11:22:16 +0100
Subject: [sles-beta] Beta 3, "startx" as non-root fails
In-Reply-To: <532D849A.8010108@netlab1.net>
References: <532C8D96.7000107@netlab1.net>
	<a90ecd8a-7754-4d15-9f0e-635a948d9333@email.android.com>
	<532D849A.8010108@netlab1.net>
Message-ID: <20140324102216.GA11714@suse.com>

On 2014-03-22 T 12:39 +0000 Joe Doupnik wrote:
>     Permissions on /usr/bin/Xorg: need to be suid root (-rws--x--x).

Yep, and that's not good as a default.

I suggest to add this to /etc/permissions.local,
thus bot requirements are fulfilled:
- secure default
- usable as you need it

> Compare with SLES 11 et al.
> Now it startx works for a regular user.

so long -
	MgE

> On 21/03/2014 22:34, Matthias G. Eckermann wrote:
> >Hello Joe and all,
> >
> >I remember a discussion ~1year ago,
> >but not the details (will check on monday),
> >and it might be a security feature
> >(the screenshots support this idea: see the last two lines!).
> >
> >I know, I know, ...:-(
> >
> >However, if it really is a security feature,
> >I will have to prepare the battle carefully:
> >it will be a battle against myself,
> >wearing the security hat --
> >and usually security wins.
> >
> >Enjoy the weekend -
> >MgE
> >
> >
> >On 21. M?rz 2014 20:05:58 MEZ, Joe Doupnik <jrd at netlab1.net> wrote:
> >>    As an ordinary user on SLES, login to the console and give command
> >>startx. After a significant pause the command fails. Attached is a
> >>screen capture of it.
> >>     Root, by contrast, does get the Gnome GUI.
> >>   As a test I did   chmod a+w /var/log   as root, returned to being a
> >>normal user and tried again. Still failure, as shown in the second
> >>screen capture.
> >>     Running as a VMware ESXi guest.
> >>     Joe D.
> >>
> >>
> >>
> >>------------------------------------------------------------------------
> >>
> >>_______________________________________________
> >>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 fcrozat at suse.com  Mon Mar 24 04:24:34 2014
From: fcrozat at suse.com (Frederic Crozat)
Date: Mon, 24 Mar 2014 11:24:34 +0100
Subject: [sles-beta] keyboard during installation
In-Reply-To: <53300693.1060608@oxya.com>
References: <53300693.1060608@oxya.com>
Message-ID: <1395656674.6754.79.camel@par-r81vxc7.par.novell.com>

Le lundi 24 mars 2014 ? 11:18 +0100, Matthieu Fatrez a ?crit :
> Hi all,
> 
> When I start a new installation, I setup language and keyboard (i keep
> the language in english, but I change the keyboard layout to french).
> Next step is the partition layout of disks. When I want to modify the
> size of the partition, the keyboard is still in English. Is it normal
> or it will apply after the reboot?

As mentioned in the Beta3 (and Beta2) announcement, it is a known issue
which is still under investigation.

-- 
Frederic Crozat <fcrozat at suse.com>
SUSE


From jrd at netlab1.net  Mon Mar 24 04:54:48 2014
From: jrd at netlab1.net (Joe Doupnik)
Date: Mon, 24 Mar 2014 10:54:48 +0000
Subject: [sles-beta] SLES12 network interface names
In-Reply-To: <5330121B020000A8000A7C6B@nat28.tlf.novell.com>
References: <40637DBB36AF3941B243A286A432CA0B0EFA83C2@HXMB12.pnet.ch>
	<5330121B020000A8000A7C6B@nat28.tlf.novell.com>
Message-ID: <53300EF8.5030108@netlab1.net>

     Try wireshark with ethN. No captures, not even with interface kind 
ANY in wireshark.
     Try standalone vsftpd. No data channel.
     At this point I think the networking material needs a careful 
review. The s-d ens* approach is an impediment, vsftpd within xinetd is 
non-usable, standalone vsftpd can't open a data channel, wireshark sees 
nothing, and perhaps there are other items yet to be discovered.
     Joe D.

On 24/03/2014 10:08, Michael Brookhuis wrote:
> Hi,
>
> I have a least 2 other big customers that will run into this same problem.
>
> Michael
>
>>>> On Mon, Mar 24, 2014 at 10:38, <urs.frey at post.ch> wrote:
>> Hi
>>   
>> I had a look at the wiki you provided.
>> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterface
>> Names/
>>   
>> My concern is, that I have to know the proper network interface name before
>> I create the autoyast autoinst.xml profile.
>> This could be accomplished perfectly when having the eth names.
>>   
>> Now with the new naming rules I run into problems as I do not know the pci
>> bus number before powering the server.
>> I sometimes do not even know the kind of network interface HW built in in my
>> ProLiant servers. Sometimes Broadcom, sometimes, Intel sometimes Emulex NIC,
>> who knows.
>>   
>> Even when having installed on VMWare and changing the HW emulation level,
>> the NIC name changes.
>> This is really not a way to go, as with every ESXi update the HW emulation
>> level may change.
>> I would like to have my VMware installation living over years with no manual
>> interaction necessary
>>   
>> I see a big challenge to get autoyast running ..
>>   
>> Best regards
>>   
>>   
>> Urs Frey
>> Post CH AG
>> Informationstechnologie
>> IT Betrieb
>> Webergutstrasse 12
>> 3030 Bern (Zollikofen)
>> Telefon : ++41 (0)58 338 58 70
>> FAX     : ++41 (0)58 667 30 07
>> E-Mail:   urs.frey at post.ch<mailto:urs.frey at post.ch>
>>   
>>   
>>   
>>   
>
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta


From gjn at gjn.priv.at  Mon Mar 24 05:26:41 2014
From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer)
Date: Mon, 24 Mar 2014 12:26:41 +0100
Subject: [sles-beta] external LDAP Server and YaST2
Message-ID: <4733755.DqNpzEZh4K@gjn.priv.at>

Hello,

Only a question ;)

Why it is not possible to include in the doc files for YaST2 Module (LDAP) a 
correct *. ldif file, for a external ldap Server? It is always a trial and 
error Problem, to find out the correct configuration. In the Doc files you can't 
find the syntax.  
-- 
mit freundlichen Gr??en / best Regards,

  G?nther J. Niederwimmer

From behlert at suse.com  Mon Mar 24 05:58:03 2014
From: behlert at suse.com (Stefan Behlert)
Date: Mon, 24 Mar 2014 12:58:03 +0100
Subject: [sles-beta] yast sw_single module dying
In-Reply-To: <CF5227DE.21892%mail@sandervanvugt.nl>
References: <CF5227DE.21892%mail@sandervanvugt.nl>
Message-ID: <20140324115803.GO5461@suse.de>

Moin,

On Mar 21, 14 17:31:10 +0100, Sander van Vugt wrote:
> After starting yast sw_single from a terminal window in a graphical
> environment I?m able to enter a search string. Then it dies after selecting
> Accept. Doesn?t strike me as normal right?

Hm, are you sure it dies? "accept" is does not mean "search the entered
string", but "apply all changes". If you have done none, it finishes the
tool afterwards. (If you have changed stuff, you get an overview where you
can explicitly say 'continue' or 'finish').


"searching" for the string is done by either pressing the 'enter'-key or
the 'Search'-button.

        Stefan
> 
> -Sander
> 

-- 
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 behlert at suse.com  Mon Mar 24 06:01:43 2014
From: behlert at suse.com (Stefan Behlert)
Date: Mon, 24 Mar 2014 13:01:43 +0100
Subject: [sles-beta] Upgrade from 11-3 to 12-0 -- s390x iso's
In-Reply-To: <46AC8C81C10B8C48820201DF2AE1D76D5377CCBB@hqmbx6.eur.ad.sag>
References: <46AC8C81C10B8C48820201DF2AE1D76D5377CCBB@hqmbx6.eur.ad.sag>
Message-ID: <20140324120143.GP5461@suse.de>

Moin,

On Mar 23, 14 10:54:21 +0000, Waite, Dick wrote:
[...]
> 
> As I see no s390x iso's on your sites this is still on hold until beta4?

s390x isos should be visible. Be so kind to check again, maybe the mirror
local to you had not finished his update of the images for Beta3.
Unfortunately that is out of our control, and we are not able to check if
all mirrors have all images yet when we annoucne them :(


        Stefan
> 
> __R

-- 
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 behlert at suse.com  Mon Mar 24 06:06:54 2014
From: behlert at suse.com (Stefan Behlert)
Date: Mon, 24 Mar 2014 13:06:54 +0100
Subject: [sles-beta] grub2-efi install Beta 3
In-Reply-To: <2468522.paB1yiRxCv@gjn.priv.at>
References: <2468522.paB1yiRxCv@gjn.priv.at>
Message-ID: <20140324120654.GQ5461@suse.de>

Moin,

On Mar 24, 14 10:41:20 +0100, G?nther J. Niederwimmer wrote:
> hello,
> 
> is it possible that are dependencies to GNOME in grub2-efi ?

I assume you refer to grub2-x86_64-efi ?

This package only requires efibootmgr, grub2 and perl-Bootloader
explicitely, I see no hidden dependencies either.

> I make a new installation on my system but three times when I unmark the Gnome 
> Software i have a stop by the installation with the grub2-efi Packet, when I 
> don't unmark the GNOME the installation is OK ?

This could only be a strange side effect.
I made an installation with just "minimal pattern", and did not see an
issue, but that might not be representative.

        Stefan
> -- 
> mit freundlichen Gr??en / best Regards,
> 
>   G?nther J. Niederwimmer
-- 
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  Mon Mar 24 06:45:19 2014
From: Dick.Waite at softwareag.com (Waite, Dick)
Date: Mon, 24 Mar 2014 12:45:19 +0000
Subject: [sles-beta] Upgrade from 11-3 to 12-0 -- s390x iso's
Message-ID: <46AC8C81C10B8C48820201DF2AE1D76D5377D356@hqmbx6.eur.ad.sag>

Grand Afternoon,

Just had a look, I have ppc, x86_64, MINI-ISO-ppc and MINI-ISO-x86_64  in the SLE12-Server directory and in SLE-12-SDK just the ppc and x86_64. No ia64 or s390s. I'm looking in Partners.novell.com, *but* if I look at my Beta page I do see there are s390x iso's there. So they just have not found there way to partners yet, which is strange as the x86_64's were there very early on Friday...
SAG has a filter on download's and the iso's are to big which is why I use Partners... I'll give them a little more time to get to where I can download...

Sorry to create a wave, I should have looked on my Beta page before making noise.

__R
________________________________________
From: sles-beta-bounces at lists.suse.com [sles-beta-bounces at lists.suse.com] on behalf of Stefan Behlert [behlert at suse.com]
Sent: 24 March 2014 13:01
To: sles-beta at lists.suse.com
Subject: [Spam]: Re: [sles-beta] Upgrade from 11-3 to 12-0 -- s390x iso's

Moin,

On Mar 23, 14 10:54:21 +0000, Waite, Dick wrote:
[...]
>
> As I see no s390x iso's on your sites this is still on hold until beta4?

s390x isos should be visible. Be so kind to check again, maybe the mirror
local to you had not finished his update of the images for Beta3.
Unfortunately that is out of our control, and we are not able to check if
all mirrors have all images yet when we annoucne them :(


        Stefan
>
> __R

--
Stefan Behlert, SUSE LINUX
Project Manager Enterprise Server

Maxfeldstr. 5, D-90409 Nuernberg, Germany
Phone +49-911-74053-173
SUSE LINUX Products GmbH, Nuernberg; GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer, HRB 16746 (AG Nuernberg)
_______________________________________________
sles-beta mailing list
sles-beta at lists.suse.com
http://lists.suse.com/mailman/listinfo/sles-beta

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 behlert at suse.com  Mon Mar 24 07:59:21 2014
From: behlert at suse.com (Stefan Behlert)
Date: Mon, 24 Mar 2014 14:59:21 +0100
Subject: [sles-beta] [ANNOUNCE] SLES 12 Beta3 is available
In-Reply-To: <532C4A51.7090006@ucs.cam.ac.uk>
References: <20140321094543.GG5461@suse.de> <532C1F7E.2000607@ucs.cam.ac.uk>
	<20140321113026.GZ6054@suse.de> <532C2766.2010808@ucs.cam.ac.uk>
	<20140321115743.GB6054@suse.de> <532C4A51.7090006@ucs.cam.ac.uk>
Message-ID: <20140324135921.GY5461@suse.de>

Moin,

On Mar 21, 14 14:18:57 +0000, Simon Flood wrote:
> On 21/03/2014 11:57, Uwe Drechsel wrote:
>
>> Sorry for the trouble.
>>
>> We recently switched from Akami to Edgecast to improve the overall
>> download experience. The main server is still with Novell in the US,
>> Edgecast spreads from there.
>>
>> The last files have been uploaded a few hours ago, we'll keep an eye on
>> this.
>
> Hmm I'm still getting the Beta2 versions of both the MD5SUMS and SHA1SUMS 
> files.

Strange. As I was the one doing the upload for Beta 3 (I was on vacation
during Beta2, so I can't say what happened there), and checked these files
explicitely, I am more than a little bit surprised.

[...]
> Note the HA *SUMS files were correct at first attempt.

Well, as this is a different product, and uploaded in a different folder,
this may be treated by the mirrors quite differently.

[...]
>
> Unless others are seeing the same perhaps we should take this off-list. 

Uwe is looking into it.

But let me assure you: Every milestone we upload is checked at the last
point where we can for integrity.

Thanks for your report, we want to get issues with downloads fixed asap,
and these help us to ask the right questions with the service provider.

        Stefan


-- 
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 okir at suse.de  Mon Mar 24 08:36:50 2014
From: okir at suse.de (Olaf Kirch)
Date: Mon, 24 Mar 2014 15:36:50 +0100
Subject: [sles-beta] SLES12 network interface names
In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0EFA83C2@HXMB12.pnet.ch>
References: <40637DBB36AF3941B243A286A432CA0B0EFA83C2@HXMB12.pnet.ch>
Message-ID: <201403241536.50121.okir@suse.de>


Hi Urs,

On Monday 24 March 2014 10:38:57 urs.frey at post.ch wrote:
> Hi
> 
> I had a look at the wiki you provided.
> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfac
> eNames/
> 
> My concern is, that I have to know the proper network interface name before
>  I create the autoyast autoinst.xml profile. This could be accomplished
>  perfectly when having the eth names.
> 
> Now with the new naming rules I run into problems as I do not know the pci
>  bus number before powering the server. I sometimes do not even know the
>  kind of network interface HW built in in my ProLiant servers. Sometimes
>  Broadcom, sometimes, Intel sometimes Emulex NIC, who knows.
> 
> Even when having installed on VMWare and changing the HW emulation level,
>  the NIC name changes. This is really not a way to go, as with every ESXi
>  update the HW emulation level may change. I would like to have my VMware
>  installation living over years with no manual interaction necessary

Just for my education - when we're talking about name persistence, there
needs to be *something* that is permanent, otherwise there won't be a way
to tie a configuration to any piece of hardware. And if devices keep changing
all the time, then we're kinda out of luck if we need to tell them apart.

So, will vmware leave at least the MAC address intact? Or are we really
just talking about a configuration like "I really don't care how the NIC
identifies itself - I just want to make it come up with DHCP"?

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

From S.M.Flood at ucs.cam.ac.uk  Mon Mar 24 08:52:51 2014
From: S.M.Flood at ucs.cam.ac.uk (Simon Flood)
Date: Mon, 24 Mar 2014 14:52:51 +0000
Subject: [sles-beta] SLES12 network interface names
In-Reply-To: <53300EF8.5030108@netlab1.net>
References: <40637DBB36AF3941B243A286A432CA0B0EFA83C2@HXMB12.pnet.ch>	<5330121B020000A8000A7C6B@nat28.tlf.novell.com>
	<53300EF8.5030108@netlab1.net>
Message-ID: <533046C3.7000304@ucs.cam.ac.uk>

On 24/03/2014 10:54, Joe Doupnik wrote:

> At this point I think the networking material needs a careful review.

Another vote for this just based on a very simple situation I've just 
hit with a freshly installed Beta 3 VM:

linux:~ # ifconfig
eno167777 Link encap:Ethernet  HWaddr 00:0C:29:4C:51:57

Okay so my interface name is eno167777 ...

linux:~ # ifconfig eno167777
eno167777: error fetching interface information: Device not found

Hmm. Since I'm aware of such issues from this list (which means 
potential customers may not be) I check /etc/sysconfig/network/ where I 
see the interface name is not eno167777 but eno16777728

linux:~ # ls /etc/sysconfig/network/
config  if-down.d  ifcfg-eno16777728  ifcfg.template  scripts
dhcp    if-up.d    ifcfg-lo           providers
linux:~ # ifconfig eno16777728
eno167777 Link encap:Ethernet  HWaddr 00:0C:29:4C:51:57

So not only is eth# something simple and standard but it's also a lot 
shorter!

Oh and to make things even more confusing I see in dmesg that 
systemd-udevd (un)helpfully "renamed network interface eth0 to 
eno16777728" ...
-- 
Simon Flood
Novell/SUSE/NetIQ Knowledge Partner

From kukuk at suse.de  Mon Mar 24 08:57:14 2014
From: kukuk at suse.de (Thorsten Kukuk)
Date: Mon, 24 Mar 2014 15:57:14 +0100
Subject: [sles-beta] SLES12 network interface names
In-Reply-To: <533046C3.7000304@ucs.cam.ac.uk>
References: <40637DBB36AF3941B243A286A432CA0B0EFA83C2@HXMB12.pnet.ch>
	<5330121B020000A8000A7C6B@nat28.tlf.novell.com>
	<53300EF8.5030108@netlab1.net> <533046C3.7000304@ucs.cam.ac.uk>
Message-ID: <20140324145713.GA8927@suse.de>

On Mon, Mar 24, Simon Flood wrote:

> On 24/03/2014 10:54, Joe Doupnik wrote:
>
>> At this point I think the networking material needs a careful review.
>
> Another vote for this just based on a very simple situation I've just hit 
> with a freshly installed Beta 3 VM:
>
> linux:~ # ifconfig
> eno167777 Link encap:Ethernet  HWaddr 00:0C:29:4C:51:57
>
> Okay so my interface name is eno167777 ...

And because of such problems ifconfig was declared obsolete
decades ago and we have "ip link".

  Thorsten

-- 
Thorsten Kukuk, Senior Architect SLES & Common Code Base
SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg)

From urs.frey at post.ch  Mon Mar 24 08:57:34 2014
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Mon, 24 Mar 2014 14:57:34 +0000
Subject: [sles-beta] SLES12 network interface names
In-Reply-To: <201403241536.50121.okir@suse.de>
References: <40637DBB36AF3941B243A286A432CA0B0EFA83C2@HXMB12.pnet.ch>
	<201403241536.50121.okir@suse.de>
Message-ID: <40637DBB36AF3941B243A286A432CA0B0EFA84E5@HXMB12.pnet.ch>

Hi Olaf

>So, will vmware leave at least the MAC address intact?
Yes unless the type of driver changes in the VM client config, e.g.from Intel to vmxnet3, the MAC keeps being the same. But this is a different story.

See, my concern is, that I usually have to install a server remotely without having seen the HW before.
The only thing I have, is the MAC I can get either by API from the HP Proliant ILO remote console, or by API from the VMware Vspere client configuration.

In both cases I then need to "translate" the MAC of the first interface in the list to some name to generate my autoinst.xml
In my case the first interface in the list is cabled and has an open Firewall as setup interface for network setup.

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 Olaf Kirch
Gesendet: Monday, March 24, 2014 3:37 PM
An: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] SLES12 network interface names


Hi Urs,

On Monday 24 March 2014 10:38:57 urs.frey at post.ch wrote:
> Hi
> 
> I had a look at the wiki you provided.
> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfac
> eNames/
> 
> My concern is, that I have to know the proper network interface name before
>  I create the autoyast autoinst.xml profile. This could be accomplished
>  perfectly when having the eth names.
> 
> Now with the new naming rules I run into problems as I do not know the pci
>  bus number before powering the server. I sometimes do not even know the
>  kind of network interface HW built in in my ProLiant servers. Sometimes
>  Broadcom, sometimes, Intel sometimes Emulex NIC, who knows.
> 
> Even when having installed on VMWare and changing the HW emulation level,
>  the NIC name changes. This is really not a way to go, as with every ESXi
>  update the HW emulation level may change. I would like to have my VMware
>  installation living over years with no manual interaction necessary

Just for my education - when we're talking about name persistence, there
needs to be *something* that is permanent, otherwise there won't be a way
to tie a configuration to any piece of hardware. And if devices keep changing
all the time, then we're kinda out of luck if we need to tell them apart.

So, will vmware leave at least the MAC address intact? Or are we really
just talking about a configuration like "I really don't care how the NIC
identifies itself - I just want to make it come up with DHCP"?

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

From jrd at netlab1.net  Mon Mar 24 08:58:46 2014
From: jrd at netlab1.net (Joe Doupnik)
Date: Mon, 24 Mar 2014 14:58:46 +0000
Subject: [sles-beta] SLES12 network interface names
In-Reply-To: <201403241536.50121.okir@suse.de>
References: <40637DBB36AF3941B243A286A432CA0B0EFA83C2@HXMB12.pnet.ch>
	<201403241536.50121.okir@suse.de>
Message-ID: <53304826.90206@netlab1.net>

     Not speaking for Urs, but from my similar position what's needed 
are two things:
     1. Adapter names eth<N> where <N> is 0, 1, etc. This is what many 
of us employ with scripts and related material. It makes sense. udev 
rules provide it. We know how to handle that with VMware movements.
     2. Visibly associate the name with the MAC address so that we 
humans can verify things. Traditionally that is in ifcfg-eth<N> style 
and udev rules files.

     We have a people/manager problem and a scripting problem at work 
here. There is also the utility aspect, such as running wireshark this 
morning, where interface names are to be selected.
     The present ens<digits> abstraction relates to nothing obvious and 
offers no advantage over the previous ifconfig method.
     We are thinking servers and other important gear here, not just 
DHCP enabled laptops where "it just works" is sufficient.
     There is already more than enough indirection and layer upon 
obscure layer of references in the new material. A return to directness 
would be most welcomed.
     Thanks,
     Joe D.

On 24/03/2014 14:36, Olaf Kirch wrote:
> Hi Urs,
>
> On Monday 24 March 2014 10:38:57 urs.frey at post.ch wrote:
>> Hi
>>
>> I had a look at the wiki you provided.
>> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfac
>> eNames/
>>
>> My concern is, that I have to know the proper network interface name before
>>   I create the autoyast autoinst.xml profile. This could be accomplished
>>   perfectly when having the eth names.
>>
>> Now with the new naming rules I run into problems as I do not know the pci
>>   bus number before powering the server. I sometimes do not even know the
>>   kind of network interface HW built in in my ProLiant servers. Sometimes
>>   Broadcom, sometimes, Intel sometimes Emulex NIC, who knows.
>>
>> Even when having installed on VMWare and changing the HW emulation level,
>>   the NIC name changes. This is really not a way to go, as with every ESXi
>>   update the HW emulation level may change. I would like to have my VMware
>>   installation living over years with no manual interaction necessary
> Just for my education - when we're talking about name persistence, there
> needs to be *something* that is permanent, otherwise there won't be a way
> to tie a configuration to any piece of hardware. And if devices keep changing
> all the time, then we're kinda out of luck if we need to tell them apart.
>
> So, will vmware leave at least the MAC address intact? Or are we really
> just talking about a configuration like "I really don't care how the NIC
> identifies itself - I just want to make it come up with DHCP"?
>
> Regards
> Olaf


From okir at suse.de  Mon Mar 24 09:04:22 2014
From: okir at suse.de (Olaf Kirch)
Date: Mon, 24 Mar 2014 16:04:22 +0100
Subject: [sles-beta] SLES12 network interface names
In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0EFA84E5@HXMB12.pnet.ch>
References: <40637DBB36AF3941B243A286A432CA0B0EFA83C2@HXMB12.pnet.ch>
	<201403241536.50121.okir@suse.de>
	<40637DBB36AF3941B243A286A432CA0B0EFA84E5@HXMB12.pnet.ch>
Message-ID: <201403241604.22441.okir@suse.de>

On Monday 24 March 2014 15:57:34 urs.frey at post.ch wrote:
> Hi Olaf
> 
> >So, will vmware leave at least the MAC address intact?
> 
> Yes unless the type of driver changes in the VM client config, e.g.from
>  Intel to vmxnet3, the MAC keeps being the same. But this is a different
>  story.
> 
> See, my concern is, that I usually have to install a server remotely
>  without having seen the HW before. The only thing I have, is the MAC I can
>  get either by API from the HP Proliant ILO remote console, or by API from
>  the VMware Vspere client configuration.
> 
> In both cases I then need to "translate" the MAC of the first interface in
>  the list to some name to generate my autoinst.xml In my case the first
>  interface in the list is cabled and has an open Firewall as setup
>  interface for network setup.

Okay, this makes sense, and I think this should not be too hard to address.
Let's see what we can come up with.

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

From fcrozat at suse.com  Mon Mar 24 09:06:58 2014
From: fcrozat at suse.com (Frederic Crozat)
Date: Mon, 24 Mar 2014 16:06:58 +0100
Subject: [sles-beta] Boot menu text
In-Reply-To: <533043DA.2000409@ucs.cam.ac.uk>
References: <533043DA.2000409@ucs.cam.ac.uk>
Message-ID: <1395673618.6754.93.camel@par-r81vxc7.par.novell.com>

Le lundi 24 mars 2014 ? 14:40 +0000, Simon Flood a ?crit :
> Environment: Text-mode install of SLES 12 Beta 3 x86_64 in virtual 
> machine under VMware Player 6.0.1 on Windows 7 Pro SP1
> 
> When booting the VM it's impossible to know what the various boot menu 
> choices are as the positioning and font size mean the text for each 
> choice is truncated.
> 
> I can only find out what the full text should say by use of "grep 
> menuentry /boot/grub2/grub.cfg" !
> 
> See two screen shots attached but basically first screen offers [with 
> intended text in brackets]:
> 
> SUSE Linux Enterprise Server 1(bit of 2) [SUSE Linux Enterprise Server 12]
> Advanced options for SUSE Lin(bit of u) [Advanced options for SUSE Linux 
> Enterprise Server 12]
> 
> Choosing Advanced ... then gives another menu offering:
> 
> SUSE Linux Enterprise Server 1(bit of 2) [SUSE Linux Enterprise Server 
> 12, with Linux 3.12.14-1-default]
> SUSE Linux Enterprise Server 1(bit of 2) [SUSE Linux Enterprise Server 
> 12, with Linux 3.12.14-1-default (recovery mode]
> 
> I'm guessing you probably don't want to abbreviate "SUSE Linux 
> Enterprise Server" to SLES so perhaps there's an option of some sub-text 
> or repositioning the left-hand "SUSE Linux Enterprise" to allow choices 
> more space? Thinking about it, does "SUSE Linux Enterprise Server" need 
> to keep being repeated for each menu choice?

Thanks, we are already looking at how to improve the boot menu
(bnc#867314).

-- 
Frederic Crozat <fcrozat at suse.com>
SUSE


From urs.frey at post.ch  Mon Mar 24 09:07:12 2014
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Mon, 24 Mar 2014 15:07:12 +0000
Subject: [sles-beta] SLES12 network interface names
In-Reply-To: <201403241604.22441.okir@suse.de>
References: <40637DBB36AF3941B243A286A432CA0B0EFA83C2@HXMB12.pnet.ch>
	<201403241536.50121.okir@suse.de>
	<40637DBB36AF3941B243A286A432CA0B0EFA84E5@HXMB12.pnet.ch>
	<201403241604.22441.okir@suse.de>
Message-ID: <40637DBB36AF3941B243A286A432CA0B0EFA8517@HXMB12.pnet.ch>

Hi Olaf

>Okay, this makes sense, and I think this should not be too hard to address.
>Let's see what we can come up with.

Thank you very much.
Meanwhile I am trying to get around by setting net.ifnames=0 as Kernel Parameter.

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: Olaf Kirch [mailto:okir at suse.de] 
Gesendet: Monday, March 24, 2014 4:04 PM
An: Frey Urs, IT222
Cc: sles-beta at lists.suse.com
Betreff: Re: AW: [sles-beta] SLES12 network interface names

On Monday 24 March 2014 15:57:34 urs.frey at post.ch wrote:
> Hi Olaf
> 
> >So, will vmware leave at least the MAC address intact?
> 
> Yes unless the type of driver changes in the VM client config, e.g.from
>  Intel to vmxnet3, the MAC keeps being the same. But this is a different
>  story.
> 
> See, my concern is, that I usually have to install a server remotely
>  without having seen the HW before. The only thing I have, is the MAC I can
>  get either by API from the HP Proliant ILO remote console, or by API from
>  the VMware Vspere client configuration.
> 
> In both cases I then need to "translate" the MAC of the first interface in
>  the list to some name to generate my autoinst.xml In my case the first
>  interface in the list is cabled and has an open Firewall as setup
>  interface for network setup.

Okay, this makes sense, and I think this should not be too hard to address.
Let's see what we can come up with.

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

From S.M.Flood at ucs.cam.ac.uk  Mon Mar 24 09:10:33 2014
From: S.M.Flood at ucs.cam.ac.uk (Simon Flood)
Date: Mon, 24 Mar 2014 15:10:33 +0000
Subject: [sles-beta] SLES12 network interface names
In-Reply-To: <20140324145713.GA8927@suse.de>
References: <40637DBB36AF3941B243A286A432CA0B0EFA83C2@HXMB12.pnet.ch>	<5330121B020000A8000A7C6B@nat28.tlf.novell.com>	<53300EF8.5030108@netlab1.net>
	<533046C3.7000304@ucs.cam.ac.uk> <20140324145713.GA8927@suse.de>
Message-ID: <53304AE9.3010504@ucs.cam.ac.uk>

On 24/03/2014 14:57, Thorsten Kukuk wrote:

> And because of such problems ifconfig was declared obsolete
> decades ago and we have "ip link".

That may be but "ifconfig" tells me what I'm looking for (IP address 
details) whereas "ip link" doesn't. Whilst "ip addr" is better it's 
still not as useful.

If I just wanted interface names I could instead do "ls /sys/class/net" 
but "ifconfig" is shorter.

At the moment I can see having to write a script that iterates the 
enoXXXXXXXX interfaces to come up with rules that renames them back to 
something more sensible (ethX). Whilst stupid it at least fixes 
post-install but I still have a big question about auto-installs.
-- 
Simon Flood
Novell/SUSE/NetIQ Knowledge Partner

From ddavis at suse.com  Mon Mar 24 11:16:13 2014
From: ddavis at suse.com (Darren Davis)
Date: Mon, 24 Mar 2014 11:16:13 -0600
Subject: [sles-beta] Upgrade from 11-3 to 12-0 -- s390x iso's
In-Reply-To: <46AC8C81C10B8C48820201DF2AE1D76D5377D356@hqmbx6.eur.ad.sag>
References: <46AC8C81C10B8C48820201DF2AE1D76D5377D356@hqmbx6.eur.ad.sag>
Message-ID: <533013FD0200007E00022E76@prv-mh.provo.novell.com>

Hello Dick,

As a note, the partners.novell.com server is maintained by the SUSE Partner Engineering
team essentially by hand.  I has no "official" connection with the beta other than a guy
puts the beta images on that server more for partner convenience for those that need an
ftp server.  Really, the official place is the Beta page.

Later,

Darren


>>> On 03/24/2014 at 06:45 AM, "Waite, Dick" <Dick.Waite at softwareag.com> wrote: 
> Grand Afternoon,
> 
> Just had a look, I have ppc, x86_64, MINI-ISO-ppc and MINI-ISO-x86_64  in 
> the SLE12-Server directory and in SLE-12-SDK just the ppc and x86_64. No ia64 
> or s390s. I'm looking in Partners.novell.com, *but* if I look at my Beta page 
> I do see there are s390x iso's there. So they just have not found there way 
> to partners yet, which is strange as the x86_64's were there very early on 
> Friday...
> SAG has a filter on download's and the iso's are to big which is why I use 
> Partners... I'll give them a little more time to get to where I can 
> download...
> 
> Sorry to create a wave, I should have looked on my Beta page before making 
> noise.
> 
> __R
> ________________________________________
> From: sles-beta-bounces at lists.suse.com [sles-beta-bounces at lists.suse.com] on 
> behalf of Stefan Behlert [behlert at suse.com]
> Sent: 24 March 2014 13:01
> To: sles-beta at lists.suse.com
> Subject: [Spam]: Re: [sles-beta] Upgrade from 11-3 to 12-0 -- s390x iso's
> 
> Moin,
> 
> On Mar 23, 14 10:54:21 +0000, Waite, Dick wrote:
> [...]
>>
>> As I see no s390x iso's on your sites this is still on hold until beta4?
> 
> s390x isos should be visible. Be so kind to check again, maybe the mirror
> local to you had not finished his update of the images for Beta3.
> Unfortunately that is out of our control, and we are not able to check if
> all mirrors have all images yet when we annoucne them :(
> 
> 
>         Stefan
>>
>> __R
> 
> --
> Stefan Behlert, SUSE LINUX
> Project Manager Enterprise Server
> 
> Maxfeldstr. 5, D-90409 Nuernberg, Germany
> Phone +49-911-74053-173
> SUSE LINUX Products GmbH, Nuernberg; GF: Jeff Hawn, Jennifer Guild, Felix 
> Imendoerffer, HRB 16746 (AG Nuernberg)
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta
> 
> 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
> 
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta



From Dick.Waite at softwareag.com  Mon Mar 24 11:23:58 2014
From: Dick.Waite at softwareag.com (Waite, Dick)
Date: Mon, 24 Mar 2014 17:23:58 +0000
Subject: [sles-beta] Upgrade from 11-3 to 12-0 -- s390x iso's
In-Reply-To: <533013FD0200007E00022E76@prv-mh.provo.novell.com>
References: <46AC8C81C10B8C48820201DF2AE1D76D5377D356@hqmbx6.eur.ad.sag>,
	<533013FD0200007E00022E76@prv-mh.provo.novell.com>
Message-ID: <20140324172403.5898388.74503.1324@softwareag.com>

Many Thanks Darren. I'll have words with our SUSE partner's chap and see what can be done. Since SLE 9 the Beta's have been available thare and x86_64 is there, maybe it's just letting the chap know we would like s390x there too. In the office tomorrow with better access etc
__R


Sent from my BlackBerry 10 smartphone.
  Original Message
From: Darren Davis
Sent: Monday, 24 March 2014 18:16
To: sles-beta at lists.suse.com; Waite, Dick; Stefan Behlert
Subject: Re: [sles-beta] Upgrade from 11-3 to 12-0 -- s390x iso's


Hello Dick,

As a note, the partners.novell.com server is maintained by the SUSE Partner Engineering
team essentially by hand.  I has no "official" connection with the beta other than a guy
puts the beta images on that server more for partner convenience for those that need an
ftp server.  Really, the official place is the Beta page.

Later,

Darren


>>> On 03/24/2014 at 06:45 AM, "Waite, Dick" <Dick.Waite at softwareag.com> wrote:
> Grand Afternoon,
>
> Just had a look, I have ppc, x86_64, MINI-ISO-ppc and MINI-ISO-x86_64  in
> the SLE12-Server directory and in SLE-12-SDK just the ppc and x86_64. No ia64
> or s390s. I'm looking in Partners.novell.com, *but* if I look at my Beta page
> I do see there are s390x iso's there. So they just have not found there way
> to partners yet, which is strange as the x86_64's were there very early on
> Friday...
> SAG has a filter on download's and the iso's are to big which is why I use
> Partners... I'll give them a little more time to get to where I can
> download...
>
> Sorry to create a wave, I should have looked on my Beta page before making
> noise.
>
> __R
> ________________________________________
> From: sles-beta-bounces at lists.suse.com [sles-beta-bounces at lists.suse.com] on
> behalf of Stefan Behlert [behlert at suse.com]
> Sent: 24 March 2014 13:01
> To: sles-beta at lists.suse.com
> Subject: [Spam]: Re: [sles-beta] Upgrade from 11-3 to 12-0 -- s390x iso's
>
> Moin,
>
> On Mar 23, 14 10:54:21 +0000, Waite, Dick wrote:
> [...]
>>
>> As I see no s390x iso's on your sites this is still on hold until beta4?
>
> s390x isos should be visible. Be so kind to check again, maybe the mirror
> local to you had not finished his update of the images for Beta3.
> Unfortunately that is out of our control, and we are not able to check if
> all mirrors have all images yet when we annoucne them :(
>
>
>         Stefan
>>
>> __R
>
> --
> Stefan Behlert, SUSE LINUX
> Project Manager Enterprise Server
>
> Maxfeldstr. 5, D-90409 Nuernberg, Germany
> Phone +49-911-74053-173
> SUSE LINUX Products GmbH, Nuernberg; GF: Jeff Hawn, Jennifer Guild, Felix
> Imendoerffer, HRB 16746 (AG Nuernberg)
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta
>
> 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
>
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta



From jrd at netlab1.net  Mon Mar 24 11:50:16 2014
From: jrd at netlab1.net (Joe Doupnik)
Date: Mon, 24 Mar 2014 17:50:16 +0000
Subject: [sles-beta] Comments on wicked in today's presentations
Message-ID: <53307058.6000209@netlab1.net>

     If I may, this is a better place to make some comments on the 
interesting presentation about wicked today. I will be critical, but in 
a sympathetic way.
     To start with the bottom line as I see things at this time. This is 
an experiment which ought to appear in production a year from now. The 
attempt seems to be to invent a robot which somehow magically makes all 
that "complicated" networking gear disappear behind a on/off switch plus 
a green/red light. That is an interesting goal, speaking 
sympathetically, but first one ought to sort things into simple 
arrangements so that people can easily cope with it. Use of the term 
"complicated" implies, to me, incomplete understanding and that is not a 
proper state for production tools. I am a scientist and I recognise 
partly formed ideas when they appear. Wicked does seem to be in that 
category presently, too early to judge for possible merits but appealing 
in its promise.
     Our discussions on the list about lan device naming and similar 
reflect the realities we have in the field today, being very clear about 
This device does That thing in a form compatible with other parts of the 
system, as well as our need to see that information at it is preserved 
in configuration files. In other words, people are smarter than the 
robot and should win more than an average number of battles with such 
things. To couple the two requires much thinking about what displays and 
what controls each side should have.
     To be fair, I am very cautious about critiquing ambitious projects 
by SUSE because in the end they often turn out to be very clever work. 
An example is snapper, another is zypper, and not least YaST itself. 
Wicked may be, in time. Between that happy end state and now reside our 
servers and our managers, and they are becoming subjects of an 
experiment in progress. OpenSUSE is a normal proving ground for such 
efforts.
     Consequently, my feeling is we need to retain the clarity and 
simplicity of what we have with ifconfig and relatives, let wicked grow 
to maturity and prove its value to our situations, and then create a 
smooth bridge between these worlds. What it is, what it ought to do, how 
one transitions from A to B, and where people fit into the scheme are 
still not well defined, not to me as an end user.

     Additional comments on XML files and similar. I am in the camp 
which says that is for computers to read and write, not for people. The 
current situation is one of creating name-value pairs, so far as I can 
surmise, not complicated hierarchical structures. Classical name-value 
files are for people as much as computers. They work well with people, 
and computers think they are trivial to parse. Thus, why complicate when 
it isn't necessary or desirable to do so.

     Thanks,
     Joe D.

From jrd at netlab1.net  Mon Mar 24 14:21:39 2014
From: jrd at netlab1.net (Joe Doupnik)
Date: Mon, 24 Mar 2014 20:21:39 +0000
Subject: [sles-beta] Comments on wicked in today's presentations
In-Reply-To: <53307058.6000209@netlab1.net>
References: <53307058.6000209@netlab1.net>
Message-ID: <533093D3.3080500@netlab1.net>

     Adding a few more words to my message.
     As I mull what was shown to us today the more it seems that wicked 
should be a nearly independent product which could be added to SLES upon 
need. Many servers need simple steady connections, static, some bonded 
many not. There are some sites which have fluid environments where hot 
plugging and whatnot occur all the time, heaven help them, and elaborate 
network management software would be a great blessing. The latter need 
such a product, the former don't and can be spared the complexity.
      Further on what we know so far. Just what are those problems which 
need solving (my place may not face them), and how would wicked go about 
solving them? I dunno. What does wicked do today in Beta 3? I really 
don't know, but its presence might contribute to our current problems. 
Do I need to take a training course to keep my Ethernet adapter and 
IPtables script working? I hope not, travel costs being what they are 
today, but the signs are not favourable. Should I pay attention to the 
alphabet soup being offered today? No, thanks anyway, I know protocols 
and prefer plain tomato soup (aka IP v4, static addresses, eth0 style). 
The soup offering is really a layer cake plus side dishes plus coffee 
all on one trolley.
     I wish the development team much luck in building the wicked tool 
set. I would love to help but I lack the environment in which do test 
such things. In a year's time the problem set ought to become well 
defined, the results should be understandable by mere mortals, the 
benefits be clear and appealing to those with the needs, and hopefully 
SUSE would make a bundle of money from the effort.
     Joe D.


On 24/03/2014 17:50, Joe Doupnik wrote:
> If I may, this is a better place to make some comments on the 
> interesting presentation about wicked today. I will be critical, but 
> in a sympathetic way.
>     To start with the bottom line as I see things at this time. This 
> is an experiment which ought to appear in production a year from now. 
> The attempt seems to be to invent a robot which somehow magically 
> makes all that "complicated" networking gear disappear behind a on/off 
> switch plus a green/red light. That is an interesting goal, speaking 
> sympathetically, but first one ought to sort things into simple 
> arrangements so that people can easily cope with it. Use of the term 
> "complicated" implies, to me, incomplete understanding and that is not 
> a proper state for production tools. I am a scientist and I recognise 
> partly formed ideas when they appear. Wicked does seem to be in that 
> category presently, too early to judge for possible merits but 
> appealing in its promise.
>     Our discussions on the list about lan device naming and similar 
> reflect the realities we have in the field today, being very clear 
> about This device does That thing in a form compatible with other 
> parts of the system, as well as our need to see that information at it 
> is preserved in configuration files. In other words, people are 
> smarter than the robot and should win more than an average number of 
> battles with such things. To couple the two requires much thinking 
> about what displays and what controls each side should have.
>     To be fair, I am very cautious about critiquing ambitious projects 
> by SUSE because in the end they often turn out to be very clever work. 
> An example is snapper, another is zypper, and not least YaST itself. 
> Wicked may be, in time. Between that happy end state and now reside 
> our servers and our managers, and they are becoming subjects of an 
> experiment in progress. OpenSUSE is a normal proving ground for such 
> efforts.
>     Consequently, my feeling is we need to retain the clarity and 
> simplicity of what we have with ifconfig and relatives, let wicked 
> grow to maturity and prove its value to our situations, and then 
> create a smooth bridge between these worlds. What it is, what it ought 
> to do, how one transitions from A to B, and where people fit into the 
> scheme are still not well defined, not to me as an end user.
>
>     Additional comments on XML files and similar. I am in the camp 
> which says that is for computers to read and write, not for people. 
> The current situation is one of creating name-value pairs, so far as I 
> can surmise, not complicated hierarchical structures. Classical 
> name-value files are for people as much as computers. They work well 
> with people, and computers think they are trivial to parse. Thus, why 
> complicate when it isn't necessary or desirable to do so.
>
>     Thanks,
>     Joe D.
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta


From kukuk at suse.de  Mon Mar 24 15:36:05 2014
From: kukuk at suse.de (Thorsten Kukuk)
Date: Mon, 24 Mar 2014 22:36:05 +0100
Subject: [sles-beta] Comments on wicked in today's presentations
In-Reply-To: <533093D3.3080500@netlab1.net>
References: <53307058.6000209@netlab1.net> <533093D3.3080500@netlab1.net>
Message-ID: <20140324213605.GA8717@suse.de>

On Mon, Mar 24, Joe Doupnik wrote:

>      Further on what we know so far. Just what are those problems which 
> need solving (my place may not face them), and how would wicked go about 
> solving them? I dunno.

Other question: which problems do you have caused by wicked and where
do you come in contact with it?
Up to now, I haven't seen any report here which where caused by
wicked.

> What does wicked do today in Beta 3?

Making sure that your network interfaces will be setup and configured
with an IP address.
Which was done by a lot of shell scripts in SLES11 before.

> I really don't  know, but its presence might contribute to our current
> problems.

Which problems?
I only know about the interface renaming discussions, but this has
nothing to do with wicked.

> Do I need to take a training course to keep my Ethernet adapter and
> IPtables script working? 

Do you had any issues in this regard with Beta1 - Beta3?
Your interfaces are still the same as with SLES11: YaST2 and
the config files in /etc/sysconfig/network.

I have the feeling you are mixing up several things which
are not connected.

-- 
Thorsten Kukuk, Senior Architect SLES & Common Code Base
SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg)

From jrd at netlab1.net  Tue Mar 25 02:40:38 2014
From: jrd at netlab1.net (Joe Doupnik)
Date: Tue, 25 Mar 2014 08:40:38 +0000
Subject: [sles-beta] Comments on wicked in today's presentations
In-Reply-To: <20140324213605.GA8717@suse.de>
References: <53307058.6000209@netlab1.net> <533093D3.3080500@netlab1.net>
	<20140324213605.GA8717@suse.de>
Message-ID: <53314106.1050002@netlab1.net>

     The difficulties to which I refer below are two: the discussed 
interface naming and associated ifcfg-X contents, and then yesterday the 
peculiar problem of wireshark seeing no packets. The latter suggests 
wicked derived apparatus is not yet ready for packet captures.
     As for shell scripts, they at least work and are well proven in the 
field. Wicked exchanges them for its own scripts. So I think this is not 
a good argument on either side of the problem.
     What counts is the apparatus works as intended, is understood by 
owners and not least how it interfaces with human managers.
     Thanks,
     Joe D.

On 24/03/2014 21:36, Thorsten Kukuk wrote:
> On Mon, Mar 24, Joe Doupnik wrote:
>
>>       Further on what we know so far. Just what are those problems which
>> need solving (my place may not face them), and how would wicked go about
>> solving them? I dunno.
> Other question: which problems do you have caused by wicked and where
> do you come in contact with it?
> Up to now, I haven't seen any report here which where caused by
> wicked.
>
>> What does wicked do today in Beta 3?
> Making sure that your network interfaces will be setup and configured
> with an IP address.
> Which was done by a lot of shell scripts in SLES11 before.
>
>> I really don't  know, but its presence might contribute to our current
>> problems.
> Which problems?
> I only know about the interface renaming discussions, but this has
> nothing to do with wicked.
>
>> Do I need to take a training course to keep my Ethernet adapter and
>> IPtables script working?
> Do you had any issues in this regard with Beta1 - Beta3?
> Your interfaces are still the same as with SLES11: YaST2 and
> the config files in /etc/sysconfig/network.
>
> I have the feeling you are mixing up several things which
> are not connected.
>


From Dick.Waite at softwareag.com  Tue Mar 25 02:54:21 2014
From: Dick.Waite at softwareag.com (Waite, Dick)
Date: Tue, 25 Mar 2014 08:54:21 +0000
Subject: [sles-beta] Upgrade fromSLE 11-3 to 12-0 on x86_64
In-Reply-To: <46AC8C81C10B8C48820201DF2AE1D76D5377CD49@hqmbx6.eur.ad.sag>
References: <46AC8C81C10B8C48820201DF2AE1D76D5377CD49@hqmbx6.eur.ad.sag>
Message-ID: <46AC8C81C10B8C48820201DF2AE1D76D5377DB19@hqmbx6.eur.ad.sag>

Grand New Day,
          I have created a SR on my issue with upgrade. Service Request: 10884981671
          I was not sure upgrade was supported in Beta3 but did get confirmation at the Beta Con_Call last night it is working. I tried again this morning and get the same message, "The installed product is not compatible with the product on the installation media. If you try to update using the current installation media, the system may not start or some applications may not run properly."
            The SLE 11-3 install was done with the GA version, all defaults taken and one network connection. I tried a check load to make sure it ran Okay and then shutdown. I then switched the iso to 12-0 beta3 and tried to upgrade. Looks Okay until it checks what it has and then gives the above message.
          The final target of this will be x86_64 and zlinux environments running SLE 11-3 and KDE to be upgraded to SLE 12-0 running GNOME, unless KDE gets a reprieve?Give us a little more time to do a very major switch of a lot of customers or I see many good people keeping with SLE 11-3 for as long as possible, which is not good for man nor beast.
__R
___________________________________________
Dick Waite
Senior R&D Consultant
Phone:  +49 6151 92-1505
Mobile: +49 171 8393 769
Software AG
Uhlandstr. 12 | 64297 Darmstadt | Germany
www.softwareag.com<http://www.softwareag.com/>
___________________________________________


From: Waite, Dick
Sent: Sunday, March 23, 2014 2:07 PM
To: sles-beta at lists.suse.com
Cc: Uwe Drechsel
Subject: RE: [sles-beta] Upgrade fromSLE 11-3 to 12-0 on x86_64

Grand Sunday Afternoon,
The words I have seen too often, "The installed product is not compatible with the product on the installation media. If you try to update using the current installation media, the system may not start or some applications may not run properly."

This was a new install of SLE 11-3 on new disks using only defaults. I did load the system a couple of times after the install to check it ran and looked Okay. I then switched the environment to point at SLE 12-0 Beta3 iso's. So it looks like from what I see a SLE 11-3 with GNOME can not be upgraded to 12-0 beta3 with Gnome.

The release notes 12.0.8 which say they can also be found at "http://www.suse.com/documentation/sles12", which gives a 404, and has a small font in green on the black background which is not very friendly to the eyes, section 4.4 Upgrade-related Notes, in a grand white font, 4.4.1 it does say: "SLES 11 GA -> SLES 11 SP1 -> SLES SP2 -> SLES SP3 -> SLES 12 GA". True this is only Beta3 but I did understand Upgrade with beta3 is supported.

Time to call it a day I think. Looking forward to tomorrow evenings meeting, could be quite lively and I'm sure productive. We all want v12 to be a grand release, much better then, "the other red one v7".  ;o)

__R

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/20140325/df810ad8/attachment.htm>

From kukuk at suse.de  Tue Mar 25 03:27:12 2014
From: kukuk at suse.de (Thorsten Kukuk)
Date: Tue, 25 Mar 2014 10:27:12 +0100
Subject: [sles-beta] Comments on wicked in today's presentations
In-Reply-To: <53314106.1050002@netlab1.net>
References: <53307058.6000209@netlab1.net> <533093D3.3080500@netlab1.net>
	<20140324213605.GA8717@suse.de> <53314106.1050002@netlab1.net>
Message-ID: <20140325092712.GA23362@suse.de>


Hi,

On Tue, Mar 25, Joe Doupnik wrote:

>     The difficulties to which I refer below are two: the discussed 
> interface naming and associated ifcfg-X contents,

Ok, the interface naming is a real problem, but it has nothing to do
with wicked. That's systemd/udev/biosdevname and whatever else thinks
it has to play around with this names. wicked does not care about how
the interface is named.

> and then yesterday the 
> peculiar problem of wireshark seeing no packets. The latter suggests wicked 
> derived apparatus is not yet ready for packet captures.

Sorry, but packet captures have nothing to do with wicked, too, but
with the kernel driver.
wireshark is working fine for me on all of my SLES12 test systems.

About xinetd and vsftpd: this looks like a xinetd problem, vsftpd does
work fine standalone. Not wicked, too.

>     As for shell scripts, they at least work and are well proven in the 
> field.

Until you want to bring up a bridge in a running system for
virtualisation guests, etc...

> Wicked exchanges them for its own scripts. So I think this is not a 
> good argument on either side of the problem.
>     What counts is the apparatus works as intended, is understood by owners 
> and not least how it interfaces with human managers.

And from your problems I would say: wicked just works.
What I already assumed: you don't have a problem with wicked,
but with bugs in other code completly unrelated to wicked.
That's at bad, too, but dropping wicked will not solve any of
your above problems. It's like with a car: if your tires are
flat, exchanging the motor engine will not fix it.

Instead we need to look at every single issue, debug and fix it.

  Thorsten

-- 
Thorsten Kukuk, Senior Architect SLES & Common Code Base
SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg)

From jrd at netlab1.net  Tue Mar 25 03:50:14 2014
From: jrd at netlab1.net (Joe Doupnik)
Date: Tue, 25 Mar 2014 09:50:14 +0000
Subject: [sles-beta] Comments on wicked in today's presentations
In-Reply-To: <20140325092712.GA23362@suse.de>
References: <53307058.6000209@netlab1.net>
	<533093D3.3080500@netlab1.net>	<20140324213605.GA8717@suse.de>
	<53314106.1050002@netlab1.net> <20140325092712.GA23362@suse.de>
Message-ID: <53315156.3050004@netlab1.net>

     Good, I think a little sorting is occurring.
     The subject yesterday was networking, where the focus was on 
wicked. My comments are on networking, and the unknown role which wicked 
may or may not play in them. I did ask just what does wicked do, a 
matter not really addressed in yesterday's presentation. I asked about 
the effects of it on systems which do not involve complicated 
networking. And similar queries. Hopefully these matters will be 
documented in due course. Further, I am pleased to see creative projects 
in this and related areas, keeping in mind that our production systems 
are not the proving ground.
     I will add that my impression of the wicked management is of 
concern, particularly the heavy emphasis on dbus traffic (yet another 
congestion/failure point). That's a technical nuance, judged from afar. 
I know, I can hear the reply, "How else can the management system learn 
about events." The kernel knows is one reply. The concern includes human 
vs machine where the machine thinks it knows better. Creating an 
understandable network management console (or equivalent) would be 
really interesting, but there is yet little evidence of that in wicked. 
I hope the team can make it happen. As stated, it might be best as a 
product in its own right.
     The problems mentioned below are real enough, but the cause of the 
wireshark part remains to be determined. More testing here might help, 
and your observation that packet captures work at your end is encouraging.
     Thanks,
     Joe D.

On 25/03/2014 09:27, Thorsten Kukuk wrote:
> Hi,
>
> On Tue, Mar 25, Joe Doupnik wrote:
>
>>      The difficulties to which I refer below are two: the discussed
>> interface naming and associated ifcfg-X contents,
> Ok, the interface naming is a real problem, but it has nothing to do
> with wicked. That's systemd/udev/biosdevname and whatever else thinks
> it has to play around with this names. wicked does not care about how
> the interface is named.
>
>> and then yesterday the
>> peculiar problem of wireshark seeing no packets. The latter suggests wicked
>> derived apparatus is not yet ready for packet captures.
> Sorry, but packet captures have nothing to do with wicked, too, but
> with the kernel driver.
> wireshark is working fine for me on all of my SLES12 test systems.
>
> About xinetd and vsftpd: this looks like a xinetd problem, vsftpd does
> work fine standalone. Not wicked, too.
>
>>      As for shell scripts, they at least work and are well proven in the
>> field.
> Until you want to bring up a bridge in a running system for
> virtualisation guests, etc...
>
>> Wicked exchanges them for its own scripts. So I think this is not a
>> good argument on either side of the problem.
>>      What counts is the apparatus works as intended, is understood by owners
>> and not least how it interfaces with human managers.
> And from your problems I would say: wicked just works.
> What I already assumed: you don't have a problem with wicked,
> but with bugs in other code completly unrelated to wicked.
> That's at bad, too, but dropping wicked will not solve any of
> your above problems. It's like with a car: if your tires are
> flat, exchanging the motor engine will not fix it.
>
> Instead we need to look at every single issue, debug and fix it.
>
>    Thorsten
>


From kukuk at suse.de  Tue Mar 25 04:29:55 2014
From: kukuk at suse.de (Thorsten Kukuk)
Date: Tue, 25 Mar 2014 11:29:55 +0100
Subject: [sles-beta] SLES12 network interface names
In-Reply-To: <53300EF8.5030108@netlab1.net>
References: <40637DBB36AF3941B243A286A432CA0B0EFA83C2@HXMB12.pnet.ch>
	<5330121B020000A8000A7C6B@nat28.tlf.novell.com>
	<53300EF8.5030108@netlab1.net>
Message-ID: <20140325102955.GA30272@suse.de>

On Mon, Mar 24, Joe Doupnik wrote:

>     Try standalone vsftpd. No data channel.

But you will get a usefull error message:
500 OOPS: priv_sock_get_int

Solution: Read /etc/vsftpd.conf, especially the security section,
and play around with the options. Enabling seccomp_sandbox=NO
should solve the problem in this case.

-- 
Thorsten Kukuk, Senior Architect SLES & Common Code Base
SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg)

From okir at suse.de  Tue Mar 25 04:42:00 2014
From: okir at suse.de (Olaf Kirch)
Date: Tue, 25 Mar 2014 11:42:00 +0100
Subject: [sles-beta] Comments on wicked in today's presentations
In-Reply-To: <53307058.6000209@netlab1.net>
References: <53307058.6000209@netlab1.net>
Message-ID: <201403251142.00861.okir@suse.de>


Hello Joe,

On Monday 24 March 2014 18:50:16 Joe Doupnik wrote:
>      If I may, this is a better place to make some comments on the
> interesting presentation about wicked today. I will be critical, but in
> a sympathetic way.
>      To start with the bottom line as I see things at this time. This is
> an experiment which ought to appear in production a year from now. The
> attempt seems to be to invent a robot which somehow magically makes all
> that "complicated" networking gear disappear behind a on/off switch plus
> a green/red light.

Well, apparently I did a very bad job at describing the intention of this
new development.

(1) We did this because the complexity of the ifup/ifdown script melange
	was beyond the breaking point. Honestly, trying to extend what we
	have has driven developers up the wall :)

	And we did extend this framework a lot - I tried to give a first
	order approximatin with my slides, but maybe that was too visual
	an attempt... but if you look past traditional IPv4 networking,
	there's a huge set of changes around DCB, FCoE support, iBFT, IPv6,
	bonding and bridging, virtualization related stuff etc, all of which
	went in over the past couple of years.

	And more is in the pipeline - I'm sure we haven't seen the last
	IPv6 tunneling technologies; there's NIC teaming support that's being
	requested, and so on. And remember, this product is going to be in
	the market for a long time. So the last thing we want to do is keep
	gluing more bits and pieces to something that showing structural
	strains already today.

(2)	This is not about dumbing down anything. It's not about making
	complicated stuff disappear - it's about making complex stuff
	available to the admin in a useful way.

	Can you, or anyone else on the list, tell me off the top of your head
	(and without going back through lots of READMEs) how to do all of
	the following:

	... disable IPv6 on a specific interface?
	... set up an interface for DHCPv4 and DHCPv6?
	... change the link speed on an Ethernet interface?
	... reconfigure a bonding device without bringing it down?
	... set up a bridge on top of a bond
	... change the firewall rules on your UMTS modem?
	... set up 802.1x authentication for your Ethernet NIC?
	... set up persistent names for your System z devices?
	... disable segmentation offloading on your Ethernet NIC?

	There are knobs and tunables for all of these things. Right now,
	they're not available to the admin (short of messing with
	rc.local scripts), or if they are, they need some non-intuitive
	syntax.

Our goal with wicked would be to offer as many of these through one
consistent configuration file format.

> That is an interesting goal, speaking
> sympathetically, but first one ought to sort things into simple
> arrangements so that people can easily cope with it.

Correct. And this is why, in SLE12, we started by replacing the old ifcfg
machinery, while still retaining the interfaces (read, the ifcfg files).
We're taking one step after the other, avoiding to change too many things
at once. As a consequence, wicked is currently not living up to the promise.
The best it can offer in GA is being as stable as its predecessor - but with
SP1, I would like us to move to the new config file format that actually
offers all the power of a unified API.

>      Our discussions on the list about lan device naming and similar
> reflect the realities we have in the field today, being very clear about
> This device does That thing in a form compatible with other parts of the
> system, as well as our need to see that information at it is preserved
> in configuration files. In other words, people are smarter than the
> robot and should win more than an average number of battles with such
> things. To couple the two requires much thinking about what displays and
> what controls each side should have.

Well, let's not confuse two things here - the naming issue has nothing,
absolutely nothing to do with the introduction of wicked. It's a separate
issue. (And I assume the wireshark problem seen recently is yet a different
topic).

One way to address it would be to reintroduce the old SLE11 code for device
renaming back to udev. So far, we're pretty reluctant to go there, beceause
it has a tendency to break once in a while because it's an inherently racy
operation, especially on machines with lots of NICs.

The other way is to try to get rid of a dependency on names as much as possible.
How many people actually did implement their own naming scheme? I think, most
everyone was happy that the system did offer naming persistence, but didn't
really care if NIC A was called eth0 or eth1, as long as that didn't change
over the life time of the system.

And I think that is the main point. Yes, I agree, en123456789 is neither
easy to remember nor easy to type, but can we agree that this is a secondary
issue (worth addressing, but maybe less pressing?)

>      Additional comments on XML files and similar. I am in the camp
> which says that is for computers to read and write, not for people. The
> current situation is one of creating name-value pairs, so far as I can
> surmise, not complicated hierarchical structures. Classical name-value
> files are for people as much as computers. They work well with people,
> and computers think they are trivial to parse. Thus, why complicate when
> it isn't necessary or desirable to do so.

Point taken. One remark on hierarchy though - that's something that will be
needed. If you think of IP addresses assigned to a NIC, you're talking
about lists, potentially. For routing, you're talking about lists as
well, and possibly even nested. All of that is currently flattened
artificially because of the very restricted syntax that the shell offers
(as in the case of IPADDR_* variables), or because of what we can parse
easily in a shell script (eg in the case of the ifcfg-routes file). But
I wouldn't go as far as establishing that as the gold standard worth
enshrining for eternity.

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

From urs.frey at post.ch  Tue Mar 25 05:22:41 2014
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Tue, 25 Mar 2014 11:22:41 +0000
Subject: [sles-beta] Comments on wicked in today's presentations
In-Reply-To: <201403251142.00861.okir@suse.de>
References: <53307058.6000209@netlab1.net> <201403251142.00861.okir@suse.de>
Message-ID: <40637DBB36AF3941B243A286A432CA0B0EFA874D@HXMB12.pnet.ch>

Hi all
Thank you Joe for this discussion, Thank you Olaf and Thorsten for your answers

My concern is the NIC device naming:

See my aim is to set up SLES 12 using autoyast.
I do have more than 1000 Linux installations here, SLES, RHEL and Debian. 
The first choice is autoyast, because of its flexibility in doing configurations after the installation.
As I mentioned already I do have to set up my servers remotely, getting only the MAC by API from v-spere or HP ProLiant remote console. 
Fixed IP address, hostname, type of server and its final function I get from our CMDB.
To create the autoyast profile I need to put in some name or alias for network device, else the entire process does not work.

I do have HP Blade servers connected FCoE, where the NIC needs to get bonded during installation. 
On top of the bond0 device I do have either VLAN tagged interfaces or a whole bunch of logical devices, depends the function webserver with specific private domains, or proxy server.
Of course I do also have a number of backup servers, where bonding is done over 8 NICs in 802.3ad LACP mode.
In all these cases, short NIC names are crucial.
And in all these cases , the possibility to have autoyast done it in an automated way is most important.

So what ever does run "under the hood" I expect autoyast can cope with.

SLES for me does mean enterprise release, because the methods and architecture released with the GA release do not change anymore over the lifetime of one mayor release. Service pack updates can be done easily using zypper dup in online mode, and the changes are sustainable for all kind of middleware installed above SLES.

So I see, the change to SystemD and the change in network engine are kind of big leap forward.

But please keep in mind the basic need: 
easy automated remote setup and operation and above all no change in method over the entire lifetime of the release.

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

From jrd at netlab1.net  Tue Mar 25 05:28:04 2014
From: jrd at netlab1.net (Joe Doupnik)
Date: Tue, 25 Mar 2014 11:28:04 +0000
Subject: [sles-beta] Comments on wicked in today's presentations
In-Reply-To: <201403251142.00861.okir@suse.de>
References: <53307058.6000209@netlab1.net> <201403251142.00861.okir@suse.de>
Message-ID: <53316844.2090803@netlab1.net>

Olaf,
     With much respect, yes, the presentation missed a lot of targets 
and stirred up the natives. I understand that, having done my share of 
these things. What we are doing now in this follow up thread is bringing 
to light the better parts of this, with more context.
     On the current if* scripts. Indeed, the scheme has grown into a 
byzantine collection of apps, poorly documented and with horrid command 
line syntax. We agree that this area could be done vastly better. We 
aren't there yet, the travel arrangements and what the destination looks 
like are not known to us in the field. My hope is this will be another 
solidly engineered SUSE project, as many are.
In the meanwhile we have servers to keep running and future side effects 
to consider. Those scripts keep us going. That is why I commented that 
the heavy development should be a parallel effort until it is ready to 
assume active duty.
     Mere managers rightly ask what is that new approach doing to my 
gear, and can I cope with it (whatever presently nebulous "it" may 
mean). There needs to be a smooth transition, with suitable warm fuzzies.
     The XML stuff illustrates an aspect which we tend to lose sight of 
while pounding keys. It is the user side of the work. We know that XML 
is By Computers For Computers, not for people. And we know that people 
have to control things (else we are doomed). In the end people ought to 
be the winners. Thus a small amount of computer science is needed to 
keep things people friendly yet expressive enough for technical nuances. 
Lists are no problem, standard stuff. Categories are not much of a 
problem either, as we can see in zillions of configuration files on our 
machines. Handling this well is an integral part of the design process, 
not much fun but really necessary.
     On the current networking problems. I will accept your comments 
that wicked is not the guilty party. Good.
     Once again, I am much in favour of such creative work. We need to 
manage it well.
     A couple of quick comments are in-line below.
     Thanks,
     Joe D.

On 25/03/2014 10:42, Olaf Kirch wrote:
> Hello Joe,
>
> On Monday 24 March 2014 18:50:16 Joe Doupnik wrote:
>>       If I may, this is a better place to make some comments on the
>> interesting presentation about wicked today. I will be critical, but in
>> a sympathetic way.
>>       To start with the bottom line as I see things at this time. This is
>> an experiment which ought to appear in production a year from now. The
>> attempt seems to be to invent a robot which somehow magically makes all
>> that "complicated" networking gear disappear behind a on/off switch plus
>> a green/red light.
> Well, apparently I did a very bad job at describing the intention of this
> new development.
>
> (1) We did this because the complexity of the ifup/ifdown script melange
> 	was beyond the breaking point. Honestly, trying to extend what we
> 	have has driven developers up the wall :)
>
> 	And we did extend this framework a lot - I tried to give a first
> 	order approximatin with my slides, but maybe that was too visual
> 	an attempt... but if you look past traditional IPv4 networking,
> 	there's a huge set of changes around DCB, FCoE support, iBFT, IPv6,
> 	bonding and bridging, virtualization related stuff etc, all of which
> 	went in over the past couple of years.
>
> 	And more is in the pipeline - I'm sure we haven't seen the last
> 	IPv6 tunneling technologies; there's NIC teaming support that's being
> 	requested, and so on. And remember, this product is going to be in
> 	the market for a long time. So the last thing we want to do is keep
> 	gluing more bits and pieces to something that showing structural
> 	strains already today.
>
> (2)	This is not about dumbing down anything. It's not about making
> 	complicated stuff disappear - it's about making complex stuff
> 	available to the admin in a useful way.
>
> 	Can you, or anyone else on the list, tell me off the top of your head
> 	(and without going back through lots of READMEs) how to do all of
> 	the following:
>
> 	... disable IPv6 on a specific interface?
             A YaST and /etc/sysconfig option
> 	... set up an interface for DHCPv4 and DHCPv6?
         A Yast, /etc/sysconfig/network ifcfg-X, and in some cases 
ifconfig options
> 	... change the link speed on an Ethernet interface?

     IP, horrid syntax and worse man page not withstanding.

> 	... reconfigure a bonding device without bringing it down?
> 	... set up a bridge on top of a bond
> 	... change the firewall rules on your UMTS modem?
> 	... set up 802.1x authentication for your Ethernet NIC?
> 	... set up persistent names for your System z devices?
> 	... disable segmentation offloading on your Ethernet NIC?
>
> 	There are knobs and tunables for all of these things. Right now,
> 	they're not available to the admin (short of messing with
> 	rc.local scripts), or if they are, they need some non-intuitive
> 	syntax.
>
> Our goal with wicked would be to offer as many of these through one
> consistent configuration file format.

     Yes, you have good points in the latter half of the list. What's 
missing is presentation to the sysadmin. YaST is a highly useful tool, 
see and change. The above list items are handled today, not slickly but 
using known methods.

>
>> That is an interesting goal, speaking
>> sympathetically, but first one ought to sort things into simple
>> arrangements so that people can easily cope with it.
> Correct. And this is why, in SLE12, we started by replacing the old ifcfg
> machinery, while still retaining the interfaces (read, the ifcfg files).
> We're taking one step after the other, avoiding to change too many things
> at once. As a consequence, wicked is currently not living up to the promise.
> The best it can offer in GA is being as stable as its predecessor - but with
> SP1, I would like us to move to the new config file format that actually
> offers all the power of a unified API.
>
>>       Our discussions on the list about lan device naming and similar
>> reflect the realities we have in the field today, being very clear about
>> This device does That thing in a form compatible with other parts of the
>> system, as well as our need to see that information at it is preserved
>> in configuration files. In other words, people are smarter than the
>> robot and should win more than an average number of battles with such
>> things. To couple the two requires much thinking about what displays and
>> what controls each side should have.
> Well, let's not confuse two things here - the naming issue has nothing,
> absolutely nothing to do with the introduction of wicked. It's a separate
> issue. (And I assume the wireshark problem seen recently is yet a different
> topic).
>
> One way to address it would be to reintroduce the old SLE11 code for device
> renaming back to udev. So far, we're pretty reluctant to go there, beceause
> it has a tendency to break once in a while because it's an inherently racy
> operation, especially on machines with lots of NICs.
>
> The other way is to try to get rid of a dependency on names as much as possible.
> How many people actually did implement their own naming scheme? I think, most
> everyone was happy that the system did offer naming persistence, but didn't
> really care if NIC A was called eth0 or eth1, as long as that didn't change
> over the life time of the system.
>
> And I think that is the main point. Yes, I agree, en123456789 is neither
> easy to remember nor easy to type, but can we agree that this is a secondary
> issue (worth addressing, but maybe less pressing?)
>
>>       Additional comments on XML files and similar. I am in the camp
>> which says that is for computers to read and write, not for people. The
>> current situation is one of creating name-value pairs, so far as I can
>> surmise, not complicated hierarchical structures. Classical name-value
>> files are for people as much as computers. They work well with people,
>> and computers think they are trivial to parse. Thus, why complicate when
>> it isn't necessary or desirable to do so.
> Point taken. One remark on hierarchy though - that's something that will be
> needed. If you think of IP addresses assigned to a NIC, you're talking
> about lists, potentially. For routing, you're talking about lists as
> well, and possibly even nested. All of that is currently flattened
> artificially because of the very restricted syntax that the shell offers
> (as in the case of IPADDR_* variables), or because of what we can parse
> easily in a shell script (eg in the case of the ifcfg-routes file). But
> I wouldn't go as far as establishing that as the gold standard worth
> enshrining for eternity.
>
> Regards,
> Olaf


From kukuk at suse.de  Tue Mar 25 09:08:17 2014
From: kukuk at suse.de (Thorsten Kukuk)
Date: Tue, 25 Mar 2014 16:08:17 +0100
Subject: [sles-beta] Upgrade fromSLE 11-3 to 12-0 on x86_64
In-Reply-To: <46AC8C81C10B8C48820201DF2AE1D76D5377DB19@hqmbx6.eur.ad.sag>
References: <46AC8C81C10B8C48820201DF2AE1D76D5377CD49@hqmbx6.eur.ad.sag>
	<46AC8C81C10B8C48820201DF2AE1D76D5377DB19@hqmbx6.eur.ad.sag>
Message-ID: <20140325150817.GA22017@suse.de>


Hi,

On Tue, Mar 25, Waite, Dick wrote:

> Grand New Day,
>           I have created a SR on my issue with upgrade. Service Request: 10884981671
>           I was not sure upgrade was supported in Beta3 but did get confirmation at the Beta Con_Call last night it is working. I tried again this morning and get the same message, "The installed product is not compatible with the product on the installation media. If you try to update using the current installation media, the system may not start or some applications may not run properly."

Yes, you are getting this message, and yes, you should take them
serious, but: you can press "continue" and do the update.

We are still in an early beta phase and there are still a lot of
bugs.

  Thorsten

-- 
Thorsten Kukuk, Senior Architect SLES & Common Code Base
SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg)

From Dick.Waite at softwareag.com  Tue Mar 25 23:05:22 2014
From: Dick.Waite at softwareag.com (Waite, Dick)
Date: Wed, 26 Mar 2014 05:05:22 +0000
Subject: [sles-beta] Upgrade fromSLE 11-3 to 12-0 on x86_64
In-Reply-To: <20140325150817.GA22017@suse.de>
References: <46AC8C81C10B8C48820201DF2AE1D76D5377CD49@hqmbx6.eur.ad.sag>
	<46AC8C81C10B8C48820201DF2AE1D76D5377DB19@hqmbx6.eur.ad.sag>,
	<20140325150817.GA22017@suse.de>
Message-ID: <46AC8C81C10B8C48820201DF2AE1D76D5377DE1C@hqmbx6.eur.ad.sag>

Grand New Day Thorsten,

Oh I did try to push on, but I never managed to get the re-ipl on 12-0 to work with a display manager. Sometimes it did not finish the upgrade, these issues seem to do with Network, the words are in my weekend email. Sometimes I could get to a user prompt in the 12-0 and I did try "startx" but I was then given lines of errors.
For me it is very repro. Lets see what the good level 3 people come up with. SR 10884981671

__R

________________________________________
From: sles-beta-bounces at lists.suse.com [sles-beta-bounces at lists.suse.com] on behalf of Thorsten Kukuk [kukuk at suse.de]
Sent: 25 March 2014 16:08
To: sles-beta at lists.suse.com
Subject: Re: [sles-beta] Upgrade fromSLE 11-3 to 12-0 on x86_64

Hi,

On Tue, Mar 25, Waite, Dick wrote:

> Grand New Day,
>           I have created a SR on my issue with upgrade. Service Request: 10884981671
>           I was not sure upgrade was supported in Beta3 but did get confirmation at the Beta Con_Call last night it is working. I tried again this morning and get the same message, "The installed product is not compatible with the product on the installation media. If you try to update using the current installation media, the system may not start or some applications may not run properly."

Yes, you are getting this message, and yes, you should take them
serious, but: you can press "continue" and do the update.

We are still in an early beta phase and there are still a lot of
bugs.

  Thorsten

--
Thorsten Kukuk, Senior Architect SLES & Common Code Base
SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
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

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 mt at suse.de  Wed Mar 26 01:52:37 2014
From: mt at suse.de (Marius Tomaschewski)
Date: Wed, 26 Mar 2014 08:52:37 +0100
Subject: [sles-beta] SLES12 x86_64 Beta3 autoyast issue /etc/hosts no
 hostname entry
In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0EFA8953@HXMB12.pnet.ch>
References: <40637DBB36AF3941B243A286A432CA0B0EFA8953@HXMB12.pnet.ch>
Message-ID: <53328745.5060006@suse.de>

Am 25.03.2014 17:02, schrieb urs.frey at post.ch:
> Hi
Hi!

BTW: You don't need to add me to Cc -- I'm on the list too :-)

I don't have much clue about all the yast2 stuff -- I'm one from
the backend (wicked + sysconfig) side.... but let's try:

> In my autoinst.xml I do have DNS and hostname definition included.
> But on the installed server in /etc/hosts there gets only localhost defined,
 > the entry of the own IP address and hostname is missing
>
>    <networking>
>      <dns>
>        <dhcp_hostname config:type="boolean">false</dhcp_hostname>

AFAIS, this causes to set DHCLIENT_SET_HOSTNAME="no"

>        <dhcp_resolv config:type="boolean">false</dhcp_resolv>

A "grep -rl dhcp_resolv $(rpm -ql autoyast2-installation)" does not show 
any match.

>        <domain>pnet.ch</domain>
>        <hostname>h063uz</hostname>

-> AFAIS, it causes to write $hostname.$domain into /etc/HOSTNAME

>        <nameservers config:type="list">
>          <nameserver>10.1.121.11</nameserver>
>          <nameserver>10.2.121.11</nameserver>
>        </nameservers>

-> NETCONFIG_DNS_STATIC_SERVERS

>        <searchlist config:type="list">
>          <search>pnet.ch</search>
>          <search>post.ch</search>
>        </searchlist>

-> NETCONFIG_DNS_STATIC_SEARCHLIST

>      </dns>
[...]

> /etc/hosts file I get
>
> h063uz:~ # cat /etc/hosts
[...]
> h063uz:~ #

IMO it looks fine with this profile.

> Do I look at the wrong end? I mean in all our /etc/hosts files there is an entry
> When I do install the very same server manually and configure the network in yast2
 > I do end up with an /etc/hosts entry
>
> 127.0.0.1       localhost
> 10.226.154.19   h063uz.pnet.ch h063uz


This is caused by the yast2 only setting WRITE_HOSTNAME_TO_HOSTS=yes [it 
is never used by anything else] -- default is "no" and it may be
set by some per-product defaults.

Note: it disables dns lookups for the own hostname & ip completely
and may break things.

I'd say, you profile is missing this statement in <dns>:

    <write_hostname config:type="boolean">true</write_hostname>

Gruesse / Regards,
  Marius Tomaschewski <mt at suse.de>, <mt at suse.com>
-- 
  SUSE LINUX Products GmbH, HRB 16746 (AG N?rnberg),
  GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer,
  Maxfeldstra?e 5, 90409 N?rnberg, Germany

From mt at suse.de  Wed Mar 26 01:59:13 2014
From: mt at suse.de (Marius Tomaschewski)
Date: Wed, 26 Mar 2014 08:59:13 +0100
Subject: [sles-beta] SLES12 x86_64 Beta3 autoyast issue /etc/hosts no
 hostname entry
In-Reply-To: <53328745.5060006@suse.de>
References: <40637DBB36AF3941B243A286A432CA0B0EFA8953@HXMB12.pnet.ch>
	<53328745.5060006@suse.de>
Message-ID: <533288D1.508@suse.de>

Am 26.03.2014 08:52, schrieb Marius Tomaschewski:
> Am 25.03.2014 17:02, schrieb urs.frey at post.ch:
>> Hi
> Hi!
>
> BTW: You don't need to add me to Cc -- I'm on the list too :-)

Ahm... just my confusion -- the list seems to do it automatically.

Gruesse / Regards,
  Marius Tomaschewski <mt at suse.de>, <mt at suse.com>
-- 
  SUSE LINUX Products GmbH, HRB 16746 (AG N?rnberg),
  GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer,
  Maxfeldstra?e 5, 90409 N?rnberg, Germany

From urs.frey at post.ch  Wed Mar 26 07:41:15 2014
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Wed, 26 Mar 2014 13:41:15 +0000
Subject: [sles-beta] SLES12 x86_64 Beta3 autoyast issue /etc/hosts no
 hostname entry
In-Reply-To: <53328745.5060006@suse.de>
References: <40637DBB36AF3941B243A286A432CA0B0EFA8953@HXMB12.pnet.ch>
	<53328745.5060006@suse.de>
Message-ID: <40637DBB36AF3941B243A286A432CA0B0EFA8B2C@HXMB12.pnet.ch>

Hello Marius

Thank you very much!
I inserted as you told in my autoinst.xml
    <dns>
      <dhcp_hostname config:type="boolean">false</dhcp_hostname>
      <dhcp_resolv config:type="boolean">false</dhcp_resolv>
      <write_hostname config:type="boolean">true</write_hostname>
      <domain>pnet.ch</domain>
      <hostname>h063uz</hostname>
      <nameservers config:type="list">
        <nameserver>10.1.121.11</nameserver>
        <nameserver>10.2.121.11</nameserver>
      </nameservers>
      <searchlist config:type="list">
        <search>pnet.ch</search>
        <search>post.ch</search>
      </searchlist>
    </dns>

But the result is not exactly what I expect. Hostname gets written, but the TCP/IP Address is not the correct one
#
# hosts         This file describes a number of hostname-to-address
#               mappings for the TCP/IP subsystem.  It is mostly
#               used at boot time, when no name servers are running.
#               On small systems, this file can be used instead of a
#               "named" name server.
# Syntax:
#
# IP-Address  Full-Qualified-Hostname  Short-Hostname
#

127.0.0.1       localhost

# special IPv6 addresses
::1             localhost ipv6-localhost ipv6-loopback

fe00::0         ipv6-localnet

ff00::0         ipv6-mcastprefix
ff02::1         ipv6-allnodes
ff02::2         ipv6-allrouters
ff02::3         ipv6-allhosts
127.0.0.2       h063uz.pnet.ch h063uz

I expect to have the configured IP address in my /etc/hosts, just the way it gets written when I configure manually, using yast
10.226.154.19 h063uz.pnet.ch h063uz

#
# hosts         This file describes a number of hostname-to-address
#               mappings for the TCP/IP subsystem.  It is mostly
#               used at boot time, when no name servers are running.
#               On small systems, this file can be used instead of a
#               "named" name server.
# Syntax:
#
# IP-Address  Full-Qualified-Hostname  Short-Hostname
#

127.0.0.1       localhost

# special IPv6 addresses
::1             localhost ipv6-localhost ipv6-loopback

fe00::0         ipv6-localnet

ff00::0         ipv6-mcastprefix
ff02::1         ipv6-allnodes
ff02::2         ipv6-allrouters
ff02::3         ipv6-allhosts
10.226.154.19   h063uz.pnet.ch h063uz

I also tried to extend the autoinst.xml code and to define host within autoinst.xml, but I never get the correct result

  <networking>
    <dns>
      <dhcp_hostname config:type="boolean">false</dhcp_hostname>
      <dhcp_resolv config:type="boolean">false</dhcp_resolv>
      <write_hostname config:type="boolean">true</write_hostname>
      <domain>pnet.ch</domain>
      <hostname>h063uz</hostname>
      <nameservers config:type="list">
        <nameserver>10.1.121.11</nameserver>
        <nameserver>10.2.121.11</nameserver>
      </nameservers>
      <searchlist config:type="list">
        <search>pnet.ch</search>
        <search>post.ch</search>
      </searchlist>
    </dns>
    <host>
      <hosts config:type="list">
         <hosts_entry>
           <host_address>127.0.0.1</host_address>
           <names config:type="list">
              <name>localhost</name>
           </names>
         </hosts_entry>
         <hosts_entry>
           <host_address>10.226.154.19</host_address>
           <names config:type="list">
              <name>h063uz.pnet.ch h063uz</name>
           </names>
       </hosts>
    </host>

So from my point of view, there is something wrong 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: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Marius Tomaschewski
Gesendet: Wednesday, March 26, 2014 8:53 AM
An: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] SLES12 x86_64 Beta3 autoyast issue /etc/hosts no hostname entry

Am 25.03.2014 17:02, schrieb urs.frey at post.ch:
> Hi
Hi!

BTW: You don't need to add me to Cc -- I'm on the list too :-)

I don't have much clue about all the yast2 stuff -- I'm one from
the backend (wicked + sysconfig) side.... but let's try:

> In my autoinst.xml I do have DNS and hostname definition included.
> But on the installed server in /etc/hosts there gets only localhost defined,
 > the entry of the own IP address and hostname is missing
>
>    <networking>
>      <dns>
>        <dhcp_hostname config:type="boolean">false</dhcp_hostname>

AFAIS, this causes to set DHCLIENT_SET_HOSTNAME="no"

>        <dhcp_resolv config:type="boolean">false</dhcp_resolv>

A "grep -rl dhcp_resolv $(rpm -ql autoyast2-installation)" does not show 
any match.

>        <domain>pnet.ch</domain>
>        <hostname>h063uz</hostname>

-> AFAIS, it causes to write $hostname.$domain into /etc/HOSTNAME

>        <nameservers config:type="list">
>          <nameserver>10.1.121.11</nameserver>
>          <nameserver>10.2.121.11</nameserver>
>        </nameservers>

-> NETCONFIG_DNS_STATIC_SERVERS

>        <searchlist config:type="list">
>          <search>pnet.ch</search>
>          <search>post.ch</search>
>        </searchlist>

-> NETCONFIG_DNS_STATIC_SEARCHLIST

>      </dns>
[...]

> /etc/hosts file I get
>
> h063uz:~ # cat /etc/hosts
[...]
> h063uz:~ #

IMO it looks fine with this profile.

> Do I look at the wrong end? I mean in all our /etc/hosts files there is an entry
> When I do install the very same server manually and configure the network in yast2
 > I do end up with an /etc/hosts entry
>
> 127.0.0.1       localhost
> 10.226.154.19   h063uz.pnet.ch h063uz


This is caused by the yast2 only setting WRITE_HOSTNAME_TO_HOSTS=yes [it 
is never used by anything else] -- default is "no" and it may be
set by some per-product defaults.

Note: it disables dns lookups for the own hostname & ip completely
and may break things.

I'd say, you profile is missing this statement in <dns>:

    <write_hostname config:type="boolean">true</write_hostname>

Gruesse / Regards,
  Marius Tomaschewski <mt at suse.de>, <mt at suse.com>
-- 
  SUSE LINUX Products GmbH, HRB 16746 (AG N?rnberg),
  GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer,
  Maxfeldstra?e 5, 90409 N?rnberg, Germany
_______________________________________________
sles-beta mailing list
sles-beta at lists.suse.com
http://lists.suse.com/mailman/listinfo/sles-beta

From bjoern.lotz at suse.com  Wed Mar 26 11:05:19 2014
From: bjoern.lotz at suse.com (Bjoern Lotz)
Date: Wed, 26 Mar 2014 18:05:19 +0100
Subject: [sles-beta] Apparmor, rsyslogd
Message-ID: <533308CF.7040707@suse.com>

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

Hi,

installed SLES 12 Beta3 and started to orient myself.

What I noticed:

In /etc/apparmor.d/, there are profiles for syslog and syslog-ng
(these are not part of the installation media), but there is no
profile for rsyslogd.

I tried to create a profile for rsyslogd:

genprof /usr/sbin/rsyslogd

result:

Can't find include file abstractions/libvirt-driver: No such file or
directory

So I went to yast2, the apparmor module allows me to create an initial
profile, but does not set it to enforce mode, which effectively blocks
rsyslogd completely.

Manually put it to complain mode, restarted rsyslogd.

Tried to update the profile:

aa-logprof

result:

Can't find include file abstractions/libvirt-driver: No such file or
directory

There is indeed no such file in the abstractions directory.

grepping for libvirt-driver in /etc/apparmor.d/ brings up
libvirt/TEMPLATE:  #include <abstractions/libvirt-driver>
(no idea if this is related).

Is there some know workaround? (Didn't see something related in
Bugzilla yet.)

Kind regards,

Bj?rn

- -- 
Dr. Bj?rn Lotz, Instructional Designer, CISSP
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 N?rnberg
Tel: +49 89 8639 9664  Mobil: +49 173 5876724
bjoern.lotz at suse.com       PGP-ID: 0xD437D363
- ------------------
SUSE Linux GmbH, N?rnberg; HRB 21284 (AG N?rnberg)
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlMzCMgACgkQKZToxtQ302P2BgCg3J8XBOkpmleylGFfWXuubYTF
+REAnj08oyj7bns88MNRMgNmlGwj5if8
=x1z0
-----END PGP SIGNATURE-----

From msvec at suse.com  Wed Mar 26 12:05:38 2014
From: msvec at suse.com (Michal Svec)
Date: Wed, 26 Mar 2014 19:05:38 +0100 (CET)
Subject: [sles-beta] [ANNOUNCE] VMDP 2.2 Beta is available
Message-ID: <alpine.LSU.2.11.1403261537270.21709@glum.suse.cz>


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


Dear Beta participants,

we are happy to announce

 	SUSE Linux Enterprise Virtual Machine Driver Pack 2.2 Beta

SUSE Linux Enterprise Virtual Machine Driver Pack (VMDP) contains
disk and network device drivers for Microsoft Windows Operating
Systems that enable the high performance hosting of the unmodified
guests on top of SUSE Linux Enterprise Server.

Supported host operating systems are SUSE Linux Enterprise Server
10 SP4 and SUSE Linux Enterprise Server 11 SP2 or later. SUSE Linux
Enterprise Virtual Machine Driver Pack contains paravirtualized
drivers for both KVM and Xen hypervisors, available as part of our
SUSE Linux Enterprise Server product.

The key updates in version 2.2 are:
   - Support for SUSE Linux Enterprise Server 12
   - Support for new Microsoft Windows releases:
     - Microsoft Windows Server 2012 R2
     - Microsoft Windows 8.1
   - Simplified hypervisor migration

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.

The SUSE Linux Enterprise Virtual Machine Driver Pack is available
for download in four formats:
  * Windows self-extracting zip file (.exe)
  * Virtual floppy disk (.vfd) for Windows XP and 2003
  * ISO image (.iso) for Windows 2008 and newer
  * RPM package for V2V conversion purposes
  - Both the vfd and iso are for virtio boot disk driver installation
    at Windows KVM VM creation time

Please verify the md5sum of the downloaded files using the 
vmdp-140227_sums file, which can be found in the same directory
on the download servers.

Thanks in advance for all your testing

         Your SUSE Linux Enterprise Team



-- 
Michal Svec
Senior Product Manager
SUSE Linux Enterprise, Virtualization
SUSE, www.suse.com


From urs.frey at post.ch  Thu Mar 27 04:38:25 2014
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Thu, 27 Mar 2014 10:38:25 +0000
Subject: [sles-beta] VMware integration - was: SLES12 Beta Question
 concerning systemd /etc/init.d/boot.local
In-Reply-To: <532C185E.3070309@suse.com>
References: <40637DBB36AF3941B243A286A432CA0B0E5B88B0@HXMB12.pnet.ch>
	<1394794249.28828.9.camel@par-r81vxc7.par.novell.com>
	<40637DBB36AF3941B243A286A432CA0B0E5B88E5@HXMB12.pnet.ch>
	<532326BF.8030800@suse.com>
	<40637DBB36AF3941B243A286A432CA0B0E5B8999@HXMB12.pnet.ch>
	<532C185E.3070309@suse.com>
Message-ID: <40637DBB36AF3941B243A286A432CA0B0EFA9433@HXMB12.pnet.ch>

Hello Kai
Thank you very much.
Yes while having a look in /usr/lib/system/system I could find a  vmtoolsd service
And as you already noted below, when enabling and starting it, on my V-sphere console I could see "? third party provider"

I see quite a challenge in providing vmware kernel modules on SLES and keeping the V-sphere console display on "supported, actual version"
- Not everybody does run the same ESXi version
- Not everybody has the same update cycle of the ESXi versions
- How to synchronize ESXi version cycles with SLES kernel update cycles

Just a few thoughts of mine
I know SUSE ISV and SUSE engineering are a very powerful organizations;-  you will find a way

Thank you in advance
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 Kai Dupke
Gesendet: Friday, March 21, 2014 11:46 AM
An: sles-beta at lists.suse.com
Betreff: [sles-beta] VMware integration - was: SLES12 Beta Question concerning systemd /etc/init.d/boot.local

On 03/14/2014 05:02 PM, urs.frey at post.ch wrote:
> Really hope that there is something which does work out-of-the box with the VMwareTools delivered by VMware on the ESXi releases
> Maybe SLES12 has already VMware certified modules in- Kernel, or there is a Partner package one can select from the SLES bundle


o Added open-vm-tools (feature)	[x86_64]

It isn't marked supported yet. We're are working with VMware to be able
to mark it fully supported to deliver a one stop support.

Same way you should find the VMware drivers.

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 markus.hubler at isc-ejpd.admin.ch  Thu Mar 27 08:11:30 2014
From: markus.hubler at isc-ejpd.admin.ch (markus.hubler at isc-ejpd.admin.ch)
Date: Thu, 27 Mar 2014 14:11:30 +0000
Subject: [sles-beta] Workaround for grub2-install?
Message-ID: <59462F911036934D8BF6834B607DD7CE7AF15ADD@sb00106a.adb.intra.admin.ch>

Hi list

When doing an autoyast installation (my SR 10884844201) I have the problem that grub2-install seems to fail.
After having booted into rescue mode and chroot to the installation grub2-install /dev/sda fixes the problem.

Do you have a workaround for that. I have tried on different platforms (virtualbox/ vmware) and I met always the same problem.

Regards
Markus






From bdang at vmware.com  Thu Mar 27 21:40:15 2014
From: bdang at vmware.com (Bo Dang)
Date: Thu, 27 Mar 2014 20:40:15 -0700 (PDT)
Subject: [sles-beta] VMware integration - was: SLES12 Beta Question
 concerning systemd /etc/init.d/boot.local
In-Reply-To: <53340703.3090606@suse.com>
References: <40637DBB36AF3941B243A286A432CA0B0E5B88B0@HXMB12.pnet.ch>
	<1394794249.28828.9.camel@par-r81vxc7.par.novell.com>
	<40637DBB36AF3941B243A286A432CA0B0E5B88E5@HXMB12.pnet.ch>
	<532326BF.8030800@suse.com>
	<40637DBB36AF3941B243A286A432CA0B0E5B8999@HXMB12.pnet.ch>
	<532C185E.3070309@suse.com>
	<40637DBB36AF3941B243A286A432CA0B0EFA9433@HXMB12.pnet.ch>
	<53340703.3090606@suse.com>
Message-ID: <699928294.51941998.1395978015240.JavaMail.root@vmware.com>

Hi Kai and Urs,

Thanks for this info and keep contacting us! As john metnioned in another thread "The intent of the message was to communicate that end users do not need to worry about installing/updating VMware tools centrally from vCenter. Instead users are expected to use OS package manager to maintain vmware tools or open-vm-tools. We published the following KB article to clarify that open-vm-tools are "supported" and there is a FAQ at the bottom about this message at http://kb.vmware.com/kb/2073803 " and we are planning to change message in the future to remove "3rd Party" and instead say something like "Guest Managed" to reduce user concerns.

If you have questions, feel free to ping us again!

Best Regards,
Bo

bdang at vmware.com
Level 8 South Wing of Tower C Raycom InfoTech Park
No. 2 Kexueyuan South Road Haidian District Beijing, 100190, People's Republic of China

----- Original Message -----
From: "Kai Dupke" <kdupke at suse.com>
To: sles-beta at lists.suse.com
Sent: Thursday, March 27, 2014 7:09:55 PM
Subject: Re: [sles-beta] VMware integration - was: SLES12 Beta Question concerning systemd /etc/init.d/boot.local

On 03/27/2014 11:38 AM, urs.frey at post.ch wrote:
> Just a few thoughts of mine
> I know SUSE ISV and SUSE engineering are a very powerful organizations;-  you will find a way

They way we're going is to work with VMware to get the drivers and tools
formally supported with SUSE the primary support contact for the SLES
side, which will mark them as supported in SLES.

If I understood you right, then the 3rd party message is in Vspehre and
not on the SLES console, right? For that I will have to check with VMware.

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

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


_______________________________________________
sles-beta mailing list
sles-beta at lists.suse.com
https://urldefense.proofpoint.com/v1/url?u=http://lists.suse.com/mailman/listinfo/sles-beta&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=UKSbxMIYAkSEPzTbqdSR3w%3D%3D%0A&m=HTxSJw%2BDVwS%2B9erpog7RtHPWxNVjU57eC6QqoRGT63I%3D%0A&s=24dab049ab9ef5569148ba0cff7c2c53ddf18f75ae3e6f84471dc729752cc054

From urs.frey at post.ch  Fri Mar 28 02:37:48 2014
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Fri, 28 Mar 2014 08:37:48 +0000
Subject: [sles-beta] SLES12-Beta3 splash grub2 problem grub2-mkconfig
 does not change /boot/grub2/grub.cfg
In-Reply-To: <20140327224831.GA15519@miranda.suse.de>
References: <40637DBB36AF3941B243A286A432CA0B0EFA93F4@HXMB12.pnet.ch>
	<20140327224831.GA15519@miranda.suse.de>
Message-ID: <40637DBB36AF3941B243A286A432CA0B0EFA962B@HXMB12.pnet.ch>

Hello Karol

Thank you very much! Shame on me, not reading the man page carefully...

SYNOPSIS
       grub-mkconfig [OPTION]

DESCRIPTION
       Generate a grub config file

       -o, --output=FILE
              output generated config to FILE [default=stdout]

YES you are right!

h063uz:~ # grep splash /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0 resume=/dev/sdb1 splash=verbose  showopts crashkernel=256M-:128M"
h063uz:~ # grep splash /boot/grub2/grub.cfg
        linux   /vmlinuz-3.12.14-1-default root=UUID=9a33ade3-9ee0-4323-a967-f205ddea3e83 splash=silent quiet net.ifnames=0 resume=/dev/sdb1 splash=silent  showopts crashkernel=256M-:128M
                linux   /vmlinuz-3.12.14-1-default root=UUID=9a33ade3-9ee0-4323-a967-f205ddea3e83 splash=silent quiet net.ifnames=0 resume=/dev/sdb1 splash=silent  showopts crashkernel=256M-:128M
h063uz:~ # grub2-mkconfig --output=/boot/grub2/grub.cfg
Generating grub configuration file ...
Found theme: /boot/grub2/themes/SLE/theme.txt
Found linux image: /boot/vmlinuz-3.12.14-1-default
Found initrd image: /boot/initrd-3.12.14-1-default
  No volume groups found
done
h063uz:~ # grep splash /boot/grub2/grub.cfg
        linux   /vmlinuz-3.12.14-1-default root=UUID=9a33ade3-9ee0-4323-a967-f205ddea3e83  net.ifnames=0 resume=/dev/sdb1 splash=verbose  showopts crashkernel=256M-:128M
                linux   /vmlinuz-3.12.14-1-default root=UUID=9a33ade3-9ee0-4323-a967-f205ddea3e83  net.ifnames=0 resume=/dev/sdb1 splas =verbose  showopts crashkernel=256M-:128M
h063uz:~ #

Thank you very much
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: Karol Mroz [mailto:kmroz at suse.com] 
Gesendet: Thursday, March 27, 2014 11:49 PM
An: Frey Urs, IT222
Cc: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] SLES12-Beta3 splash grub2 problem grub2-mkconfig does not change /boot/grub2/grub.cfg

On Thu, Mar 27, 2014 at 09:48:39AM +0000, urs.frey at post.ch wrote:
> Hi

Hi Urs,

Please see inline...

> 
> When there is need getting rid of the default setting splash=silent in grub2, one may change the file
> /etc/default/grub
> This is directed in /boot/grub2/grub.cfg
> 
> #
> # DO NOT EDIT THIS FILE
> #
> # It is automatically generated by grub2-mkconfig using templates
> # from /etc/grub.d and settings from /etc/default/grub
> #
> 
> The problem is now, when I am going to change in /etc/default/grub from slash=silent quiet => splash=verbose
> and run grub2-mkconfig, within the file /boot/grub2/grub.cfg nothing gets changed
> 
> 
> h063uz:~ # grep splash /boot/grub2/grub.cfg
>         linux   /vmlinuz-3.12.14-1-default root=UUID=9a33ade3-9ee0-4323-a967-f205ddea3e83 splash=silent quiet net.ifnames=0 resume=/dev/sdb1 splash=silent  showopts crashkernel=256M-:128M
>                 linux   /vmlinuz-3.12.14-1-default root=UUID=9a33ade3-9ee0-4323-a967-f205ddea3e83 splash=silent quiet net.ifnames=0 resume=/dev/sdb1 splash=silent  showopts crashkernel=256M-:128M
> h063uz:~ # grep splash /etc/default/grub
> GRUB_CMDLINE_LINUX_DEFAULT="splash=silent net.ifnames=0 resume=/dev/sdb1 splash=silent quiet showopts crashkernel=256M-:128M"
> h063uz:~ # sed -i "s/splash=silent/splash=verbose/g" /etc/default/grub
> h063uz:~ # sed -i "s/quiet//g" /etc/default/grub
> h063uz:~ # grep splash /etc/default/grub
> GRUB_CMDLINE_LINUX_DEFAULT="splash=verbose net.ifnames=0 resume=/dev/sdb1 splash=verbose  showopts crashkernel=256M-:128M"
> h063uz:~ # grub2-mkconfig

I believe the above command should be: # grub2-mkconfig --output=/boot/grub2/grub.cfg
Issuing the command without the --output switch only dumps the newly generated file (with changes parsed from
/etc/default/grub) to stdout.

Please give this a try to see if it corrects the problem for you.

-Karol

From mt at suse.de  Fri Mar 28 04:00:24 2014
From: mt at suse.de (Marius Tomaschewski)
Date: Fri, 28 Mar 2014 11:00:24 +0100
Subject: [sles-beta] SLES12 x86_64 Beta3 autoyast issue /etc/hosts no
 hostname entry
In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0EFA8B2C@HXMB12.pnet.ch>
References: <40637DBB36AF3941B243A286A432CA0B0EFA8953@HXMB12.pnet.ch>	<53328745.5060006@suse.de>
	<40637DBB36AF3941B243A286A432CA0B0EFA8B2C@HXMB12.pnet.ch>
Message-ID: <53354838.604@suse.de>

Am 26.03.2014 14:41, schrieb urs.frey at post.ch:
> Hello Marius
>
> Thank you very much!

Hi!

You're welcome!

> I inserted as you told in my autoinst.xml
>      <dns>
>        <dhcp_hostname config:type="boolean">false</dhcp_hostname>
>        <dhcp_resolv config:type="boolean">false</dhcp_resolv>
>        <write_hostname config:type="boolean">true</write_hostname>
>        <domain>pnet.ch</domain>
>        <hostname>h063uz</hostname>
>        <nameservers config:type="list">
>          <nameserver>10.1.121.11</nameserver>
>          <nameserver>10.2.121.11</nameserver>
>        </nameservers>
>        <searchlist config:type="list">
>          <search>pnet.ch</search>
>          <search>post.ch</search>
>        </searchlist>
>      </dns>
>
> But the result is not exactly what I expect. Hostname gets written, but the TCP/IP Address is not the correct one

Ah... the "write_hostname" seems to result in the 127.0.0.2 hack.

Originally intended as fallback to get the hostname resolved when
there is no IP address available on dynamic (ppp,dhcp) links...
and breaking resolving of the hostname completely as it causes to
always resolve the hostname to 127.0.0.2... even the IP is there.
So "write_hostname" seems the wrong way to do it.

>      <host>
>        <hosts config:type="list">
>           <hosts_entry>
>             <host_address>127.0.0.1</host_address>
>             <names config:type="list">
>                <name>localhost</name>
>             </names>
>           </hosts_entry>
>           <hosts_entry>
>             <host_address>10.226.154.19</host_address>
>             <names config:type="list">
>                <name>h063uz.pnet.ch h063uz</name>
>             </names>
>         </hosts>
>      </host>
>
> So from my point of view, there is something wrong with autoyast

Open a bug report for autoyast2. I've no idea about this machinery.

Gruesse / Regards,
  Marius Tomaschewski <mt at suse.de>, <mt at suse.com>
-- 
  SUSE LINUX Products GmbH, HRB 16746 (AG N?rnberg),
  GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer,
  Maxfeldstra?e 5, 90409 N?rnberg, Germany

From urs.frey at post.ch  Fri Mar 28 04:14:49 2014
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Fri, 28 Mar 2014 10:14:49 +0000
Subject: [sles-beta] SLES12 x86_64 Beta3 autoyast issue /etc/hosts no
 hostname entry
In-Reply-To: <53354838.604@suse.de>
References: <40637DBB36AF3941B243A286A432CA0B0EFA8953@HXMB12.pnet.ch>
	<53328745.5060006@suse.de>
	<40637DBB36AF3941B243A286A432CA0B0EFA8B2C@HXMB12.pnet.ch>
	<53354838.604@suse.de>
Message-ID: <40637DBB36AF3941B243A286A432CA0B0EFA96AF@HXMB12.pnet.ch>

Hi Marius

Thank you very much
Yes I opened a service request

Service Request  # 10885376321 has been created.  

 SUMMARY OF SR # 10885376321 
  * SR Severity Level: Medium  
  * SR Brief Description: SLES12-Beta3, autoyast not writing IP-address and hostname to /etc/hosts


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 Marius Tomaschewski
Gesendet: Friday, March 28, 2014 11:00 AM
An: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] SLES12 x86_64 Beta3 autoyast issue /etc/hosts no hostname entry

Am 26.03.2014 14:41, schrieb urs.frey at post.ch:
> Hello Marius
>
> Thank you very much!

Hi!

You're welcome!

> I inserted as you told in my autoinst.xml
>      <dns>
>        <dhcp_hostname config:type="boolean">false</dhcp_hostname>
>        <dhcp_resolv config:type="boolean">false</dhcp_resolv>
>        <write_hostname config:type="boolean">true</write_hostname>
>        <domain>pnet.ch</domain>
>        <hostname>h063uz</hostname>
>        <nameservers config:type="list">
>          <nameserver>10.1.121.11</nameserver>
>          <nameserver>10.2.121.11</nameserver>
>        </nameservers>
>        <searchlist config:type="list">
>          <search>pnet.ch</search>
>          <search>post.ch</search>
>        </searchlist>
>      </dns>
>
> But the result is not exactly what I expect. Hostname gets written, but the TCP/IP Address is not the correct one

Ah... the "write_hostname" seems to result in the 127.0.0.2 hack.

Originally intended as fallback to get the hostname resolved when
there is no IP address available on dynamic (ppp,dhcp) links...
and breaking resolving of the hostname completely as it causes to
always resolve the hostname to 127.0.0.2... even the IP is there.
So "write_hostname" seems the wrong way to do it.

>      <host>
>        <hosts config:type="list">
>           <hosts_entry>
>             <host_address>127.0.0.1</host_address>
>             <names config:type="list">
>                <name>localhost</name>
>             </names>
>           </hosts_entry>
>           <hosts_entry>
>             <host_address>10.226.154.19</host_address>
>             <names config:type="list">
>                <name>h063uz.pnet.ch h063uz</name>
>             </names>
>         </hosts>
>      </host>
>
> So from my point of view, there is something wrong with autoyast

Open a bug report for autoyast2. I've no idea about this machinery.

Gruesse / Regards,
  Marius Tomaschewski <mt at suse.de>, <mt at suse.com>
-- 
  SUSE LINUX Products GmbH, HRB 16746 (AG N?rnberg),
  GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer,
  Maxfeldstra?e 5, 90409 N?rnberg, Germany
_______________________________________________
sles-beta mailing list
sles-beta at lists.suse.com
http://lists.suse.com/mailman/listinfo/sles-beta

From gjn at gjn.priv.at  Sun Mar 30 08:43:17 2014
From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer)
Date: Sun, 30 Mar 2014 16:43:17 +0200
Subject: [sles-beta] XEN Installation with (U)EFI
Message-ID: <2910909.FTccLXjxPa@gjn.priv.at>

Hello,

On my system it is not possible to install / start XEN with EFI

I mean the grub2-efi Bug, it is not possible to change the default Boot is 
known, or SR ?

here the default installation is starting with (U)EFI support, but the XEN 
without.

Also I have a bad Problem with my Network when I Install a Virtual System (KVM 
/ XEN) I mean the new wiched have Problems with Bridges. The most time I have 
no Network also some times the Ifconf-brX lost the Port (enp....) 

It is also not possible to config a static Network on installation, also it is 
not possible to change DNS server, when a DHCP Server is found in the 
Background.
 
-- 
mit freundlichen Gr??en / best Regards,

  G?nther J. Niederwimmer