From urs.frey at post.ch  Mon Sep 15 04:27:29 2014
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Mon, 15 Sep 2014 10:27:29 +0000
Subject: [sles-beta] SLES12 x86_64 RC3 zypper problem: requires
 ruby(abi) = 2.1.0, but this requirement cannot be provided
In-Reply-To: <20140915120432.1f626ed2@tengu.suse.de>
References: <40637DBB36AF3941B243A286A432CA0B0F9D6CC8@HXMB12.pnet.ch>
	<1410528965.1791.12.camel@par-r81vxc7.par.novell.com>
	<40637DBB36AF3941B243A286A432CA0B0F9D6D2D@HXMB12.pnet.ch>
	<1410530261.1791.13.camel@par-r81vxc7.par.novell.com>
	<20140912163613.32576d01@tengu.suse.de>
	<40637DBB36AF3941B243A286A432CA0B0F9D6DF7@HXMB12.pnet.ch>
	<20140915120432.1f626ed2@tengu.suse.de>
Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9D7622@HXMB12.pnet.ch>

Hello Marcus

Quite cryptographic your informatin

>> <rpm:entry name="rubygem(ruby:2.1.0:stomp:1.3.2)" flags="EQ"
>> epoch="0" ver="1.3.2"/>

>so you have a relatively recent ruby-common package. it generates the
>right provides.

>> <rpm:entry name="ruby(abi)" flags="EQ" epoch="0" ver="2.1.0"/>

Guess you are talking about repodata/primary.xml.gz entry above, created using "createrepo ."

</package>
<package type="rpm">
  <name>pst-rubygem-stomp-doc</name>
  <arch>x86_64</arch>
  <version epoch="0" ver="1.3.2" rel="1"/>
  <checksum type="sha" pkgid="YES">5bdafd1e190887c96ee893d57dfb0edf65a017cc</checksum>
  <summary>RDoc documentation for stomp</summary>
  <description>Documentation generated at gem installation time.
Usually in RDoc and RI formats.</description>
  <packager></packager>
  <url>https://github.com/stompgem/stomp</url>
  <time file="1410534064" build="1410533812"/>
  <size package="114374" installed="279474" archive="398896"/>
<location href="x86_64/pst-rubygem-stomp-doc-1.3.2-1.x86_64.rpm"/>
  <format>
    <rpm:license>Apache License Version 2.0</rpm:license>
    <rpm:vendor>Die Schweizerische Post</rpm:vendor>
    <rpm:group>Development/Languages/Ruby</rpm:group>
    <rpm:buildhost>h05cni.pnet.ch</rpm:buildhost>
    <rpm:sourcerpm>pst-rubygem-stomp-1.3.2-1.src.rpm</rpm:sourcerpm>
    <rpm:header-range start="280" end="71844"/>
    <rpm:provides>
      <rpm:entry name="pst-rubygem-stomp-doc" flags="EQ" epoch="0" ver="1.3.2" rel="1"/>
      <rpm:entry name="pst-rubygem-stomp-doc(x86-64)" flags="EQ" epoch="0" ver="1.3.2" rel="1"/>
    </rpm:provides>
    <rpm:requires>
      <rpm:entry name="pst-rubygem-stomp" flags="EQ" epoch="0" ver="1.3.2"/>
    </rpm:requires>
  </format>
</package>



>but the wrong requires here

>1. rpm -qp --requires x86_64/pst-rubygem-stomp-1.3.2-1.x86_64.rpm
>   rpm -qp --provides x86_64/pst-rubygem-stomp-1.3.2-1.x86_64.rpm
What exactly do you mean?
v03g27:/appl/pstkits/pstaddon/SLES12_64/post/x86_64 # rpm -qp --requires pst-rubygem-stomp-1.3.2-1.x86_64.rpm
/usr/bin/ruby
/usr/bin/ruby.ruby2.1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
ruby(abi) = ruby:2.1.0
rpmlib(PayloadIsLzma) <= 4.4.6-1
v03g27:/appl/pstkits/pstaddon/SLES12_64/post/x86_64 #
v03g27:/appl/pstkits/pstaddon/SLES12_64/post/x86_64 # rpm -qp --provides pst-rubygem-stomp-1.3.2-1.x86_64.rpm
pst-rubygem-stomp = 1.3.2-1
pst-rubygem-stomp(x86-64) = 1.3.2-1
rubygem(ruby:2.1.0:stomp) = 1.3.2
rubygem(ruby:2.1.0:stomp:1) = 1.3.2
rubygem(ruby:2.1.0:stomp:1.3) = 1.3.2
rubygem(ruby:2.1.0:stomp:1.3.2) = 1.3.2
rubygem(stomp) = 1.3.2
v03g27:/appl/pstkits/pstaddon/SLES12_64/post/x86_64 #


>2. please make sure this is not some caching you enabled in createrepo.
Sorry, but what do you exactly mean? 
I am using createrepo like this
# cd /appl/pstkits/pstaddon/SLES12_64/post
# createrepo .
No -c (--cachedir) or similar

>3. did you bump release numbers when rebuilding. if not, this might be
>   the cause for the broken requires.
What do you exactly mean?

I am having a fresh installation on the client, so there is no cache
On the repository before rebuilding I remove all packages and the path repodata
Then I rsync the RPMs from the build server to the repo server and as last step I do a createrepo to build the entries under repodata.
So I might exclude what you might have suspected.

By the way I rebuilt the package on my freshly installed SLES12 RC3 server, then I installed apache2, configured it and copied the freshly built rpm to a new path, did a createrepo and then published this path in apache2.
The I removed my previously not working zypper repo with the OEM packages
Finally I added this apache2 published path from the local server with zypper as a new repository.

So I have SLES12 RC3 on Testserver A
Built custom RPM on SLES12 RC3 Testserver A
Installed apache2 on Testserver A
Created repo on Testserver A
Added zypper repo http on Testserver A

=> zypper had still the same error

Conclusion
Whatever you mean: I claim createrepo on SLES12 RC3 is not working anymore

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: Marcus R?ckert [mailto:mrueckert at suse.de] 
Gesendet: Monday, September 15, 2014 12:05 PM
An: Frey Urs, IT222
Cc: fcrozat at suse.com; sles-beta at lists.suse.com
Betreff: Re: [sles-beta] SLES12 x86_64 RC3 zypper problem: requires ruby(abi) = 2.1.0, but this requirement cannot be provided

On Fri, 12 Sep 2014 15:25:32 +0000
<urs.frey at post.ch> wrote:

> <rpm:entry name="rubygem(ruby:2.1.0:stomp:1.3.2)" flags="EQ"
> epoch="0" ver="1.3.2"/>

so you have a relatively recent ruby-common package. it generates the
right provides.

> <rpm:entry name="ruby(abi)" flags="EQ" epoch="0" ver="2.1.0"/>

but the wrong requires here

1. rpm -qp --requires x86_64/pst-rubygem-stomp-1.3.2-1.x86_64.rpm
   rpm -qp --provides x86_64/pst-rubygem-stomp-1.3.2-1.x86_64.rpm
2. please make sure this is not some caching you enabled in createrepo.
3. did you bump release numbers when rebuilding. if not, this might be
   the cause for the broken requires.

-- 
          openSUSE - SUSE Linux is my linux
              openSUSE is good for you
                  www.opensuse.org

From mrueckert at suse.de  Mon Sep 15 04:04:32 2014
From: mrueckert at suse.de (Marcus =?UTF-8?B?UsO8Y2tlcnQ=?=)
Date: Mon, 15 Sep 2014 12:04:32 +0200
Subject: [sles-beta] SLES12 x86_64 RC3 zypper problem: requires
 ruby(abi) = 2.1.0, but this requirement cannot be provided
In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9D6DF7@HXMB12.pnet.ch>
References: <40637DBB36AF3941B243A286A432CA0B0F9D6CC8@HXMB12.pnet.ch>
	<1410528965.1791.12.camel@par-r81vxc7.par.novell.com>
	<40637DBB36AF3941B243A286A432CA0B0F9D6D2D@HXMB12.pnet.ch>
	<1410530261.1791.13.camel@par-r81vxc7.par.novell.com>
	<20140912163613.32576d01@tengu.suse.de>
	<40637DBB36AF3941B243A286A432CA0B0F9D6DF7@HXMB12.pnet.ch>
Message-ID: <20140915120432.1f626ed2@tengu.suse.de>

On Fri, 12 Sep 2014 15:25:32 +0000
<urs.frey at post.ch> wrote:

> <rpm:entry name="rubygem(ruby:2.1.0:stomp:1.3.2)" flags="EQ"
> epoch="0" ver="1.3.2"/>

so you have a relatively recent ruby-common package. it generates the
right provides.

> <rpm:entry name="ruby(abi)" flags="EQ" epoch="0" ver="2.1.0"/>

but the wrong requires here

1. rpm -qp --requires x86_64/pst-rubygem-stomp-1.3.2-1.x86_64.rpm
   rpm -qp --provides x86_64/pst-rubygem-stomp-1.3.2-1.x86_64.rpm
2. please make sure this is not some caching you enabled in createrepo.
3. did you bump release numbers when rebuilding. if not, this might be
   the cause for the broken requires.

-- 
          openSUSE - SUSE Linux is my linux
              openSUSE is good for you
                  www.opensuse.org

From mrueckert at suse.de  Mon Sep 15 04:54:27 2014
From: mrueckert at suse.de (Marcus =?UTF-8?B?UsO8Y2tlcnQ=?=)
Date: Mon, 15 Sep 2014 12:54:27 +0200
Subject: [sles-beta] SLES12 x86_64 RC3 zypper problem: requires
 ruby(abi) = 2.1.0, but this requirement cannot be provided
In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9D7622@HXMB12.pnet.ch>
References: <40637DBB36AF3941B243A286A432CA0B0F9D6CC8@HXMB12.pnet.ch>
	<1410528965.1791.12.camel@par-r81vxc7.par.novell.com>
	<40637DBB36AF3941B243A286A432CA0B0F9D6D2D@HXMB12.pnet.ch>
	<1410530261.1791.13.camel@par-r81vxc7.par.novell.com>
	<20140912163613.32576d01@tengu.suse.de>
	<40637DBB36AF3941B243A286A432CA0B0F9D6DF7@HXMB12.pnet.ch>
	<20140915120432.1f626ed2@tengu.suse.de>
	<40637DBB36AF3941B243A286A432CA0B0F9D7622@HXMB12.pnet.ch>
Message-ID: <20140915125427.5ee471a6@tengu.suse.de>

On Mon, 15 Sep 2014 10:27:29 +0000
<urs.frey at post.ch> wrote:
> >but the wrong requires here
> 
> >1. rpm -qp --requires x86_64/pst-rubygem-stomp-1.3.2-1.x86_64.rpm
> >   rpm -qp --provides x86_64/pst-rubygem-stomp-1.3.2-1.x86_64.rpm
> What exactly do you mean?
> v03g27:/appl/pstkits/pstaddon/SLES12_64/post/x86_64 # rpm -qp
> --requires pst-rubygem-stomp-1.3.2-1.x86_64.rpm /usr/bin/ruby
[...]
> ruby(abi) = ruby:2.1.0

ok the package actually has the correct requires.

> Whatever you mean: I claim createrepo on SLES12 RC3 is not working
> anymore

createrepo on sle11 or sle12 has problems with X:Y as "version" number
it seems.

     Marcus Rueckert

-- 
          openSUSE - SUSE Linux is my linux
              openSUSE is good for you
                  www.opensuse.org

From kukuk at suse.de  Mon Sep 15 04:58:49 2014
From: kukuk at suse.de (Thorsten Kukuk)
Date: Mon, 15 Sep 2014 12:58:49 +0200
Subject: [sles-beta] Certificate Deleted
In-Reply-To: <1611665.XhP1MaMyAv@gjn.priv.at>
References: <1611665.XhP1MaMyAv@gjn.priv.at>
Message-ID: <20140915105849.GA3251@suse.de>

On Sun, Sep 14, G?nther J. Niederwimmer wrote:

> Hello,
> 
> when I make a zypper up from RC2 to RC3 my Certificate are deleted in 
> /usr/lib/ca-certificates/pem ?

Do you really mean /usr/lib/ca-certificates/pem and not
/var/lib/ca-certificates/pem ?

I cannot find /usr/lib/ca-certificates/pem, but if your certificate
was really in /var/lib/ca-certificates/pem and got deleted during
upgrade: that behavior is correct.

According to our release-notes (3.1.3.1 Installing CA Certificates),
the correct place is /etc/pki/trust/anchors/

  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 gjn at gjn.priv.at  Mon Sep 15 05:20:41 2014
From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer)
Date: Mon, 15 Sep 2014 13:20:41 +0200
Subject: [sles-beta] Certificate Deleted
In-Reply-To: <20140915105849.GA3251@suse.de>
References: <1611665.XhP1MaMyAv@gjn.priv.at> <20140915105849.GA3251@suse.de>
Message-ID: <3395007.2hMXcVxlYN@gjn.priv.at>

Hello Thorsten,

Am Montag, 15. September 2014, 12:58:49 schrieb Thorsten Kukuk:
> On Sun, Sep 14, G?nther J. Niederwimmer wrote:
> > Hello,
> > 
> > when I make a zypper up from RC2 to RC3 my Certificate are deleted in
> > /usr/lib/ca-certificates/pem ?
> 
> Do you really mean /usr/lib/ca-certificates/pem and not
> /var/lib/ca-certificates/pem ?

Pardon,
I mean /var/lib/ca-certificates/pem
 
> I cannot find /usr/lib/ca-certificates/pem, but if your certificate
> was really in /var/lib/ca-certificates/pem and got deleted during
> upgrade: that behavior is correct.
> 
> According to our release-notes (3.1.3.1 Installing CA Certificates),
> the correct place is /etc/pki/trust/anchors/

Thorsten, is this correct also with the YaST2 CA created CA/certificate ?

Then I lost always with a Update, my certificate. YaST2 store the certificate in 
/var/lib/ca-certificates/pem

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

  G?nther J. Niederwimmer

From urs.frey at post.ch  Mon Sep 15 05:22:34 2014
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Mon, 15 Sep 2014 11:22:34 +0000
Subject: [sles-beta] SLES12 x86_64 RC3 zypper problem: requires
 ruby(abi) = 2.1.0, but this requirement cannot be provided
In-Reply-To: <20140915125427.5ee471a6@tengu.suse.de>
References: <40637DBB36AF3941B243A286A432CA0B0F9D6CC8@HXMB12.pnet.ch>
	<1410528965.1791.12.camel@par-r81vxc7.par.novell.com>
	<40637DBB36AF3941B243A286A432CA0B0F9D6D2D@HXMB12.pnet.ch>
	<1410530261.1791.13.camel@par-r81vxc7.par.novell.com>
	<20140912163613.32576d01@tengu.suse.de>
	<40637DBB36AF3941B243A286A432CA0B0F9D6DF7@HXMB12.pnet.ch>
	<20140915120432.1f626ed2@tengu.suse.de>
	<40637DBB36AF3941B243A286A432CA0B0F9D7622@HXMB12.pnet.ch>
	<20140915125427.5ee471a6@tengu.suse.de>
Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9D767C@HXMB12.pnet.ch>

Hello Marcus

>createrepo on sle11 or sle12 has problems with X:Y as "version" number
>it seems.
So will this be analyzed and fixed ?

thanks

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


-----Urspr?ngliche Nachricht-----
Von: Marcus R?ckert [mailto:mrueckert at suse.de] 
Gesendet: Monday, September 15, 2014 12:54 PM
An: Frey Urs, IT222
Cc: fcrozat at suse.com; sles-beta at lists.suse.com
Betreff: Re: [sles-beta] SLES12 x86_64 RC3 zypper problem: requires ruby(abi) = 2.1.0, but this requirement cannot be provided

On Mon, 15 Sep 2014 10:27:29 +0000
<urs.frey at post.ch> wrote:
> >but the wrong requires here
> 
> >1. rpm -qp --requires x86_64/pst-rubygem-stomp-1.3.2-1.x86_64.rpm
> >   rpm -qp --provides x86_64/pst-rubygem-stomp-1.3.2-1.x86_64.rpm
> What exactly do you mean?
> v03g27:/appl/pstkits/pstaddon/SLES12_64/post/x86_64 # rpm -qp
> --requires pst-rubygem-stomp-1.3.2-1.x86_64.rpm /usr/bin/ruby
[...]
> ruby(abi) = ruby:2.1.0

ok the package actually has the correct requires.

> Whatever you mean: I claim createrepo on SLES12 RC3 is not working
> anymore

createrepo on sle11 or sle12 has problems with X:Y as "version" number
it seems.

     Marcus Rueckert

-- 
          openSUSE - SUSE Linux is my linux
              openSUSE is good for you
                  www.opensuse.org

From mrueckert at suse.de  Mon Sep 15 06:15:32 2014
From: mrueckert at suse.de (Marcus =?UTF-8?B?UsO8Y2tlcnQ=?=)
Date: Mon, 15 Sep 2014 14:15:32 +0200
Subject: [sles-beta] SLES12 x86_64 RC3 zypper problem: requires
 ruby(abi) = 2.1.0, but this requirement cannot be provided
In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9D767C@HXMB12.pnet.ch>
References: <40637DBB36AF3941B243A286A432CA0B0F9D6CC8@HXMB12.pnet.ch>
	<1410528965.1791.12.camel@par-r81vxc7.par.novell.com>
	<40637DBB36AF3941B243A286A432CA0B0F9D6D2D@HXMB12.pnet.ch>
	<1410530261.1791.13.camel@par-r81vxc7.par.novell.com>
	<20140912163613.32576d01@tengu.suse.de>
	<40637DBB36AF3941B243A286A432CA0B0F9D6DF7@HXMB12.pnet.ch>
	<20140915120432.1f626ed2@tengu.suse.de>
	<40637DBB36AF3941B243A286A432CA0B0F9D7622@HXMB12.pnet.ch>
	<20140915125427.5ee471a6@tengu.suse.de>
	<40637DBB36AF3941B243A286A432CA0B0F9D767C@HXMB12.pnet.ch>
Message-ID: <20140915141532.07fbaf9f@tengu.suse.de>

On Mon, 15 Sep 2014 11:22:34 +0000
<urs.frey at post.ch> wrote:

> Hello Marcus
> 
> >createrepo on sle11 or sle12 has problems with X:Y as "version"
> >number it seems.
> So will this be analyzed and fixed ?

1. it is already analyzed.
2. solution should be submitted soon.

hth

-- 
          openSUSE - SUSE Linux is my linux
              openSUSE is good for you
                  www.opensuse.org

From jsrain at suse.cz  Tue Sep 16 02:53:55 2014
From: jsrain at suse.cz (Jiri Srain)
Date: Tue, 16 Sep 2014 10:53:55 +0200
Subject: [sles-beta] SLES12 RC3 and SMT
In-Reply-To: <450c9ed24c4e40e2be8615e0b361c1bb@LGNMSXA01.prod.bk.dfs>
References: <53E357F7.9060809@suse.cz>
	<450c9ed24c4e40e2be8615e0b361c1bb@LGNMSXA01.prod.bk.dfs>
Message-ID: <5417FAA3.8030100@suse.cz>

Hello,

the version of the API was indeed changed with RC3.

I will push out an announcement about new version of SMT within next hour.

Jiri

On 09/16/2014 10:25 AM, Pretzsch, Ronny wrote:
> Hello,
>
> I am about to install SLES12 RC3 (Manual Installation).
>
> I wanted to register with our local SMT (Beta) but I get the error message
>
> Registration client error.
> Details: API Version not supported.
>
>
> On our SMT Beta Server I see the following line in /var/log/apache2/access_log:
> testvm001.xxxxxxx - - [16/Sep/2014:10:21:49 +0200] "POST /connect/subscriptions/systems HTTP/1.1" 406 96 "-" "SUSEConnect/0.2.11"
>
>
> We use the LATEST-Repo
> http://beta.suse.com/private/SMT-Beta/11-SP3/LATEST/
>
> and have the following SMT-Version:
> vm11:~ # rpm -qa |grep -i smt
> libesmtp-1.0.4-157.15.1
> smt-2.0.1-0.7.1
> nagios-plugins-smtp-1.5-111.2
> yast2-smt-2.17.29-0.7.1
>
>
> Is there a newer SMT Version required? And will it be released on the know location?
>
>
> 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>
>
>
>
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta
>


-- 
Regards,

Jiri Srain
Project Manager
---------------------------------------------------------------------
SUSE LINUX, s.r.o.                            e-mail: jsrain at suse.com
Lihovarska 1060/12                            tel: +420 284 084 659
190 00 Praha 9                                fax: +420 284 084 001
Czech Republic                                http://www.suse.com

From jsrain at suse.cz  Tue Sep 16 03:15:02 2014
From: jsrain at suse.cz (Jiri Srain)
Date: Tue, 16 Sep 2014 11:15:02 +0200
Subject: [sles-beta] New testing snapshot of SMT11-SP3 update available
Message-ID: <5417FF96.8060107@suse.cz>

Dear SLES12 testers,

testing version of SMT, which allows registration of SLES12 RC3, is now 
available at

   http://beta.suse.com/private/SMT-Beta/

Please, update to this version, otherwise SLES12 RC3 installer reports 
an error during registration against SMT (as already reported on 
sles-beta list).

For updating, make sure to use the latest repo, as referenced at the URL 
above. If you use the date stamp as part of the repository URL instead 
of the symlink 'LATEST', please, adjust the repository URL. For fresh 
installation, you need both the new repository and the original SMT media.

More information is available in the README-SCC file, which is available 
at the URL above.

Happy testing and thanks for your feedback!

     The SUSE SMT team.


-- 
Regards,

Jiri Srain
Project Manager
---------------------------------------------------------------------
SUSE LINUX, s.r.o.                            e-mail: jsrain at suse.com
Lihovarska 1060/12                            tel: +420 284 084 659
190 00 Praha 9                                fax: +420 284 084 001
Czech Republic                                http://www.suse.com

-- 
Regards,

Jiri Srain
Project Manager
---------------------------------------------------------------------
SUSE LINUX, s.r.o.                            e-mail: jsrain at suse.com
Lihovarska 1060/12                            tel: +420 284 084 659
190 00 Praha 9                                fax: +420 284 084 001
Czech Republic                                http://www.suse.com

From gjn at gjn.priv.at  Wed Sep 17 03:34:20 2014
From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer)
Date: Wed, 17 Sep 2014 11:34:20 +0200
Subject: [sles-beta] snapper ldap mdb DB
Message-ID: <8356843.O8iFxEoHZp@gjn.priv.at>

Hello,

Question is this a Bug,

when I create with yast2 a ldap-server and like to test the mdb DB this was 
not deleted, in the view it is marked to delete, but it is not deleted 
afterward.

I have create a snapshot before I install ldap
Thanks for a Answer.
-- 
mit freundlichen Gr??en / best Regards,

  G?nther J. Niederwimmer

From rthompson at novell.com  Wed Sep 17 06:28:00 2014
From: rthompson at novell.com (Richard Thompson)
Date: Wed, 17 Sep 2014 13:28:00 +0100
Subject: [sles-beta]  openssh
Message-ID: <54198C600200006D000D50B9@mail.emea.novell.com>

A quick question about openssh

I am trying to find /usr/lib64/ssh/ssh-ldap-wrapper and /usr/lib64/ssh/helper (they are in SLES11).
They appear to have been taken out of the openssh package.

Have they been moved elsewhere or have they just been removed?

Richard Thompson

Attachmate Group Germany GmbH
D?sseldorf


From ronny.pretzsch at dfs.de  Wed Sep 17 06:31:34 2014
From: ronny.pretzsch at dfs.de (Ronny Pretzsch)
Date: Wed, 17 Sep 2014 14:31:34 +0200
Subject: [sles-beta] SLES12 RC2 x86_64 Login possible even though
 autoyast init-script is still runing
In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9D2BF6@HXMB12.pnet.ch>
References: <40637DBB36AF3941B243A286A432CA0B0F9D2BF6@HXMB12.pnet.ch>
Message-ID: <1410957094.30188.13.camel@ronnylinux.prod.bk.dfs>

On Tue, 2014-08-26 at 13:23 +0000, urs.frey at post.ch wrote:
> Hi
>  
> When trying to install SLES12 Rc2 x86_64 using autoyast with
> init-scripts within autoinst.xml the installation process does not
> wait until init-script has terminated.
> So I can already see the final login screen even though my init-script
> within autoinst.xml is still running
>  
> This is wrong.
> I mean under SLES11-SP3 the autoinst.xml init-script does terminate
> and ONLY after termination of this init-script the services get
> restarted and the login gets visible
>  
> I consider this as bug.
> Please fix this within autoyast

Hello,

I reported this bug on the list with beta 9 or so.

Stefan Schubert told us to report a bug which we did:

https://bugzilla.novell.com/show_bug.cgi?id=891144

Unfortunately the very same Stefan closed this bug with a useless cite
of the documentation:

------
Summary: SLE12 RC1- autoyast init-script is still executed while at
login prompt 
Collapse All Comments - Expand All Comments 
________________________________________________________________________
[reply] [-] Description Brian King 2014-08-08 20:40:30 UTC 
Autoyast init-script is still being executed while the login prompt (tty 1-6)
appears.  Thus the user thinks the system is ready when it really is not.
[reply] [-] Comment 3 Stefan Schubert 2014-08-20 08:54:21 UTC 
The docu says:
"These scripts are executed when YaST has finished, during the initial boot
process after the network has been initialized. These final scripts are
executed using a special init.d script executed only once."

So init scripts are intent to run independent.
------

I am very happy to see not only we (DFS) have the simple requirement to
run a script after autoyast installation but before allowing user login
but also Urs Frey and others do.

We use the init-script to run puppet and make the system ready for
usage, which takes some minutes. I think this is a standard use case.
During this puppet phase a log-in *must* be avoided.

What is the official statement from SUSE regarding this topic?

For us the feature "init-script" is considered not-working with SLE12
currently.

Regards,

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 schubi at suse.de  Thu Sep 18 04:59:02 2014
From: schubi at suse.de (Stefan Schubert)
Date: Thu, 18 Sep 2014 12:59:02 +0200
Subject: [sles-beta] SLES12 RC2 x86_64 Login possible even though
 autoyast init-script is still runing
In-Reply-To: <1410957094.30188.13.camel@ronnylinux.prod.bk.dfs>
References: <40637DBB36AF3941B243A286A432CA0B0F9D2BF6@HXMB12.pnet.ch>
	<1410957094.30188.13.camel@ronnylinux.prod.bk.dfs>
Message-ID: <541ABAF6.5010309@suse.de>

Hello,

Well, since I have had closed that bug and I have not heard anything 
else from you or the
bug reporter since almost one month I have had the assumption that 
everything is OK
for you.

I have described the current state of theses scripts which is described 
in the official documentation too.
I have not been aware that this information is "useless" for you and 
does not solve your problem.

So I will reopen the bug and try to find a solution for this problem.

Greetings
Stefan Schubert

Am 17.09.2014 14:31, schrieb Ronny Pretzsch:
> On Tue, 2014-08-26 at 13:23 +0000, urs.frey at post.ch wrote:
>> Hi
>>   
>> When trying to install SLES12 Rc2 x86_64 using autoyast with
>> init-scripts within autoinst.xml the installation process does not
>> wait until init-script has terminated.
>> So I can already see the final login screen even though my init-script
>> within autoinst.xml is still running
>>   
>> This is wrong.
>> I mean under SLES11-SP3 the autoinst.xml init-script does terminate
>> and ONLY after termination of this init-script the services get
>> restarted and the login gets visible
>>   
>> I consider this as bug.
>> Please fix this within autoyast
> Hello,
>
> I reported this bug on the list with beta 9 or so.
>
> Stefan Schubert told us to report a bug which we did:
>
> https://bugzilla.novell.com/show_bug.cgi?id=891144
>
> Unfortunately the very same Stefan closed this bug with a useless cite
> of the documentation:
>
> ------
> Summary: SLE12 RC1- autoyast init-script is still executed while at
> login prompt
> Collapse All Comments - Expand All Comments
> ________________________________________________________________________
> [reply] [-] Description Brian King 2014-08-08 20:40:30 UTC
> Autoyast init-script is still being executed while the login prompt (tty 1-6)
> appears.  Thus the user thinks the system is ready when it really is not.
> [reply] [-] Comment 3 Stefan Schubert 2014-08-20 08:54:21 UTC
> The docu says:
> "These scripts are executed when YaST has finished, during the initial boot
> process after the network has been initialized. These final scripts are
> executed using a special init.d script executed only once."
>
> So init scripts are intent to run independent.
> ------
>
> I am very happy to see not only we (DFS) have the simple requirement to
> run a script after autoyast installation but before allowing user login
> but also Urs Frey and others do.
>
> We use the init-script to run puppet and make the system ready for
> usage, which takes some minutes. I think this is a standard use case.
> During this puppet phase a log-in *must* be avoided.
>
> What is the official statement from SUSE regarding this topic?
>
> For us the feature "init-script" is considered not-working with SLE12
> currently.
>
> Regards,
>
> 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>
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta


-- 
*******************************************************************************
Stefan Schubert
e-mail: schubi at suse.de
-------------------------------------------------------------------------------
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  Thu Sep 18 05:10:21 2014
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Thu, 18 Sep 2014 11:10:21 +0000
Subject: [sles-beta] SLES12 RC2 x86_64 Login possible even though
 autoyast init-script is still runing
In-Reply-To: <541ABAF6.5010309@suse.de>
References: <40637DBB36AF3941B243A286A432CA0B0F9D2BF6@HXMB12.pnet.ch>
	<1410957094.30188.13.camel@ronnylinux.prod.bk.dfs>
	<541ABAF6.5010309@suse.de>
Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9DE0D8@HXMB12.pnet.ch>

Hi Stefan
Thank you! I agree that it is sometimes difficult to estimate what is going on in the "hectic" life of a beta program.
But closing a bug when there is no feasible technical solution available is .... (not really acceptable)

Of course I do agree that systemd brings new challenges on both sides: distributor and end user

Getting a suitable solution will be highly welcome

Btw: RC3 is not installable for me, because of the ruby(abi) createrepo problem
So I can not really test. This is one answer, why there is no feedback
The other side is, that there was never a bug (Bugzilla Link) published to me.
(at least I have no message with a link concerning this subject and bug)

Best regards

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

-----Urspr?ngliche Nachricht-----
Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Stefan Schubert
Gesendet: Thursday, September 18, 2014 12:59 PM
An: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing

Hello,

Well, since I have had closed that bug and I have not heard anything 
else from you or the
bug reporter since almost one month I have had the assumption that 
everything is OK
for you.

I have described the current state of theses scripts which is described 
in the official documentation too.
I have not been aware that this information is "useless" for you and 
does not solve your problem.

So I will reopen the bug and try to find a solution for this problem.

Greetings
Stefan Schubert

Am 17.09.2014 14:31, schrieb Ronny Pretzsch:
> On Tue, 2014-08-26 at 13:23 +0000, urs.frey at post.ch wrote:
>> Hi
>>   
>> When trying to install SLES12 Rc2 x86_64 using autoyast with
>> init-scripts within autoinst.xml the installation process does not
>> wait until init-script has terminated.
>> So I can already see the final login screen even though my init-script
>> within autoinst.xml is still running
>>   
>> This is wrong.
>> I mean under SLES11-SP3 the autoinst.xml init-script does terminate
>> and ONLY after termination of this init-script the services get
>> restarted and the login gets visible
>>   
>> I consider this as bug.
>> Please fix this within autoyast
> Hello,
>
> I reported this bug on the list with beta 9 or so.
>
> Stefan Schubert told us to report a bug which we did:
>
> https://bugzilla.novell.com/show_bug.cgi?id=891144
>
> Unfortunately the very same Stefan closed this bug with a useless cite
> of the documentation:
>
> ------
> Summary: SLE12 RC1- autoyast init-script is still executed while at
> login prompt
> Collapse All Comments - Expand All Comments
> ________________________________________________________________________
> [reply] [-] Description Brian King 2014-08-08 20:40:30 UTC
> Autoyast init-script is still being executed while the login prompt (tty 1-6)
> appears.  Thus the user thinks the system is ready when it really is not.
> [reply] [-] Comment 3 Stefan Schubert 2014-08-20 08:54:21 UTC
> The docu says:
> "These scripts are executed when YaST has finished, during the initial boot
> process after the network has been initialized. These final scripts are
> executed using a special init.d script executed only once."
>
> So init scripts are intent to run independent.
> ------
>
> I am very happy to see not only we (DFS) have the simple requirement to
> run a script after autoyast installation but before allowing user login
> but also Urs Frey and others do.
>
> We use the init-script to run puppet and make the system ready for
> usage, which takes some minutes. I think this is a standard use case.
> During this puppet phase a log-in *must* be avoided.
>
> What is the official statement from SUSE regarding this topic?
>
> For us the feature "init-script" is considered not-working with SLE12
> currently.
>
> Regards,
>
> 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>
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta


-- 
*******************************************************************************
Stefan Schubert
e-mail: schubi at suse.de
-------------------------------------------------------------------------------
SUSE LINUX Products GmbH
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg)
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 schubi at suse.de  Thu Sep 18 06:06:15 2014
From: schubi at suse.de (Stefan Schubert)
Date: Thu, 18 Sep 2014 14:06:15 +0200
Subject: [sles-beta] SLES12 RC2 x86_64 Login possible even though
 autoyast init-script is still runing
In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9DE0D8@HXMB12.pnet.ch>
References: <40637DBB36AF3941B243A286A432CA0B0F9D2BF6@HXMB12.pnet.ch>	<1410957094.30188.13.camel@ronnylinux.prod.bk.dfs>
	<541ABAF6.5010309@suse.de>
	<40637DBB36AF3941B243A286A432CA0B0F9DE0D8@HXMB12.pnet.ch>
Message-ID: <541ACAB7.8070509@suse.de>

Am 18.09.2014 13:10, schrieb urs.frey at post.ch:
> Btw: RC3 is not installable for me, because of the ruby(abi) createrepo problem
> So I can not really test. This is one answer, why there is no feedback
Could you please point me to the bugzilla ID ?
> The other side is, that there was never a bug (Bugzilla Link) published to me.
> (at least I have no message with a link concerning this subject and bug)
>
>
I have added you to the CC list.

Greetings
Stefan Schubert

-- 
*******************************************************************************
Stefan Schubert
e-mail: schubi at suse.de
-------------------------------------------------------------------------------
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  Thu Sep 18 06:18:35 2014
From: ronny.pretzsch at dfs.de (Pretzsch, Ronny)
Date: Thu, 18 Sep 2014 12:18:35 +0000
Subject: [sles-beta] SLES12 RC2 x86_64 Login possible even though
 autoyast init-script is still runing
In-Reply-To: <541ABAF6.5010309@suse.de>
References: <40637DBB36AF3941B243A286A432CA0B0F9D2BF6@HXMB12.pnet.ch>
	<1410957094.30188.13.camel@ronnylinux.prod.bk.dfs>,
	<541ABAF6.5010309@suse.de>
Message-ID: <d3c5182f76cb4435a3fe6527d2f5bbbb@LGNMSXA01.prod.bk.dfs>

Hello Stefan,

thank you very much for re-opening. I was on vacation, that's why I did not respond for a while.

A solution for this might be to implement a general "run-once" mechanism. We have in our SLE11 environment done such a thing by ourselves:
Create an init script (or with sle12 systemd script) with correct dependencies (has to run after network but before login getty / xdm).
This script does not delete itself (as opposed to the autoyast init-script) but runs with every boot.
This script executes all scripts in e.g. /var/spool/run-once.d/* and deletes those scripts afterwards.

So autoyast would have nothing else to do but copy the init-script(s) to /var/spool/run-once.d/

Bye,

Ronny Pretzsch

Produktmanagement Linux Server
Produktmanagement Intranet und Internet


DFS Deutsche Flugsicherung GmbH
Systemhaus Datacenter (SH/ID)
Am DFS-Campus 10
63225 Langen


________________________________________
Von: sles-beta-bounces at lists.suse.com <sles-beta-bounces at lists.suse.com> im Auftrag von Stefan Schubert <schubi at suse.de>
Gesendet: Donnerstag, 18. September 2014 12:59
An: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing

Hello,

Well, since I have had closed that bug and I have not heard anything
else from you or the
bug reporter since almost one month I have had the assumption that
everything is OK
for you.

I have described the current state of theses scripts which is described
in the official documentation too.
I have not been aware that this information is "useless" for you and
does not solve your problem.

So I will reopen the bug and try to find a solution for this problem.

Greetings
Stefan Schubert

Am 17.09.2014 14:31, schrieb Ronny Pretzsch:
> On Tue, 2014-08-26 at 13:23 +0000, urs.frey at post.ch wrote:
>> Hi
>>
>> When trying to install SLES12 Rc2 x86_64 using autoyast with
>> init-scripts within autoinst.xml the installation process does not
>> wait until init-script has terminated.
>> So I can already see the final login screen even though my init-script
>> within autoinst.xml is still running
>>
>> This is wrong.
>> I mean under SLES11-SP3 the autoinst.xml init-script does terminate
>> and ONLY after termination of this init-script the services get
>> restarted and the login gets visible
>>
>> I consider this as bug.
>> Please fix this within autoyast
> Hello,
>
> I reported this bug on the list with beta 9 or so.
>
> Stefan Schubert told us to report a bug which we did:
>
> https://bugzilla.novell.com/show_bug.cgi?id=891144
>
> Unfortunately the very same Stefan closed this bug with a useless cite
> of the documentation:
>
> ------
> Summary: SLE12 RC1- autoyast init-script is still executed while at
> login prompt
> Collapse All Comments - Expand All Comments
> ________________________________________________________________________
> [reply] [-] Description Brian King 2014-08-08 20:40:30 UTC
> Autoyast init-script is still being executed while the login prompt (tty 1-6)
> appears.  Thus the user thinks the system is ready when it really is not.
> [reply] [-] Comment 3 Stefan Schubert 2014-08-20 08:54:21 UTC
> The docu says:
> "These scripts are executed when YaST has finished, during the initial boot
> process after the network has been initialized. These final scripts are
> executed using a special init.d script executed only once."
>
> So init scripts are intent to run independent.
> ------
>
> I am very happy to see not only we (DFS) have the simple requirement to
> run a script after autoyast installation but before allowing user login
> but also Urs Frey and others do.
>
> We use the init-script to run puppet and make the system ready for
> usage, which takes some minutes. I think this is a standard use case.
> During this puppet phase a log-in *must* be avoided.
>
> What is the official statement from SUSE regarding this topic?
>
> For us the feature "init-script" is considered not-working with SLE12
> currently.
>
> Regards,
>
> 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>
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta


--
*******************************************************************************
Stefan Schubert
e-mail: schubi at suse.de
-------------------------------------------------------------------------------
SUSE LINUX Products GmbH
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg)
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

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 Joerg.Reisenweber at btc-it-services.com  Thu Sep 18 06:23:29 2014
From: Joerg.Reisenweber at btc-it-services.com (Joerg.Reisenweber at btc-it-services.com)
Date: Thu, 18 Sep 2014 14:23:29 +0200
Subject: [sles-beta] SLES12 RC2 x86_64 Login possible even though
 autoyast init-script is still runing
In-Reply-To: <541ACAB7.8070509@suse.de>
References: <40637DBB36AF3941B243A286A432CA0B0F9D2BF6@HXMB12.pnet.ch>
	<1410957094.30188.13.camel@ronnylinux.prod.bk.dfs>
	<541ABAF6.5010309@suse.de>
	<40637DBB36AF3941B243A286A432CA0B0F9DE0D8@HXMB12.pnet.ch>
	<541ACAB7.8070509@suse.de>
Message-ID: <6FCF9F3FA7310B4B9AA1A975F4C4A54B4C0FBF2941@OLCA9095.btcnet.btc-ag.com>

Dear list,

fwiw, this "bug" isn't new to SLES. It exists in SLES 11.x as well. We are using AutoYaST init scripts for registration with SUMA. Because we use the "fully update this box" feature in our bootstrap scripts, login was always already possible although the box was still being updated.

We would also appreciate a "fix" for this.

Sunny greetings
J?rg

-----Urspr?ngliche Nachricht-----
Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Stefan Schubert
Gesendet: Donnerstag, 18. September 2014 14:06
Cc: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing

Am 18.09.2014 13:10, schrieb urs.frey at post.ch:
> Btw: RC3 is not installable for me, because of the ruby(abi) 
> createrepo problem So I can not really test. This is one answer, why 
> there is no feedback
Could you please point me to the bugzilla ID ?
> The other side is, that there was never a bug (Bugzilla Link) published to me.
> (at least I have no message with a link concerning this subject and 
> bug)
>
>
I have added you to the CC list.

Greetings
Stefan Schubert

--
*******************************************************************************
Stefan Schubert
e-mail: schubi at suse.de
-------------------------------------------------------------------------------
SUSE LINUX Products GmbH
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) 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 urs.frey at post.ch  Thu Sep 18 06:23:49 2014
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Thu, 18 Sep 2014 12:23:49 +0000
Subject: [sles-beta] SLES12 RC2 x86_64 Login possible even though
 autoyast init-script is still runing
In-Reply-To: <d3c5182f76cb4435a3fe6527d2f5bbbb@LGNMSXA01.prod.bk.dfs>
References: <40637DBB36AF3941B243A286A432CA0B0F9D2BF6@HXMB12.pnet.ch>
	<1410957094.30188.13.camel@ronnylinux.prod.bk.dfs>,
	<541ABAF6.5010309@suse.de>
	<d3c5182f76cb4435a3fe6527d2f5bbbb@LGNMSXA01.prod.bk.dfs>
Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9DE184@HXMB12.pnet.ch>

Hi all

The main reason why I need to run custom installations and puppet in autoyast init-script is the locking mechanism from yast towards zypper 
One really feasible solution would be, making zypper awailable to run during autoyast post-install phase, then init-script would be less used.

Without zypper available in post-script, autoyast post-script is nearly useless for me

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 Pretzsch, Ronny
Gesendet: Thursday, September 18, 2014 2:19 PM
An: Stefan Schubert; sles-beta at lists.suse.com
Betreff: Re: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing

Hello Stefan,

thank you very much for re-opening. I was on vacation, that's why I did not respond for a while.

A solution for this might be to implement a general "run-once" mechanism. We have in our SLE11 environment done such a thing by ourselves:
Create an init script (or with sle12 systemd script) with correct dependencies (has to run after network but before login getty / xdm).
This script does not delete itself (as opposed to the autoyast init-script) but runs with every boot.
This script executes all scripts in e.g. /var/spool/run-once.d/* and deletes those scripts afterwards.

So autoyast would have nothing else to do but copy the init-script(s) to /var/spool/run-once.d/

Bye,

Ronny Pretzsch

Produktmanagement Linux Server
Produktmanagement Intranet und Internet


DFS Deutsche Flugsicherung GmbH
Systemhaus Datacenter (SH/ID)
Am DFS-Campus 10
63225 Langen


________________________________________
Von: sles-beta-bounces at lists.suse.com <sles-beta-bounces at lists.suse.com> im Auftrag von Stefan Schubert <schubi at suse.de>
Gesendet: Donnerstag, 18. September 2014 12:59
An: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing

Hello,

Well, since I have had closed that bug and I have not heard anything
else from you or the
bug reporter since almost one month I have had the assumption that
everything is OK
for you.

I have described the current state of theses scripts which is described
in the official documentation too.
I have not been aware that this information is "useless" for you and
does not solve your problem.

So I will reopen the bug and try to find a solution for this problem.

Greetings
Stefan Schubert

Am 17.09.2014 14:31, schrieb Ronny Pretzsch:
> On Tue, 2014-08-26 at 13:23 +0000, urs.frey at post.ch wrote:
>> Hi
>>
>> When trying to install SLES12 Rc2 x86_64 using autoyast with
>> init-scripts within autoinst.xml the installation process does not
>> wait until init-script has terminated.
>> So I can already see the final login screen even though my init-script
>> within autoinst.xml is still running
>>
>> This is wrong.
>> I mean under SLES11-SP3 the autoinst.xml init-script does terminate
>> and ONLY after termination of this init-script the services get
>> restarted and the login gets visible
>>
>> I consider this as bug.
>> Please fix this within autoyast
> Hello,
>
> I reported this bug on the list with beta 9 or so.
>
> Stefan Schubert told us to report a bug which we did:
>
> https://bugzilla.novell.com/show_bug.cgi?id=891144
>
> Unfortunately the very same Stefan closed this bug with a useless cite
> of the documentation:
>
> ------
> Summary: SLE12 RC1- autoyast init-script is still executed while at
> login prompt
> Collapse All Comments - Expand All Comments
> ________________________________________________________________________
> [reply] [-] Description Brian King 2014-08-08 20:40:30 UTC
> Autoyast init-script is still being executed while the login prompt (tty 1-6)
> appears.  Thus the user thinks the system is ready when it really is not.
> [reply] [-] Comment 3 Stefan Schubert 2014-08-20 08:54:21 UTC
> The docu says:
> "These scripts are executed when YaST has finished, during the initial boot
> process after the network has been initialized. These final scripts are
> executed using a special init.d script executed only once."
>
> So init scripts are intent to run independent.
> ------
>
> I am very happy to see not only we (DFS) have the simple requirement to
> run a script after autoyast installation but before allowing user login
> but also Urs Frey and others do.
>
> We use the init-script to run puppet and make the system ready for
> usage, which takes some minutes. I think this is a standard use case.
> During this puppet phase a log-in *must* be avoided.
>
> What is the official statement from SUSE regarding this topic?
>
> For us the feature "init-script" is considered not-working with SLE12
> currently.
>
> Regards,
>
> 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>
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta


--
*******************************************************************************
Stefan Schubert
e-mail: schubi at suse.de
-------------------------------------------------------------------------------
SUSE LINUX Products GmbH
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg)
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

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

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

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

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

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

From urs.frey at post.ch  Thu Sep 18 06:49:53 2014
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Thu, 18 Sep 2014 12:49:53 +0000
Subject: [sles-beta] SLES12 RC2 x86_64 Login possible even though
 autoyast init-script is still runing
In-Reply-To: <6FCF9F3FA7310B4B9AA1A975F4C4A54B4C0FBF2941@OLCA9095.btcnet.btc-ag.com>
References: <40637DBB36AF3941B243A286A432CA0B0F9D2BF6@HXMB12.pnet.ch>
	<1410957094.30188.13.camel@ronnylinux.prod.bk.dfs>
	<541ABAF6.5010309@suse.de>
	<40637DBB36AF3941B243A286A432CA0B0F9DE0D8@HXMB12.pnet.ch>
	<541ACAB7.8070509@suse.de>
	<6FCF9F3FA7310B4B9AA1A975F4C4A54B4C0FBF2941@OLCA9095.btcnet.btc-ag.com>
Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9DE196@HXMB12.pnet.ch>

Yes, correct, this is already known with SLES11-SP3, because of the already known zyyper lock in autoyast post-script
But in SLES11-SP3 the overlap of not finished init-scripts and login already possible is less notable


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 Joerg.Reisenweber at btc-it-services.com
Gesendet: Thursday, September 18, 2014 2:23 PM
Cc: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing

Dear list,

fwiw, this "bug" isn't new to SLES. It exists in SLES 11.x as well. We are using AutoYaST init scripts for registration with SUMA. Because we use the "fully update this box" feature in our bootstrap scripts, login was always already possible although the box was still being updated.

We would also appreciate a "fix" for this.

Sunny greetings
J?rg

-----Urspr?ngliche Nachricht-----
Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Stefan Schubert
Gesendet: Donnerstag, 18. September 2014 14:06
Cc: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing

Am 18.09.2014 13:10, schrieb urs.frey at post.ch:
> Btw: RC3 is not installable for me, because of the ruby(abi) 
> createrepo problem So I can not really test. This is one answer, why 
> there is no feedback
Could you please point me to the bugzilla ID ?
> The other side is, that there was never a bug (Bugzilla Link) published to me.
> (at least I have no message with a link concerning this subject and 
> bug)
>
>
I have added you to the CC list.

Greetings
Stefan Schubert

--
*******************************************************************************
Stefan Schubert
e-mail: schubi at suse.de
-------------------------------------------------------------------------------
SUSE LINUX Products GmbH
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) 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
_______________________________________________
sles-beta mailing list
sles-beta at lists.suse.com
http://lists.suse.com/mailman/listinfo/sles-beta

From gsu at axway.com  Thu Sep 18 11:04:19 2014
From: gsu at axway.com (Guang Su)
Date: Thu, 18 Sep 2014 17:04:19 +0000
Subject: [sles-beta] [Bug 895418] Autoyast error using PXE installation
 - pkg-bindings silently hide any libzypp error
In-Reply-To: <20140909125441.8A3A2CC7C4@soval.provo.novell.com>
References: <bug-895418-66095@http.bugzilla.novell.com/>
	<20140909125441.8A3A2CC7C4@soval.provo.novell.com>
Message-ID: <EFCA4142AEE5F74FA9BA0EF0C9D2B62F1D828424@WPHXMAIL1.phx.axway.int>

Hi,

I wonder why RC3 does not have the fix package (yast2-pkg-bindings-3.1.18) included? I saw old package /mnt/iso/suse/x86_64/yast2-pkg-bindings-3.1.17-1.2.x86_64.rpm

Thanks

--Guang



-----Original Message-----
From: bugzilla_noreply at novell.com [mailto:bugzilla_noreply at novell.com] 
Sent: Tuesday, September 09, 2014 5:55 AM
To: Guang Su
Subject: [Bug 895418] Autoyast error using PXE installation - pkg-bindings silently hide any libzypp error


https://bugzilla.novell.com/show_bug.cgi?id=895418

https://bugzilla.novell.com/show_bug.cgi?id=895418#c8


Ladislav Slezak <lslezak at suse.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #8 from Ladislav Slezak <lslezak at suse.com> 2014-09-09 12:54:40 UTC --- I removed the generic exception handler which ignored all errors, now pkg-bindings return `nil` when an error occurs.

That means it will probably crash more violently in your case, but it won't hide the errors in libzypp anymore.

Fixed in yast2-pkg-bindings-3.1.18
(https://github.com/yast/yast-pkg-bindings/pull/31, SR#43882)


You need to fix the Pool repository to make it work properly.

--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: ------- You are on the CC list for the bug.

From behlert at suse.com  Thu Sep 18 23:49:24 2014
From: behlert at suse.com (Stefan Behlert)
Date: Fri, 19 Sep 2014 07:49:24 +0200
Subject: [sles-beta] [Bug 895418] Autoyast error using PXE
	installation	- pkg-bindings silently hide any libzypp error
In-Reply-To: <EFCA4142AEE5F74FA9BA0EF0C9D2B62F1D828424@WPHXMAIL1.phx.axway.int>
References: <bug-895418-66095@http.bugzilla.novell.com/>
	<20140909125441.8A3A2CC7C4@soval.provo.novell.com>
	<EFCA4142AEE5F74FA9BA0EF0C9D2B62F1D828424@WPHXMAIL1.phx.axway.int>
Message-ID: <20140919054924.GA7131@suse.de>

Moin,


On Sep 18, 14 17:04:19 +0000, Guang Su wrote:
> Hi,
> 
> I wonder why RC3 does not have the fix package
> (yast2-pkg-bindings-3.1.18) included? I saw old package
> /mnt/iso/suse/x86_64/yast2-pkg-bindings-3.1.17-1.2.x86_64.rpm


That's simple: Because it came after the deadline of RC3 submits.
Let me explain this a little bit for better understanding:
RC 3 _release_ date was announce for Sep 11th. This means, we try to make
the images available to you on that date, latest on the 12th given QA
results (and your timezone ;) ).

To achieve this, we have submit deadlines for packages that should go onto
the media. In this case it were the 5th for packages which trigger a huge
number of packages to build (e.g. we updated util-linux), and the 8th for
packages that are 'leaf packages'.
The package you mentioned was fixed on the 9th. It then went through some
pre-check-queues to make sure it has no regressions, and to find potential
issues before it went into the media. 
When it was ready, we already had an image in QA for acceptance tests that
looed good to become an RC3. And as this time we had no re-mastering to do
because of QA-found severe issues, the package did not make it onto RC3.


At one point in time we simply have to close the acceptance of package
submissions to be able to release, sorry.
Some packages that came in late get then released as updates, but not all.

        ciao,
          Stefan



> 
> Thanks
> 
> --Guang
> 
> 
> 
> -----Original Message-----
> From: bugzilla_noreply at novell.com [mailto:bugzilla_noreply at novell.com] 
> Sent: Tuesday, September 09, 2014 5:55 AM
> To: Guang Su
> Subject: [Bug 895418] Autoyast error using PXE installation - pkg-bindings silently hide any libzypp error
> 
> 
> https://bugzilla.novell.com/show_bug.cgi?id=895418
> 
> https://bugzilla.novell.com/show_bug.cgi?id=895418#c8
> 
> 
> Ladislav Slezak <lslezak at suse.com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|ASSIGNED                    |RESOLVED
>          Resolution|                            |FIXED
> 
> --- Comment #8 from Ladislav Slezak <lslezak at suse.com> 2014-09-09 12:54:40 UTC --- I removed the generic exception handler which ignored all errors, now pkg-bindings return `nil` when an error occurs.
> 
> That means it will probably crash more violently in your case, but it won't hide the errors in libzypp anymore.
> 
> Fixed in yast2-pkg-bindings-3.1.18
> (https://github.com/yast/yast-pkg-bindings/pull/31, SR#43882)
> 
> 
> You need to fix the Pool repository to make it work properly.
> 
> --
> Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
> ------- You are receiving this mail because: ------- You are on the CC list for the bug.
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta
> 

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

From frank.loewe at ngncc.de  Fri Sep 19 06:51:06 2014
From: frank.loewe at ngncc.de (Frank Loewe)
Date: Fri, 19 Sep 2014 14:51:06 +0200 (CEST)
Subject: [sles-beta] perl-Parse-Yapp missing in RC3?
In-Reply-To: <13703046.1783.1411131018654.JavaMail.floewe@FDOMWS-FLOEWE>
Message-ID: <18968678.1784.1411131055777.JavaMail.floewe@FDOMWS-FLOEWE>

Hi all,

i can?t find this Module after upgrading SLES11-SP3 > SLES12RC3.
I it missing on purpose or by mistake?

--
Mit freundlichem Gru?

Frank Loewe

derzeit t?tig f?r:

IBM Deutschland GmbH
NGN Competence Center
c/o Deutsche Telekom AG
Oeserstr. 111
65934 Frankfurt am Main
Tel: + 49 69 90551-180
Mobil: +49 178 4998899




From darrent at akurit.com.au  Sat Sep 20 02:15:29 2014
From: darrent at akurit.com.au (Darren Thompson)
Date: Sat, 20 Sep 2014 18:15:29 +1000
Subject: [sles-beta] YAST2 "Install server"
Message-ID: <CAEUhfEcjaY09EP=zWUSJ+iPj1FAE6=mZsggmbn4NbOAQubyTmw@mail.gmail.com>

Team

I have a SLES12 "Install server" that i have been craying forward from the
earliest betas by just doing an inplace zypper dup with the new sources as
repos.

In any case the apache2 instance started failing with the following errors:

sles12sources:/etc/apache2 # systemctl status apache2
apache2.service - The Apache Webserver
   Loaded: loaded (/usr/lib/systemd/system/apache2.service; enabled)
   Active: failed (Result: exit-code) since Sat 2014-09-20 17:32:54 AEST;
5s ago
  Process: 3517 ExecStop=/usr/sbin/start_apache2 -D SYSTEMD -DFOREGROUND -k
graceful-stop (code=exited, status=1/FAILURE)
  Process: 3498 ExecStart=/usr/sbin/start_apache2 -D SYSTEMD -DFOREGROUND
-k start (code=exited, status=1/FAILURE)
 Main PID: 3498 (code=exited, status=1/FAILURE)

Sep 20 17:32:53 sles12sources start_apache2[3498]: Module "imagemap" is not
installed, ignoring.
Sep 20 17:32:53 sles12sources start_apache2[3498]: Check the APACHE_MODULES
setting in /etc/sysconfig/apache2.
Sep 20 17:32:53 sles12sources start_apache2[3498]: AH00526: Syntax error on
line 9 of /etc/apache2/conf.d/inst_server.conf:
Sep 20 17:32:53 sles12sources start_apache2[3498]: Invalid command 'Order',
perhaps misspelled or defined by a modu...ation
Sep 20 17:32:54 sles12sources start_apache2[3517]: Module "imagemap" is not
installed, ignoring.
Sep 20 17:32:54 sles12sources start_apache2[3517]: Check the APACHE_MODULES
setting in /etc/sysconfig/apache2.
Sep 20 17:32:54 sles12sources start_apache2[3517]: AH00526: Syntax error on
line 9 of /etc/apache2/conf.d/inst_server.conf:
Sep 20 17:32:54 sles12sources start_apache2[3517]: Invalid command 'Order',
perhaps misspelled or defined by a modu...ation


The "imagemap" looks like it was just an invalid module so i excluded it
and that seemd to address that issue...

The "Invalid command 'Order'," was more confusing as it is a standard
authorisation stansa.

I found this reference in apace2 documents
"In this example, all requests are allowed.
2.2 configuration:

Order allow,denyAllow from all

 2.4 configuration:

Require all granted"

http://httpd.apache.org/docs/2.4/upgrading.html

I then re-edited the "inst_server,conf" file in,ine with that recomendation
(sample below) and the install server is now working again.

Is it possible that the YAST2 module does not correctly accomadate an
upgraded APACHE2 server configuration requirement?

Sample inst_server.conf below:

# httpd configuration for Installation Server included by httpd.conf
<IfDefine inst_server>
    Alias /Install/ /srv/install/
    <Directory /srv/install/>

        Options +Indexes +FollowSymLinks
        IndexOptions +NameWidth=*

#        Order allow,deny
#        Allow from all
Require all granted

    </Directory>
</IfDefine>

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