From urs.frey at post.ch  Mon Aug 11 03:44:36 2014
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Mon, 11 Aug 2014 09:44:36 +0000
Subject: [sles-beta] SLES12 RC1 btrfs yast creates empty snapshots
In-Reply-To: <20140811093318.GA15094@suse.de>
References: <40637DBB36AF3941B243A286A432CA0B0F9C7369@HXMB12.pnet.ch>
	<20140811093318.GA15094@suse.de>
Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9C7B9C@HXMB12.pnet.ch>

Hi Arvin

>Yes, the workflow could be improved but this will require hugh
>changes to YaST. 
Thank you very much for your explanation.
I see there are limits and I fully agree.

I could also see, that after some time these empty snapshots get cleaned up

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: Arvin Schnell [mailto:aschnell at suse.de] 
Gesendet: Monday, August 11, 2014 11:33 AM
An: Frey Urs, IT222
Cc: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] SLES12 RC1 btrfs yast creates empty snapshots

On Fri, Aug 08, 2014 at 08:55:07AM +0000, urs.frey at post.ch wrote:
> Hi
> 
> When having SLES12 RC1 x86_64 yast does create empty snapshots
> 
> This is easy to reproduce:
> -       Invoke yast
> -       Goto Software management
> -       Filter patterns
> -       Select "KVM Virtualization"  => +
> -       Cancel Operation => ALT C & ALT Y
> -       Quit
> 
> Now snapper list does show yast sw single snapshots which are empty

> From my point of view the workflow here should be reviewed. Upon cancellation of a yast SW installation no empty snapshots should be generated

> When I do the same operation using zypper, no empty snapshot gets created

Yes, the workflow could be improved but this will require hugh
changes to YaST. While libzypp has a single commit action step
this does not apply to YaST. So currently it is only possible to
create a snapshot before YaST is started and after it has
finished. Even information whether YaST did modify the system is
not available at the end for snapper.

That is also one reason why snapper has a empty-pre-post cleanup
algorithm.

Regards,
  Arvin

-- 
Arvin Schnell, <aschnell at suse.de>
Senior Software Engineer, Research & Development
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg)
Maxfeldstra?e 5
90409 N?rnberg
Germany

From urs.frey at post.ch  Mon Aug 11 04:10:05 2014
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Mon, 11 Aug 2014 10:10:05 +0000
Subject: [sles-beta] SLES12 RC1Question
	concerning	EMPTY_PRE_POST_CLEANUP="yes"
In-Reply-To: <20140811100452.GA19353@suse.de>
References: <40637DBB36AF3941B243A286A432CA0B0F9C7390@HXMB12.pnet.ch>
	<20140811100452.GA19353@suse.de>
Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9C7BC7@HXMB12.pnet.ch>

Hi Arvin

Thank you for your post.

>Also, per default the cleanup algorithms only delete snapshots
>which are at least 30 minutes old.
>
>So on average empty pre-post snapshots are deleted after half a
>day, but it can take upto one day and 30 minutes.
>
>As you already wrote in a reply to my previous mail the snapshots
>are deleted after some time so everything looks OK.
I was looking to get an information telling me more about the delay to clean up empty pre-post snapshots
So even in the manpage there was nothing.

I think it could be helpful to better understanding if there were a bit more details in some documentation of manpage

Thank you very much

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: Arvin Schnell [mailto:aschnell at suse.de] 
Gesendet: Monday, August 11, 2014 12:05 PM
An: Frey Urs, IT222
Cc: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] SLES12 RC1Question concerning EMPTY_PRE_POST_CLEANUP="yes"

On Fri, Aug 08, 2014 at 09:14:42AM +0000, urs.frey at post.ch wrote:
> Hi
> When using SLES12 with btrfs I can see in /etc/snapper/configs/root the parameter EMPTY_PRE_POST_CLEANUP="yes" enabled.
> 
> I am googling, but can not find when, after which time these empty pre-post snapshots get cleaned from my server.
> I can only learn that there are three algorithms for cleanup in the cron job of snapper
> Number, Timeline, empty-pre-post

The snapper manpage mentions that the cleanup algorithms are
executed in a daily cron-job. When the daily cron-job is executed
depends on the cron configuration.

Also, per default the cleanup algorithms only delete snapshots
which are at least 30 minutes old.

So on average empty pre-post snapshots are deleted after half a
day, but it can take upto one day and 30 minutes.

As you already wrote in a reply to my previous mail the snapshots
are deleted after some time so everything looks OK.

Regards,
  Arvin

-- 
Arvin Schnell, <aschnell at suse.de>
Senior Software Engineer, Research & Development
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg)
Maxfeldstra?e 5
90409 N?rnberg
Germany

From ronny.pretzsch at dfs.de  Mon Aug 11 04:47:28 2014
From: ronny.pretzsch at dfs.de (Ronny Pretzsch)
Date: Mon, 11 Aug 2014 12:47:28 +0200
Subject: [sles-beta] RC1 NRPE Package (nagios)
In-Reply-To: <20140808123616.GA24665@suse.com>
References: <1407321611.7092.12.camel@ronnylinux.prod.bk.dfs>
	<20140806111453.GA14801@suse.de>
	<1407415729.26168.5.camel@ronnylinux.prod.bk.dfs>
	<20140807125545.GA4404@suse.de> <53E37AF0.8090705@ucs.cam.ac.uk>
	<1407499597.25813.10.camel@ronnylinux.prod.bk.dfs>
	<20140808123616.GA24665@suse.com>
Message-ID: <1407754048.7120.6.camel@ronnylinux.prod.bk.dfs>

Hello,

> > Thus the question if the nrpe daemon (nrpe tcp-server)
> > is going to be included in any SLE12 product.
> 
> Similar to the nagios-plugins (which have been renamed to
> monitoring-plugins), the nrpe stuff will be renamed to
> monitoring*nrpe-*.

This is not the answer to my question!
Again: Will the nrpe tcp-server (/usr/bin/nrpe) be included
in SLE12 or do I have to get it from some place else (e.g.
buildservice)?


> > In the latter case I wonder why, as the client alone
> > does not help anyone. It's the nrpe server that has to
> > be installed on every system to be monitored.
>  
> Unfortunately both nrpe packages where missing in SUSE
> Linux Enterprise Server 12 RC1, they should become
> available again in RC2.

The statement "should" is not helpful.
WILL it? An will it in RC3 ... Golden ... Release?

Ronny Pretzsch


DFS Deutsche Flugsicherung GmbH
Am DFS-Campus
D - 63225 Langen

Tel.: +49-(0)6103-707-0

Sitz der Gesellschaft: Langen/Hessen
Zust?ndiges Registergericht: AG Offenbach am Main, HRB 34977
Vorsitzender des Aufsichtsrates: Michael Odenwald
Gesch?ftsf?hrer: Prof. Klaus-Dieter Scheurle (Vors.), Robert Schickling, Dr. Michael Hann

Internet: http://www.dfs.de
Public-Key der DFS: http://www.dfs.de/dfs/public_key.asc <http://www.dfs.de/dfs/public_key.asc>

From gjn at gjn.priv.at  Mon Aug 11 07:09:39 2014
From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer)
Date: Mon, 11 Aug 2014 15:09:39 +0200
Subject: [sles-beta] Big Ldap Problem
Message-ID: <4389226.7nn1APZf6u@gjn.priv.at>

Hello,

can any test or have test to change the ldap config for a working Mirror Setup.

On my system I can change with ldapmodify "dn: cn=config, dn: 
Database={0}config,cn=config" 

But not cn: olcDatabase={1}hdb,cn=config

Is this my mistake or a Bug?

Thank you for a answer, 

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

  G?nther J. Niederwimmer

From dvosburg at suse.com  Mon Aug 11 07:27:32 2014
From: dvosburg at suse.com (Donald Vosburg)
Date: Mon, 11 Aug 2014 07:27:32 -0600
Subject: [sles-beta] Big Ldap Problem
In-Reply-To: <4389226.7nn1APZf6u@gjn.priv.at>
References: <4389226.7nn1APZf6u@gjn.priv.at>
Message-ID: <53E87073020000C200153EDA@prv-mh.provo.novell.com>

Did you set separate credentials for the cn=config database?  Try looking at what the yast LDAP server module shows.

Sent from my iPhone

> On Aug 11, 2014, at 9:09 AM, "G?nther J.Niederwimmer" <gjn at gjn.priv.at> wrote:
> 
> Hello,
> 
> can any test or have test to change the ldap config for a working Mirror Setup.
> 
> On my system I can change with ldapmodify "dn: cn=config, dn: 
> Database={0}config,cn=config" 
> 
> But not cn: olcDatabase={1}hdb,cn=config
> 
> Is this my mistake or a Bug?
> 
> Thank you for a answer, 
> 
> -- 
> mit freundlichen Gr??en / best Regards,
> 
>  G?nther J. Niederwimmer
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta


From gjn at gjn.priv.at  Mon Aug 11 07:59:07 2014
From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer)
Date: Mon, 11 Aug 2014 15:59:07 +0200
Subject: [sles-beta] Big Ldap Problem
In-Reply-To: <53E87073020000C200153EDA@prv-mh.provo.novell.com>
References: <4389226.7nn1APZf6u@gjn.priv.at>
	<53E87073020000C200153EDA@prv-mh.provo.novell.com>
Message-ID: <1471624.DBGJMWmFe3@gjn.priv.at>

Hello,

Am Montag, 11. August 2014, 07:27:32 schrieb Donald Vosburg:
> Did you set separate credentials for the cn=config database?  Try looking at
> what the yast LDAP server module shows.
> 
> Sent from my iPhone
;)

No is a original YaST Ldap Master Installation.

this is the output from ldapmodify

modifying entry "cn=config"

modifying entry "olcDatabase={0}config,cn=config"

modifying entry "olcDatabase={1}mdb,cn=config"
ldap_modify: Other (e.g., implementation specific) error (80)
        additional info: Base DN "cn=config" is not within the database naming 
context

for Info the *.ldif is attached
  
> > On Aug 11, 2014, at 9:09 AM, "G?nther J.Niederwimmer" <gjn at gjn.priv.at>
> > wrote:
> > 
> > Hello,
> > 
> > can any test or have test to change the ldap config for a working Mirror
> > Setup.
> > 
> > On my system I can change with ldapmodify "dn: cn=config, dn:
> > Database={0}config,cn=config"
> > 
> > But not cn: olcDatabase={1}hdb,cn=config
> > 
> > Is this my mistake or a Bug?
> > 
> > Thank you for a answer,
> 
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta

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

  G?nther J. Niederwimmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldap.ldif
Type: text/x-ldif
Size: 1559 bytes
Desc: not available
URL: <http://lists.suse.com/mailman/private/sles-beta/attachments/20140811/c467435c/attachment.bin>

From aschnell at suse.de  Mon Aug 11 03:33:18 2014
From: aschnell at suse.de (Arvin Schnell)
Date: Mon, 11 Aug 2014 11:33:18 +0200
Subject: [sles-beta] SLES12 RC1 btrfs yast creates empty snapshots
In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9C7369@HXMB12.pnet.ch>
References: <40637DBB36AF3941B243A286A432CA0B0F9C7369@HXMB12.pnet.ch>
Message-ID: <20140811093318.GA15094@suse.de>

On Fri, Aug 08, 2014 at 08:55:07AM +0000, urs.frey at post.ch wrote:
> Hi
> 
> When having SLES12 RC1 x86_64 yast does create empty snapshots
> 
> This is easy to reproduce:
> -       Invoke yast
> -       Goto Software management
> -       Filter patterns
> -       Select "KVM Virtualization"  => +
> -       Cancel Operation => ALT C & ALT Y
> -       Quit
> 
> Now snapper list does show yast sw single snapshots which are empty

> From my point of view the workflow here should be reviewed. Upon cancellation of a yast SW installation no empty snapshots should be generated

> When I do the same operation using zypper, no empty snapshot gets created

Yes, the workflow could be improved but this will require hugh
changes to YaST. While libzypp has a single commit action step
this does not apply to YaST. So currently it is only possible to
create a snapshot before YaST is started and after it has
finished. Even information whether YaST did modify the system is
not available at the end for snapper.

That is also one reason why snapper has a empty-pre-post cleanup
algorithm.

Regards,
  Arvin

-- 
Arvin Schnell, <aschnell at suse.de>
Senior Software Engineer, Research & Development
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg)
Maxfeldstra?e 5
90409 N?rnberg
Germany

From aschnell at suse.de  Mon Aug 11 04:04:52 2014
From: aschnell at suse.de (Arvin Schnell)
Date: Mon, 11 Aug 2014 12:04:52 +0200
Subject: [sles-beta] SLES12 RC1Question
	concerning	EMPTY_PRE_POST_CLEANUP="yes"
In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9C7390@HXMB12.pnet.ch>
References: <40637DBB36AF3941B243A286A432CA0B0F9C7390@HXMB12.pnet.ch>
Message-ID: <20140811100452.GA19353@suse.de>

On Fri, Aug 08, 2014 at 09:14:42AM +0000, urs.frey at post.ch wrote:
> Hi
> When using SLES12 with btrfs I can see in /etc/snapper/configs/root the parameter EMPTY_PRE_POST_CLEANUP="yes" enabled.
> 
> I am googling, but can not find when, after which time these empty pre-post snapshots get cleaned from my server.
> I can only learn that there are three algorithms for cleanup in the cron job of snapper
> Number, Timeline, empty-pre-post

The snapper manpage mentions that the cleanup algorithms are
executed in a daily cron-job. When the daily cron-job is executed
depends on the cron configuration.

Also, per default the cleanup algorithms only delete snapshots
which are at least 30 minutes old.

So on average empty pre-post snapshots are deleted after half a
day, but it can take upto one day and 30 minutes.

As you already wrote in a reply to my previous mail the snapshots
are deleted after some time so everything looks OK.

Regards,
  Arvin

-- 
Arvin Schnell, <aschnell at suse.de>
Senior Software Engineer, Research & Development
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg)
Maxfeldstra?e 5
90409 N?rnberg
Germany

From aschnell at suse.de  Mon Aug 11 04:21:10 2014
From: aschnell at suse.de (Arvin Schnell)
Date: Mon, 11 Aug 2014 12:21:10 +0200
Subject: [sles-beta] SLES12 RC1Question
	concerning	EMPTY_PRE_POST_CLEANUP="yes"
In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9C7BC7@HXMB12.pnet.ch>
References: <40637DBB36AF3941B243A286A432CA0B0F9C7390@HXMB12.pnet.ch>
	<20140811100452.GA19353@suse.de>
	<40637DBB36AF3941B243A286A432CA0B0F9C7BC7@HXMB12.pnet.ch>
Message-ID: <20140811102110.GA21678@suse.de>

On Mon, Aug 11, 2014 at 10:10:05AM +0000, urs.frey at post.ch wrote:
> Hi Arvin
> 
> Thank you for your post.
> 
> >Also, per default the cleanup algorithms only delete snapshots
> >which are at least 30 minutes old.
> >
> >So on average empty pre-post snapshots are deleted after half a
> >day, but it can take upto one day and 30 minutes.
> >
> >As you already wrote in a reply to my previous mail the snapshots
> >are deleted after some time so everything looks OK.
> I was looking to get an information telling me more about the delay to clean up empty pre-post snapshots
> So even in the manpage there was nothing.

This is explained in the snapper-configs(5) manpage (which is
referenced from snapper(8)). Those are also available on
the snapper homepage:

  http://snapper.io/documentation.html

Regards,
  Arvin

-- 
Arvin Schnell, <aschnell at suse.de>
Senior Software Engineer, Research & Development
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg)
Maxfeldstra?e 5
90409 N?rnberg
Germany

From darrent at akurit.com.au  Mon Aug 11 15:11:42 2014
From: darrent at akurit.com.au (Darren Thompson)
Date: Tue, 12 Aug 2014 07:11:42 +1000
Subject: [sles-beta] Fwd: [opensuse-factory] Re: grub2: booting from btrfs
	snapshots
In-Reply-To: <CAAq0jx+hP-ATt+b7G+cK241zpFmacQdznnfdvYm4rOyZZs=umQ@mail.gmail.com>
References: <ls5mkc$e66$1@ger.gmane.org>
	<20140809215129.673fefc9@opensuse.site>
	<ls5pj4$fqd$1@ger.gmane.org> <ls5qcd$mkt$1@ger.gmane.org>
	<20140811080645.GA8375@suse.com>
	<CAAq0jx+hP-ATt+b7G+cK241zpFmacQdznnfdvYm4rOyZZs=umQ@mail.gmail.com>
Message-ID: <CAEUhfEcH2xuF4u36gJbnww59o-OETfBGdw8HZtme_s67p4584A@mail.gmail.com>

Team

I was wondering how this was supposed to work for a "full rollback"

I saw this summary and thought it was useful to forward here...

Darren
---------- Forwarded message ----------
From: Matthias G. Eckermann <mge at suse.com>
Date: Mon, Aug 11, 2014 at 6:06 PM
Subject: Re: [opensuse-factory] Re: grub2: booting from btrfs snapshots
To: "Matwey V. Kornilov" <matwey.kornilov at gmail.com>,
opensuse-factory at opensuse.org


Hello Matwey and all,

On 2014-08-09 T 22:47 +0400 Matwey V. Kornilov wrote:
> 09.08.2014 22:34, Matwey V. Kornilov ?????:
> > 09.08.2014 21:51, Andrey Borzenkov ?????:
> >>
> >> There were quite a number of commits to support
> >> booting from btrfs snapshots. So I assume this
> >> should work, at least under some restrictions.
> >
> > Just installed 13.2, there are grub2-snapper-plugin
> > package, but it doesn't work out of the box. Trying
> > to understand what is to do with it.
>
> Ok. Get it working. When I boot into the snapshot,
> the / seems to be mounted as ro, and the OS is almost
> not working. Is it supposed to be so?

Yes. -- Booting from a snapshot can be used in two ways:

1. You chose a RO Snapshot in the Grub2 menu. In this
   case you will boot into a RO Snapshot, and you
   should  be able to work in this system. If you want
   to stay in this "state", you will have to copy the
   RO Snapshot into a RW, reboot and work from it.

   Sounds complex!? Maybe, but there is a reason for this:
   The assumption is that the majority of people will
   use RO Snapshots as "well known states" into which
   they want to jump back in case of emergency.
   If we would boot into such a snapshot "RW", the
   state would be changed, would not be "well known"
   anymore. In other words, it would be a "one time
   use well known state". Not very helpful, ...
   For that reason, booting into "RO" and changing to
   RW afterwards is a right way, as it preserves the
   "well known state" in the RO snapshot.

   The perfect solution would be, if Grub2 would be
   able to clone the (existing) RO into a (new) RW
   btrfs snapshot. But I don't know if it is even
   possible to implement this into Grub2.

2. If you are in a running system, you can chose:
        "snapper rollback <number>",
   reboot,
   and you are in a RW copy of <number>.

Hope this explains (a bit).

so long -
        MgE


--
Matthias G. Eckermann     Senior Product Manager   SUSE? Linux Enterprise
SUSE LINUX Products GmbH  Maxfeldstra?e 5          90409 N?rnberg Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg)
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe at opensuse.org
To contact the owner, e-mail: opensuse-factory+owner at opensuse.org





-- 

Darren Thompson

Professional Services Engineer / Consultant

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

Level 3, 60 City Road

Southgate, VIC 3006

Mb: 0400 640 414

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

From jreidinger at suse.com  Tue Aug 12 00:14:34 2014
From: jreidinger at suse.com (Josef Reidinger)
Date: Tue, 12 Aug 2014 08:14:34 +0200
Subject: [sles-beta] SLES12 RC1 SUSEConnect distingush between virtiual
 and physical server?
In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9C8C05@HXMB12.pnet.ch>
References: <40637DBB36AF3941B243A286A432CA0B0F9C8C05@HXMB12.pnet.ch>
Message-ID: <20140812081434.7280460d@dhcp150.suse.cz>

On Mon, 11 Aug 2014 16:55:47 +0000
<urs.frey at post.ch> wrote:

> Hi
> 
> I finally found an old note of mine showing me, that once in SLES12
> beta6 the
> file /usr/lib64/ruby/gems/2.0.0/gems/suse-connect-0.0.17/lib/suse/connect/system.rb,
> there was this sequence to distinguish between virtual and physical
> installation when registering.
> 
> Within the file
> /usr/lib64/ruby/gems/2.0.0/gems/suse-connect-0.0.17/lib/suse/connect/system.rb
> I can see this sequence
> 
> module SUSE
>   module Connect
>     # System class allowing to interact with underlying system
>     class System
> 
>       class << self
> 
>         def hwinfo
>           info = {
>             :cpu_type       => `uname -p`,
>             :cpu_count      => `grep "processor" /proc/cpuinfo | wc
> -l`, :platform_type  => `uname -i`,
>             :hostname       => `hostname`
>           }
> 
>           info.values.each(&:chomp!)
>           dmidecode = `dmidecode`
>           virt_zoo = ['vmware', 'virtual machine', 'qemu', 'domu']
>           info[:virtualized] = (virt_zoo).any? {|ident|
> dmidecode.downcase.include? ident } if dmidecode info
>         end
> 
>         # returns username and password from SCC_CREDENTIALS_FILE
> 
> So dmidecode is used to detect a virtual machine
> 
> 
> Now with SLES12 RC1 this sequence has gone, there are some hypervisor
> definitions now
> 
> h05cnh:~ #
> cat /usr/lib64/ruby/gems/2.1.0/gems/suse-connect-0.2.7/lib/suse/connect/system.rb
> require 'suse/toolkit/hwinfo'
> 
> module SUSE
>   module Connect
>     # System class allowing to interact with underlying system
>     class System
>       class << self
> 
>         include SUSE::Toolkit::Hwinfo
> 
>         attr_accessor :filesystem_root
> 
>         def prefix_path(path)
>           filesystem_root ? File.join(filesystem_root, path) : path
>         end
> 
>         def hwinfo
>           if x86?
>             {
>               hostname: hostname,
>               cpus: cpus,
>               sockets: sockets,
>               hypervisor: hypervisor,
>               arch: arch,
>               uuid: uuid
>             }
>           else
>             {
>               hostname: hostname,
>               arch: arch
>             }
>           end
>         end
> 
> From the toolkit hwinfo,rb I can see some Hypervisor definitions
> h05cnh:~ #
> cat /usr/lib64/ruby/gems/2.1.0/gems/suse-connect-0.2.7/lib/suse/toolkit/hwinfo.rb
> require 'suse/toolkit/system_calls'
> 
> # Collects system hardware information
> module SUSE::Toolkit::Hwinfo
> 
>   include SUSE::Toolkit::SystemCalls
> 
>   def cpus
>     output['CPU(s)'].to_i
>   end
> 
>   def sockets
>     output['Socket(s)'].to_i
>   end
> 
>   def hypervisor
>     output['Hypervisor vendor']
>   end
> 
> Can somebody please show me, how now SUSEConnect can distinguish
> between a HP-ProLiant Server, a XEN client, a KVM client and a VMWare
> ESXi client. It is really of interest to see how it is done.
> ( Believing is one thing. But understanding the process gives me
> confidence. )
> 
> Thank you very much, indeed
> 
> Best regards
> 
> 

Hi Urs,
I check current code on github and it uses now lscpu call -
https://github.com/SUSE/connect/blob/master/lib/suse/connect/hwinfo/x86.rb#L45
from which it create pairs of keys and values. and there should by
Hypervisor vendor key.

Josef

From urs.frey at post.ch  Tue Aug 12 02:06:25 2014
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Tue, 12 Aug 2014 08:06:25 +0000
Subject: [sles-beta] SLES12 RC1 SUSEConnect distingush between virtiual
 and physical server?
In-Reply-To: <20140812081434.7280460d@dhcp150.suse.cz>
References: <40637DBB36AF3941B243A286A432CA0B0F9C8C05@HXMB12.pnet.ch>
	<20140812081434.7280460d@dhcp150.suse.cz>
Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9C8C7F@HXMB12.pnet.ch>

Hello Josef

OK, thank you very much!
I see:
In fact you are doing nothing other than

  def hypervisor
    output['Hypervisor vendor']
  end

  def output
    @output ||= execute('lscpu', false).split("\n").reduce({}) do |hash, line|
      k, v = line.split(':')
      hash[k] = v.strip
      hash
    end
  end

Which is in bash shell:

KVM:
=====
h05cnh:~ # lscpu | grep "Hypervisor vendor"| cut -d":" -f2 | awk '{print $1}'
KVM
h05cnh:~ #


VMware ESXi
==========
v03er9:~ # lscpu| grep "Hypervisor vendor"| cut -d":" -f2 | awk '{print $1}'
VMware
v03er9:~ #

HP ProLiant
=========
h05cni:~ # lscpu| grep "Hypervisor vendor"| cut -d":" -f2 | awk '{print $1}'
h05cni:~ #


And therefore if "Hypervisor vendor" Output has some value, you know : "This is a virtual machine installation"

Is this correct?

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: Josef Reidinger [mailto:jreidinger at suse.com] 
Gesendet: Tuesday, August 12, 2014 8:15 AM
An: sles-beta at lists.suse.com
Cc: Frey Urs, IT222
Betreff: Re: [sles-beta] SLES12 RC1 SUSEConnect distingush between virtiual and physical server?

On Mon, 11 Aug 2014 16:55:47 +0000
<urs.frey at post.ch> wrote:

> Hi
> 
> I finally found an old note of mine showing me, that once in SLES12
> beta6 the
> file /usr/lib64/ruby/gems/2.0.0/gems/suse-connect-0.0.17/lib/suse/connect/system.rb,
> there was this sequence to distinguish between virtual and physical
> installation when registering.
> 
> Within the file
> /usr/lib64/ruby/gems/2.0.0/gems/suse-connect-0.0.17/lib/suse/connect/system.rb
> I can see this sequence
> 
> module SUSE
>   module Connect
>     # System class allowing to interact with underlying system
>     class System
> 
>       class << self
> 
>         def hwinfo
>           info = {
>             :cpu_type       => `uname -p`,
>             :cpu_count      => `grep "processor" /proc/cpuinfo | wc
> -l`, :platform_type  => `uname -i`,
>             :hostname       => `hostname`
>           }
> 
>           info.values.each(&:chomp!)
>           dmidecode = `dmidecode`
>           virt_zoo = ['vmware', 'virtual machine', 'qemu', 'domu']
>           info[:virtualized] = (virt_zoo).any? {|ident|
> dmidecode.downcase.include? ident } if dmidecode info
>         end
> 
>         # returns username and password from SCC_CREDENTIALS_FILE
> 
> So dmidecode is used to detect a virtual machine
> 
> 
> Now with SLES12 RC1 this sequence has gone, there are some hypervisor
> definitions now
> 
> h05cnh:~ #
> cat /usr/lib64/ruby/gems/2.1.0/gems/suse-connect-0.2.7/lib/suse/connect/system.rb
> require 'suse/toolkit/hwinfo'
> 
> module SUSE
>   module Connect
>     # System class allowing to interact with underlying system
>     class System
>       class << self
> 
>         include SUSE::Toolkit::Hwinfo
> 
>         attr_accessor :filesystem_root
> 
>         def prefix_path(path)
>           filesystem_root ? File.join(filesystem_root, path) : path
>         end
> 
>         def hwinfo
>           if x86?
>             {
>               hostname: hostname,
>               cpus: cpus,
>               sockets: sockets,
>               hypervisor: hypervisor,
>               arch: arch,
>               uuid: uuid
>             }
>           else
>             {
>               hostname: hostname,
>               arch: arch
>             }
>           end
>         end
> 
> From the toolkit hwinfo,rb I can see some Hypervisor definitions
> h05cnh:~ #
> cat /usr/lib64/ruby/gems/2.1.0/gems/suse-connect-0.2.7/lib/suse/toolkit/hwinfo.rb
> require 'suse/toolkit/system_calls'
> 
> # Collects system hardware information
> module SUSE::Toolkit::Hwinfo
> 
>   include SUSE::Toolkit::SystemCalls
> 
>   def cpus
>     output['CPU(s)'].to_i
>   end
> 
>   def sockets
>     output['Socket(s)'].to_i
>   end
> 
>   def hypervisor
>     output['Hypervisor vendor']
>   end
> 
> Can somebody please show me, how now SUSEConnect can distinguish
> between a HP-ProLiant Server, a XEN client, a KVM client and a VMWare
> ESXi client. It is really of interest to see how it is done.
> ( Believing is one thing. But understanding the process gives me
> confidence. )
> 
> Thank you very much, indeed
> 
> Best regards
> 
> 

Hi Urs,
I check current code on github and it uses now lscpu call -
https://github.com/SUSE/connect/blob/master/lib/suse/connect/hwinfo/x86.rb#L45
from which it create pairs of keys and values. and there should by
Hypervisor vendor key.

Josef

From martin.wilck at ts.fujitsu.com  Tue Aug 12 03:14:38 2014
From: martin.wilck at ts.fujitsu.com (Martin Wilck)
Date: Tue, 12 Aug 2014 11:14:38 +0200
Subject: [sles-beta] strange values for crashkernel= after RC1 installation
Message-ID: <53E9DAFE.9040809@ts.fujitsu.com>

We are seeing kdump failures (OOM killer in kdump environment) on
various systems. This seems to be due to strange values for crashkernel=

1 system with 32GB RAM:  crashkernel=182M-:91M
1 system with 96GB RAM:  crashkernel=192M-:96M

Whatever algorithm is used here, the outcome seems to be strange.
For a system with only 192M RAM, 91M crashkernel would be a *lot*. For
today's typical server it is too little.

Surely this can be fixed by hand-editing crashkernel=, but maybe SUSE
should check the algorithm for the default value once again.

Martin

-- 
Dr. Martin Wilck
PRIMERGY System Software Engineer
x86 Server Engineering

FUJITSU
Fujitsu Technology Solutions GmbH
Heinz-Nixdorf-Ring 1
33106 Paderborn, Germany
Phone:			++49 5251 525 2796
Fax:			++49 5251 525 2820
Email:			martin.wilck at ts.fujitsu.com
Internet:		http://ts.fujitsu.com
Company Details:	http://ts.fujitsu.com/imprint

From darrent at akurit.com.au  Tue Aug 12 05:10:44 2014
From: darrent at akurit.com.au (Darren Thompson (AkurIT))
Date: Tue, 12 Aug 2014 21:10:44 +1000
Subject: [sles-beta] SLES12 RC1 SUSEConnect distingush between virtiual
	and physical server?
In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9C8C7F@HXMB12.pnet.ch>
References: <40637DBB36AF3941B243A286A432CA0B0F9C8C05@HXMB12.pnet.ch>
	<20140812081434.7280460d@dhcp150.suse.cz>
	<40637DBB36AF3941B243A286A432CA0B0F9C8C7F@HXMB12.pnet.ch>
Message-ID: <4941C076-1A1E-4516-BC1C-FD7D5BFE4E40@akurit.com.au>

Is it worth me running the same shell script on a XEN host to. Compare the output?

On 12/08/2014, at 18:06, <urs.frey at post.ch> wrote:

> Hello Josef
> 
> OK, thank you very much!
> I see:
> In fact you are doing nothing other than
> 
>  def hypervisor
>    output['Hypervisor vendor']
>  end
> 
>  def output
>    @output ||= execute('lscpu', false).split("\n").reduce({}) do |hash, line|
>      k, v = line.split(':')
>      hash[k] = v.strip
>      hash
>    end
>  end
> 
> Which is in bash shell:
> 
> KVM:
> =====
> h05cnh:~ # lscpu | grep "Hypervisor vendor"| cut -d":" -f2 | awk '{print $1}'
> KVM
> h05cnh:~ #
> 
> 
> VMware ESXi
> ==========
> v03er9:~ # lscpu| grep "Hypervisor vendor"| cut -d":" -f2 | awk '{print $1}'
> VMware
> v03er9:~ #
> 
> HP ProLiant
> =========
> h05cni:~ # lscpu| grep "Hypervisor vendor"| cut -d":" -f2 | awk '{print $1}'
> h05cni:~ #
> 
> 
> And therefore if "Hypervisor vendor" Output has some value, you know : "This is a virtual machine installation"
> 
> Is this correct?
> 
> 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: Josef Reidinger [mailto:jreidinger at suse.com] 
> Gesendet: Tuesday, August 12, 2014 8:15 AM
> An: sles-beta at lists.suse.com
> Cc: Frey Urs, IT222
> Betreff: Re: [sles-beta] SLES12 RC1 SUSEConnect distingush between virtiual and physical server?
> 
> On Mon, 11 Aug 2014 16:55:47 +0000
> <urs.frey at post.ch> wrote:
> 
>> Hi
>> 
>> I finally found an old note of mine showing me, that once in SLES12
>> beta6 the
>> file /usr/lib64/ruby/gems/2.0.0/gems/suse-connect-0.0.17/lib/suse/connect/system.rb,
>> there was this sequence to distinguish between virtual and physical
>> installation when registering.
>> 
>> Within the file
>> /usr/lib64/ruby/gems/2.0.0/gems/suse-connect-0.0.17/lib/suse/connect/system.rb
>> I can see this sequence
>> 
>> module SUSE
>>  module Connect
>>    # System class allowing to interact with underlying system
>>    class System
>> 
>>      class << self
>> 
>>        def hwinfo
>>          info = {
>>            :cpu_type       => `uname -p`,
>>            :cpu_count      => `grep "processor" /proc/cpuinfo | wc
>> -l`, :platform_type  => `uname -i`,
>>            :hostname       => `hostname`
>>          }
>> 
>>          info.values.each(&:chomp!)
>>          dmidecode = `dmidecode`
>>          virt_zoo = ['vmware', 'virtual machine', 'qemu', 'domu']
>>          info[:virtualized] = (virt_zoo).any? {|ident|
>> dmidecode.downcase.include? ident } if dmidecode info
>>        end
>> 
>>        # returns username and password from SCC_CREDENTIALS_FILE
>> 
>> So dmidecode is used to detect a virtual machine
>> 
>> 
>> Now with SLES12 RC1 this sequence has gone, there are some hypervisor
>> definitions now
>> 
>> h05cnh:~ #
>> cat /usr/lib64/ruby/gems/2.1.0/gems/suse-connect-0.2.7/lib/suse/connect/system.rb
>> require 'suse/toolkit/hwinfo'
>> 
>> module SUSE
>>  module Connect
>>    # System class allowing to interact with underlying system
>>    class System
>>      class << self
>> 
>>        include SUSE::Toolkit::Hwinfo
>> 
>>        attr_accessor :filesystem_root
>> 
>>        def prefix_path(path)
>>          filesystem_root ? File.join(filesystem_root, path) : path
>>        end
>> 
>>        def hwinfo
>>          if x86?
>>            {
>>              hostname: hostname,
>>              cpus: cpus,
>>              sockets: sockets,
>>              hypervisor: hypervisor,
>>              arch: arch,
>>              uuid: uuid
>>            }
>>          else
>>            {
>>              hostname: hostname,
>>              arch: arch
>>            }
>>          end
>>        end
>> 
>> From the toolkit hwinfo,rb I can see some Hypervisor definitions
>> h05cnh:~ #
>> cat /usr/lib64/ruby/gems/2.1.0/gems/suse-connect-0.2.7/lib/suse/toolkit/hwinfo.rb
>> require 'suse/toolkit/system_calls'
>> 
>> # Collects system hardware information
>> module SUSE::Toolkit::Hwinfo
>> 
>>  include SUSE::Toolkit::SystemCalls
>> 
>>  def cpus
>>    output['CPU(s)'].to_i
>>  end
>> 
>>  def sockets
>>    output['Socket(s)'].to_i
>>  end
>> 
>>  def hypervisor
>>    output['Hypervisor vendor']
>>  end
>> 
>> Can somebody please show me, how now SUSEConnect can distinguish
>> between a HP-ProLiant Server, a XEN client, a KVM client and a VMWare
>> ESXi client. It is really of interest to see how it is done.
>> ( Believing is one thing. But understanding the process gives me
>> confidence. )
>> 
>> Thank you very much, indeed
>> 
>> Best regards
> 
> Hi Urs,
> I check current code on github and it uses now lscpu call -
> https://github.com/SUSE/connect/blob/master/lib/suse/connect/hwinfo/x86.rb#L45
> from which it create pairs of keys and values. and there should by
> Hypervisor vendor key.
> 
> Josef
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta

From urs.frey at post.ch  Tue Aug 12 05:38:00 2014
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Tue, 12 Aug 2014 11:38:00 +0000
Subject: [sles-beta] SLES12 RC1 SUSEConnect distingush between virtiual
 and physical server?
In-Reply-To: <4941C076-1A1E-4516-BC1C-FD7D5BFE4E40@akurit.com.au>
References: <40637DBB36AF3941B243A286A432CA0B0F9C8C05@HXMB12.pnet.ch>
	<20140812081434.7280460d@dhcp150.suse.cz>
	<40637DBB36AF3941B243A286A432CA0B0F9C8C7F@HXMB12.pnet.ch>
	<4941C076-1A1E-4516-BC1C-FD7D5BFE4E40@akurit.com.au>
Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9C8CFA@HXMB12.pnet.ch>

Hi Darren
It is up to you to decide how deep you want to go with your tests and try to understand the process of SUSEConnect

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: Darren Thompson (AkurIT) [mailto:darrent at akurit.com.au] 
Gesendet: Tuesday, August 12, 2014 1:11 PM
An: Frey Urs, IT222
Cc: <jreidinger at suse.com>; <sles-beta at lists.suse.com>
Betreff: Re: [sles-beta] SLES12 RC1 SUSEConnect distingush between virtiual and physical server?

Is it worth me running the same shell script on a XEN host to. Compare the output?

On 12/08/2014, at 18:06, <urs.frey at post.ch> wrote:

> Hello Josef
> 
> OK, thank you very much!
> I see:
> In fact you are doing nothing other than
> 
>  def hypervisor
>    output['Hypervisor vendor']
>  end
> 
>  def output
>    @output ||= execute('lscpu', false).split("\n").reduce({}) do |hash, line|
>      k, v = line.split(':')
>      hash[k] = v.strip
>      hash
>    end
>  end
> 
> Which is in bash shell:
> 
> KVM:
> =====
> h05cnh:~ # lscpu | grep "Hypervisor vendor"| cut -d":" -f2 | awk '{print $1}'
> KVM
> h05cnh:~ #
> 
> 
> VMware ESXi
> ==========
> v03er9:~ # lscpu| grep "Hypervisor vendor"| cut -d":" -f2 | awk '{print $1}'
> VMware
> v03er9:~ #
> 
> HP ProLiant
> =========
> h05cni:~ # lscpu| grep "Hypervisor vendor"| cut -d":" -f2 | awk '{print $1}'
> h05cni:~ #
> 
> 
> And therefore if "Hypervisor vendor" Output has some value, you know : "This is a virtual machine installation"
> 
> Is this correct?
> 
> 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: Josef Reidinger [mailto:jreidinger at suse.com] 
> Gesendet: Tuesday, August 12, 2014 8:15 AM
> An: sles-beta at lists.suse.com
> Cc: Frey Urs, IT222
> Betreff: Re: [sles-beta] SLES12 RC1 SUSEConnect distingush between virtiual and physical server?
> 
> On Mon, 11 Aug 2014 16:55:47 +0000
> <urs.frey at post.ch> wrote:
> 
>> Hi
>> 
>> I finally found an old note of mine showing me, that once in SLES12
>> beta6 the
>> file /usr/lib64/ruby/gems/2.0.0/gems/suse-connect-0.0.17/lib/suse/connect/system.rb,
>> there was this sequence to distinguish between virtual and physical
>> installation when registering.
>> 
>> Within the file
>> /usr/lib64/ruby/gems/2.0.0/gems/suse-connect-0.0.17/lib/suse/connect/system.rb
>> I can see this sequence
>> 
>> module SUSE
>>  module Connect
>>    # System class allowing to interact with underlying system
>>    class System
>> 
>>      class << self
>> 
>>        def hwinfo
>>          info = {
>>            :cpu_type       => `uname -p`,
>>            :cpu_count      => `grep "processor" /proc/cpuinfo | wc
>> -l`, :platform_type  => `uname -i`,
>>            :hostname       => `hostname`
>>          }
>> 
>>          info.values.each(&:chomp!)
>>          dmidecode = `dmidecode`
>>          virt_zoo = ['vmware', 'virtual machine', 'qemu', 'domu']
>>          info[:virtualized] = (virt_zoo).any? {|ident|
>> dmidecode.downcase.include? ident } if dmidecode info
>>        end
>> 
>>        # returns username and password from SCC_CREDENTIALS_FILE
>> 
>> So dmidecode is used to detect a virtual machine
>> 
>> 
>> Now with SLES12 RC1 this sequence has gone, there are some hypervisor
>> definitions now
>> 
>> h05cnh:~ #
>> cat /usr/lib64/ruby/gems/2.1.0/gems/suse-connect-0.2.7/lib/suse/connect/system.rb
>> require 'suse/toolkit/hwinfo'
>> 
>> module SUSE
>>  module Connect
>>    # System class allowing to interact with underlying system
>>    class System
>>      class << self
>> 
>>        include SUSE::Toolkit::Hwinfo
>> 
>>        attr_accessor :filesystem_root
>> 
>>        def prefix_path(path)
>>          filesystem_root ? File.join(filesystem_root, path) : path
>>        end
>> 
>>        def hwinfo
>>          if x86?
>>            {
>>              hostname: hostname,
>>              cpus: cpus,
>>              sockets: sockets,
>>              hypervisor: hypervisor,
>>              arch: arch,
>>              uuid: uuid
>>            }
>>          else
>>            {
>>              hostname: hostname,
>>              arch: arch
>>            }
>>          end
>>        end
>> 
>> From the toolkit hwinfo,rb I can see some Hypervisor definitions
>> h05cnh:~ #
>> cat /usr/lib64/ruby/gems/2.1.0/gems/suse-connect-0.2.7/lib/suse/toolkit/hwinfo.rb
>> require 'suse/toolkit/system_calls'
>> 
>> # Collects system hardware information
>> module SUSE::Toolkit::Hwinfo
>> 
>>  include SUSE::Toolkit::SystemCalls
>> 
>>  def cpus
>>    output['CPU(s)'].to_i
>>  end
>> 
>>  def sockets
>>    output['Socket(s)'].to_i
>>  end
>> 
>>  def hypervisor
>>    output['Hypervisor vendor']
>>  end
>> 
>> Can somebody please show me, how now SUSEConnect can distinguish
>> between a HP-ProLiant Server, a XEN client, a KVM client and a VMWare
>> ESXi client. It is really of interest to see how it is done.
>> ( Believing is one thing. But understanding the process gives me
>> confidence. )
>> 
>> Thank you very much, indeed
>> 
>> Best regards
> 
> Hi Urs,
> I check current code on github and it uses now lscpu call -
> https://github.com/SUSE/connect/blob/master/lib/suse/connect/hwinfo/x86.rb#L45
> from which it create pairs of keys and values. and there should by
> Hypervisor vendor key.
> 
> Josef
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta

From gahorvath at npsh.hu  Tue Aug 12 04:46:14 2014
From: gahorvath at npsh.hu (=?UTF-8?B?R8OhYm9yIEhvcnbDoXRo?=)
Date: Tue, 12 Aug 2014 12:46:14 +0200
Subject: [sles-beta] Big Ldap Problem
In-Reply-To: <1471624.DBGJMWmFe3@gjn.priv.at>
References: <4389226.7nn1APZf6u@gjn.priv.at>
	<53E87073020000C200153EDA@prv-mh.provo.novell.com>
	<1471624.DBGJMWmFe3@gjn.priv.at>
Message-ID: <53EA0C96020000D70001B594@groupwise.npsh.hu>

You specified searchbase="cn=config" in the olcSyncrepl attribute for
your production DIT's mdb backend.
I have a strong feeling it should be sth like
searchbase="dc=example,dc=com"

g.


>>> "G?nther J.Niederwimmer" <gjn at gjn.priv.at> 08/11/14 3:59 PM >>>
Hello,

Am Montag, 11. August 2014, 07:27:32 schrieb Donald Vosburg:
> Did you set separate credentials for the cn=config database?  Try
looking at
> what the yast LDAP server module shows.
> 
> Sent from my iPhone
;)

No is a original YaST Ldap Master Installation.

this is the output from ldapmodify

modifying entry "cn=config"

modifying entry "olcDatabase={0}config,cn=config"

modifying entry "olcDatabase={1}mdb,cn=config"
ldap_modify: Other (e.g., implementation specific) error (80)
        additional info: Base DN "cn=config" is not within the database
naming 
context

for Info the *.ldif is attached
  
> > On Aug 11, 2014, at 9:09 AM, "G?nther J.Niederwimmer"
<gjn at gjn.priv.at>
> > wrote:
> > 
> > Hello,
> > 
> > can any test or have test to change the ldap config for a working
Mirror
> > Setup.
> > 
> > On my system I can change with ldapmodify "dn: cn=config, dn:
> > Database={0}config,cn=config"
> > 
> > But not cn: olcDatabase={1}hdb,cn=config
> > 
> > Is this my mistake or a Bug?
> > 
> > Thank you for a answer,
> 
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta

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

  G?nther J. Niederwimmer

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

From behlert at suse.com  Wed Aug 13 01:09:47 2014
From: behlert at suse.com (Stefan Behlert)
Date: Wed, 13 Aug 2014 09:09:47 +0200
Subject: [sles-beta] RC1 NRPE Package (nagios)
In-Reply-To: <1407754048.7120.6.camel@ronnylinux.prod.bk.dfs>
References: <1407321611.7092.12.camel@ronnylinux.prod.bk.dfs>
	<20140806111453.GA14801@suse.de>
	<1407415729.26168.5.camel@ronnylinux.prod.bk.dfs>
	<20140807125545.GA4404@suse.de> <53E37AF0.8090705@ucs.cam.ac.uk>
	<1407499597.25813.10.camel@ronnylinux.prod.bk.dfs>
	<20140808123616.GA24665@suse.com>
	<1407754048.7120.6.camel@ronnylinux.prod.bk.dfs>
Message-ID: <20140813070947.GA14187@suse.de>

Hi,

On Aug 11, 14 12:47:28 +0200, Ronny Pretzsch wrote:
> Hello,
> 
> > > Thus the question if the nrpe daemon (nrpe tcp-server)
> > > is going to be included in any SLE12 product.
> > 
> > Similar to the nagios-plugins (which have been renamed to
> > monitoring-plugins), the nrpe stuff will be renamed to
> > monitoring*nrpe-*.
> 
> This is not the answer to my question!
> Again: Will the nrpe tcp-server (/usr/bin/nrpe) be included
> in SLE12 or do I have to get it from some place else (e.g.
> buildservice)?

I can confirm:
nrpe will be on the RC2 media. It contains '/usr/sbin/nrpe' (I think it was
in 'sbin' also on CODE11), and the /etc/nrpe.cfg.

I hope this answers your question, if not, be so kind to rephrase, 
to help me understand.

The confusion is due to the rename of the nagios-plugins-* to
monitoring-plugins-*. As collateral damage the nagios-nrpe package fell off
the table - it was renamed to 'nrpe' some time ago, and I missed that when
adapting the package lists for the media.
This error has been corrected meanwhile.


        ciao,
          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 ronny.pretzsch at dfs.de  Wed Aug 13 04:41:46 2014
From: ronny.pretzsch at dfs.de (Ronny Pretzsch)
Date: Wed, 13 Aug 2014 12:41:46 +0200
Subject: [sles-beta] RC1 NRPE Package (nagios)
In-Reply-To: <20140813070947.GA14187@suse.de>
References: <1407321611.7092.12.camel@ronnylinux.prod.bk.dfs>
	<20140806111453.GA14801@suse.de>
	<1407415729.26168.5.camel@ronnylinux.prod.bk.dfs>
	<20140807125545.GA4404@suse.de> <53E37AF0.8090705@ucs.cam.ac.uk>
	<1407499597.25813.10.camel@ronnylinux.prod.bk.dfs>
	<20140808123616.GA24665@suse.com>
	<1407754048.7120.6.camel@ronnylinux.prod.bk.dfs>
	<20140813070947.GA14187@suse.de>
Message-ID: <1407926506.6601.2.camel@ronnylinux.prod.bk.dfs>

> I can confirm:
> nrpe will be on the RC2 media. It contains '/usr/sbin/nrpe' (I think it was
> in 'sbin' also on CODE11), and the /etc/nrpe.cfg.
> 
> I hope this answers your question, if not, be so kind to rephrase, 
> to help me understand.

This answers my question.
Thank you very much!

Ciao,
Ronny


DFS Deutsche Flugsicherung GmbH
Am DFS-Campus
D - 63225 Langen

Tel.: +49-(0)6103-707-0

Sitz der Gesellschaft: Langen/Hessen
Zust?ndiges Registergericht: AG Offenbach am Main, HRB 34977
Vorsitzender des Aufsichtsrates: Michael Odenwald
Gesch?ftsf?hrer: Prof. Klaus-Dieter Scheurle (Vors.), Robert Schickling, Dr. Michael Hann

Internet: http://www.dfs.de
Public-Key der DFS: http://www.dfs.de/dfs/public_key.asc <http://www.dfs.de/dfs/public_key.asc>

From gjn at gjn.priv.at  Thu Aug 14 05:14:51 2014
From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer)
Date: Thu, 14 Aug 2014 13:14:51 +0200
Subject: [sles-beta] wicked & openvswitch
In-Reply-To: <20140813024633.GD2808@callisto.lan>
References: <1836253.NTgZCXi9QK@gjn.priv.at>
	<20140807173433.GA27396@callisto.lan>
	<20140813024633.GD2808@callisto.lan>
Message-ID: <13162158.cNsNeJMZHE@gjn.priv.at>

Hello Karol,
 
Am Dienstag, 12. August 2014, 19:46:33 schrieb Karol Mroz:
> Guenther et al,
> 
> After some internal discussion, I wanted to address your queries regarding
> openvswitch (ovs) and Wicked, to hopefully clarify any confusion that may
> have arisen.
> 
> Wicked is able to configure address, route and resolver settings of an
> ovs-style bridge. No more, no less. This means that the actual interface
> _needs_ to have been created and had a bridge port assigned by way of
> openvswitch itself (ie. ovs-vsctl. Wicked, currently, is _not_ able to
> create ovs-style bridges.
> 
> To create and configure an ovs-style bridge on a SLES-12 system with
> openvswitch 2.1.2 and wicked-0.6.1, you may do the following:
> 
> Assumptions:
> - eth0 will be the bridge port for ovs-style bridge called ovsbr0 (adjust
> naming suit your needs/system)

OK, I make all what you say but this is the most time not working. :-(

a static configuration is not possible. I have ovsbr0, ovsbr1 ovsbr2

With BOOTPROTO= 'dhcp' in ovsbr0 the network coming up AFTER boot sometimes 
with wicked ifreload all or ifup all? the most time not.

But then I have a dhcp and a static address (configuration) I change only 
"BOOTPROTO"

The ovsbr1 is static configured (IPv6) this is working normal when the ovsbr0 
is coming up.
 
> Procedure:
> 1. zypper in openvswitch && zypper in openvswitch-switch
>   - this should pull in openvswitch-kmp-[default|desktop|etc]
> 2. systemctl enable openvswitch
>   - allow openvswitch to start on reboot
> 3. systemctl start openvswitch
> 4. ovs-vsctl add-br ovsbr0
> 5. ovs-vsctl add-port ovsbr0 eth0
> 6. create /etc/sysconfig/network/ifcfg-eth0 to contain:
>   BOOTPROTO='none'
>   STARTMODE='auto'
> 7. create /etc/sysconfig/network/ifcfg-ovsbr0 to contain:
>   BOOTPROTO='dhcp'
>   STARTMODE='manual'
> 8. wicked ifup ovsbr0
> 
> Verification:
> 1. ovs-vsctl show
> 
> c1f92605-e9c2-4679-aa2a-20d7e55bf62d
>     Bridge "ovsbr0"
>         Port "eth0"
>             Interface "eth0"
>         Port "ovsbr0"
>             Interface "ovsbr0"
>                 type: internal
>     ovs_version: "2.1.2"
> 
> 2. wicked ifstatus eth0 ovsbr0
> 
> eth0            up
>       link:     #2, state up, mtu 1500
>       type:     ethernet, hwaddr 52:54:00:c4:23:89
>       config:   compat:/etc/sysconfig/network/ifcfg-eth0
> 
> ovsbr0          up
>       link:     #6, state up, mtu 1500
>       type:     ethernet, hwaddr f6:43:72:fe:fd:40
>       config:   compat:/etc/sysconfig/network/ifcfg-ovsbr0
>       leases:   ipv4 dhcp granted
>       leases:   ipv6 dhcp granted
>       addr:     ipv4 10.0.0.233/24
>       addr:     ipv6 fd78:3b33:7892::2b6/64
>       addr:     ipv6 fd78:3b33:7892:0:39fb:22d6:9315:3f08/64
>       addr:     ipv6 fd78:3b33:7892:0:f443:72ff:fefe:fd40/64
> 
> 3. No crash in Wicked was observed
> 
> As you can see, Wicked treats the ovs-style bridge, ovsbr0, as an ethernet
> device. It _needs_ to be present in the system _before_ trying to configure
> the device by way of `wicked ifup`. Thus, the openvswitch service needs to
> running _before_ Wicked and the ovsbr0 bridge needs to be present in the ovs
> database with proper port interfaces added. If correctly configured this
> way, on reboot, you should be able to bring up ovsbr0 manually via a direct
> `wicked ifup ovsbr0`.
> 
> To summarize the level of support for openvswitch in Wicked:
> 
> Wicked can configure addressing/resolver/routing for an ovs-style bridge,
> but the bridge first needs to be created by openvswitch (for example
> manually via ovs-vsctl). Wicked currently does _not_ support ovs-style
> bridge _creation_. Creation, if deemed needed, would be a feature delivered
> via a Service Pack.
> 
> Please try the above procedure and let us know how it works for you.
> 
> Best Regards,
> Karol

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

  G?nther J. Niederwimmer

From achernikov at suse.de  Wed Aug 13 02:55:36 2014
From: achernikov at suse.de (Artem Chernikov)
Date: Wed, 13 Aug 2014 10:55:36 +0200
Subject: [sles-beta] subscribe
Message-ID: <53EB2808.4060703@suse.de>



-- 
Artem Chernikov
DevOps Engineer
SCC Team
SuSE Linux Products GmbH
Maxfeldstr. 5, Nuremberg
+49 179 817 02 16


From gjn at gjn.priv.at  Fri Aug 15 09:32:16 2014
From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer)
Date: Fri, 15 Aug 2014 17:32:16 +0200
Subject: [sles-beta] wicked & openvswitch
In-Reply-To: <20140814175421.GG4497@callisto.lan>
References: <1836253.NTgZCXi9QK@gjn.priv.at> <13162158.cNsNeJMZHE@gjn.priv.at>
	<20140814175421.GG4497@callisto.lan>
Message-ID: <2163361.HVLScN88Ko@gjn.priv.at>

Hello Karol,

so now i create your minimalist ifcfg-xxx files ;-) I create static configs 

ifcfg-eth0
ifcfg-ovsbr0
ifcfg-eth1
ifcgf-ovsbr1

On this system are 4 NIC's

Two are in the moment not configured.

On start up the two ifcfg-ethX are known from wicked and configured.

the two ifcfg-ovsbrX are not known from wicked and NOT configured.

After the start up a "wicked ifreload all" bring up the two ifcfg-ovsbrX 

The SUSEfirewal have also problems with this set this have to modify manual.

wicked I mean know the ifcfg-eth0.orig SuSEfirewall not.	 

In this situation I have no working network after boot and problem with nfs 
and more 

Now I have to test the KVM Clients for working with openvswitch and more ;)

I sent attached the original created configs from YaST2 and my modification what 
I mean before  this must be configured?. 

You can have more Logs when you like :-).

Am Donnerstag, 14. August 2014, 10:54:21 schrieb Karol Mroz:
> On Thu, Aug 14, 2014 at 01:14:51PM +0200, G?nther J. Niederwimmer wrote:
> > Hello Karol,
> 
> Hello!
> 
> > Am Dienstag, 12. August 2014, 19:46:33 schrieb Karol Mroz:
> > > Guenther et al,
> > > 
> > > After some internal discussion, I wanted to address your queries
> > > regarding
> > > openvswitch (ovs) and Wicked, to hopefully clarify any confusion that
> > > may
> > > have arisen.
> > > 
> > > Wicked is able to configure address, route and resolver settings of an
> > > ovs-style bridge. No more, no less. This means that the actual interface
> > > _needs_ to have been created and had a bridge port assigned by way of
> > > openvswitch itself (ie. ovs-vsctl. Wicked, currently, is _not_ able to
> > > create ovs-style bridges.
> > > 
> > > To create and configure an ovs-style bridge on a SLES-12 system with
> > > openvswitch 2.1.2 and wicked-0.6.1, you may do the following:
> > > 
> > > Assumptions:
> > > - eth0 will be the bridge port for ovs-style bridge called ovsbr0
> > > (adjust
> > > naming suit your needs/system)
> > 
> > OK, I make all what you say but this is the most time not working. :-(
> > 
> > a static configuration is not possible. I have ovsbr0, ovsbr1 ovsbr2
> 
> I've applied both static and dhcp, and even a mixture to my ovsbrX through
> wicked successfully. Could you forward your ifcfg-ovsbrX files?
> 
> My examples are as follows (ifcfg-ovsbr2 with ifcfg-eth2 as port interface
> config):
> 
> 0. ifcfg-eth2
> BOOTPROTO='none'
> STARTMODE='auto'
> 
> 1. pure dhcp
> BOOTPROTO='dhcp'
> STARTMODE='manual'
> 
> 2. pure static
> BOOTPROTO='static'
> STARTMODE='manual'
> IPADDR='10.0.0.222/24'
> 
> 3. mixture
> BOOTPROTO='dhcp'
> STARTMODE='manual'
> IPADDR='10.0.0.222/24'
> 
> > With BOOTPROTO= 'dhcp' in ovsbr0 the network coming up AFTER boot
> > sometimes
> > with wicked ifreload all or ifup all? the most time not.
> 
> Hrm, this is interesting behaviour
> 
> `wicked ifup all` passes over interfaces with STARTMODE=manual
> 
> Perhaps this is expected and correct behaviour, however, it
> contradicts with:
> 
> `wicked ifreload all`
> 
> which actually does bring up interfaces configured with STARTMODE=manual
> 
> I will look into this. But in the meantime, please either reference
> the ovsbrX directly when doing an ifup:
> 
> `wicked ifup ovsbrX`
> 
> Or please use ifreload:
> 
> `wicked ifreload all`
> 
> Again, a manual STARTMODE is needed in the case of Wicked+ovs because
> Wicked can't yet create an ovs-style bridge. The bridge needs to be
> present (with port) before you try to configure. So, once booted, you
> need to manually bring up each ovsbrX interface directly.
> 
> I hope thise helps,
> Karol
> 
> PS. thanks for bringing the difference in ifup/ifreload behaviour with
> manual STARTMODE's to our attention!
> 
> > But then I have a dhcp and a static address (configuration) I change only
> > "BOOTPROTO"
> > 
> > The ovsbr1 is static configured (IPv6) this is working normal when the
> > ovsbr0 is coming up.
> > 
> > > Procedure:
> > > 1. zypper in openvswitch && zypper in openvswitch-switch
> > > 
> > >   - this should pull in openvswitch-kmp-[default|desktop|etc]
> > > 
> > > 2. systemctl enable openvswitch
> > > 
> > >   - allow openvswitch to start on reboot
> > > 
> > > 3. systemctl start openvswitch
> > > 4. ovs-vsctl add-br ovsbr0
> > > 5. ovs-vsctl add-port ovsbr0 eth0
> > > 
> > > 6. create /etc/sysconfig/network/ifcfg-eth0 to contain:
> > >   BOOTPROTO='none'
> > >   STARTMODE='auto'
> > > 
> > > 7. create /etc/sysconfig/network/ifcfg-ovsbr0 to contain:
> > >   BOOTPROTO='dhcp'
> > >   STARTMODE='manual'
> > > 
> > > 8. wicked ifup ovsbr0
> > > 
> > > Verification:
> > > 1. ovs-vsctl show
> > > 
> > > c1f92605-e9c2-4679-aa2a-20d7e55bf62d
> > > 
> > >     Bridge "ovsbr0"
> > >     
> > >         Port "eth0"
> > >         
> > >             Interface "eth0"
> > >         
> > >         Port "ovsbr0"
> > >         
> > >             Interface "ovsbr0"
> > >             
> > >                 type: internal
> > >     
> > >     ovs_version: "2.1.2"
> > > 
> > > 2. wicked ifstatus eth0 ovsbr0
> > > 
> > > eth0            up
> > > 
> > >       link:     #2, state up, mtu 1500
> > >       type:     ethernet, hwaddr 52:54:00:c4:23:89
> > >       config:   compat:/etc/sysconfig/network/ifcfg-eth0
> > > 
> > > ovsbr0          up
> > > 
> > >       link:     #6, state up, mtu 1500
> > >       type:     ethernet, hwaddr f6:43:72:fe:fd:40
> > >       config:   compat:/etc/sysconfig/network/ifcfg-ovsbr0
> > >       leases:   ipv4 dhcp granted
> > >       leases:   ipv6 dhcp granted
> > >       addr:     ipv4 10.0.0.233/24
> > >       addr:     ipv6 fd78:3b33:7892::2b6/64
> > >       addr:     ipv6 fd78:3b33:7892:0:39fb:22d6:9315:3f08/64
> > >       addr:     ipv6 fd78:3b33:7892:0:f443:72ff:fefe:fd40/64
> > > 
> > > 3. No crash in Wicked was observed
> > > 
> > > As you can see, Wicked treats the ovs-style bridge, ovsbr0, as an
> > > ethernet
> > > device. It _needs_ to be present in the system _before_ trying to
> > > configure
> > > the device by way of `wicked ifup`. Thus, the openvswitch service needs
> > > to
> > > running _before_ Wicked and the ovsbr0 bridge needs to be present in the
> > > ovs database with proper port interfaces added. If correctly configured
> > > this way, on reboot, you should be able to bring up ovsbr0 manually via
> > > a direct `wicked ifup ovsbr0`.
> > > 
> > > To summarize the level of support for openvswitch in Wicked:
> > > 
> > > Wicked can configure addressing/resolver/routing for an ovs-style
> > > bridge,
> > > but the bridge first needs to be created by openvswitch (for example
> > > manually via ovs-vsctl). Wicked currently does _not_ support ovs-style
> > > bridge _creation_. Creation, if deemed needed, would be a feature
> > > delivered
> > > via a Service Pack.
> > > 
> > > Please try the above procedure and let us know how it works for you.
> > > 
> > > Best Regards,
> > > Karol

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

  G?nther J. Niederwimmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: network.tar.bz2
Type: application/x-bzip-compressed-tar
Size: 1075 bytes
Desc: not available
URL: <http://lists.suse.com/mailman/private/sles-beta/attachments/20140815/43a90126/attachment.tbz2>