From meissner at suse.de Mon Sep 22 04:04:42 2014 From: meissner at suse.de (Marcus Meissner) Date: Mon, 22 Sep 2014 12:04:42 +0200 Subject: [sles-beta] openssh In-Reply-To: <54198C600200006D000D50B9@mail.emea.novell.com> References: <54198C600200006D000D50B9@mail.emea.novell.com> Message-ID: <20140922100442.GC31624@suse.de> Hi, They have been split out into the openssh-helpers package, which was not added to the SLE12 media yet. I sent an email to the release managers to add it. Ciao, Marcus On Wed, Sep 17, 2014 at 01:28:00PM +0100, Richard Thompson wrote: > 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 > > _______________________________________________ > sles-beta mailing list > sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta > From schubi at suse.de Tue Sep 23 09:21:45 2014 From: schubi at suse.de (Stefan Schubert) Date: Tue, 23 Sep 2014 17:21:45 +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: <54219009.9040003@suse.de> 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 > Hello, we have fixed this because it has been proven that it is REALLY a problem in some use cases. So, no login is possible now until the AutoYaST init-script has been finished. 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 uwedr at suse.com Wed Sep 24 06:20:46 2014 From: uwedr at suse.com (Uwe Drechsel) Date: Wed, 24 Sep 2014 14:20:46 +0200 Subject: [sles-beta] Documentation pdf Files In-Reply-To: <1522810.6lHP2jRvDl@gjn.priv.at> References: <1522810.6lHP2jRvDl@gjn.priv.at> Message-ID: <20140924122046.GE8532@suse.com> On Sat, Sep 13, G?nther J.Niederwimmer wrote: > Hello, > > is this known in the Doc (book...pdf) RC3 are YaST module described this don't > exist anymore in YaST2, like kerberos client or kerberos server but nothing > for the sssd config or the new auth-server client. > The doc team is looking into this. Thanks Uwe -- mathematician, n: Someone who believes imaginary things appear right before your i's. From behlert at suse.com Wed Sep 24 23:58:47 2014 From: behlert at suse.com (Stefan Behlert) Date: Thu, 25 Sep 2014 07:58:47 +0200 Subject: [sles-beta] perl-Parse-Yapp missing in RC3? In-Reply-To: <18968678.1784.1411131055777.JavaMail.floewe@FDOMWS-FLOEWE> References: <13703046.1783.1411131018654.JavaMail.floewe@FDOMWS-FLOEWE> <18968678.1784.1411131055777.JavaMail.floewe@FDOMWS-FLOEWE> Message-ID: <20140925055847.GA15879@suse.de> Moin, On Sep 19, 14 14:51:06 +0200, Frank Loewe wrote: > Hi all, > > i can?t find this Module after upgrading SLES11-SP3 > SLES12RC3. > I it missing on purpose or by mistake? It was missing on the SDK by mistake. Will be on the next release. Thanks for mentioning it. Stefan > > -- > Mit freundlichem Gru? > > Frank Loewe -- 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 darrent at akurit.com.au Thu Sep 25 00:47:08 2014 From: darrent at akurit.com.au (Darren Thompson) Date: Thu, 25 Sep 2014 16:47:08 +1000 Subject: [sles-beta] YAST2 "Install server" - incorrect permissions set by default Message-ID: Team OK first email was too wordy... Has anyone else set-up the "Install Server" using the Yast "install server" module? If yes, (and you set it up to use http) were the default Apache permissions working correctly? Darren Darren Thompson Professional Services Engineer / Consultant *[image: cid:image001.jpg at 01CB7C0C.6C6A2AE0]* Level 3, 60 City Road Southgate, VIC 3006 Mb: 0400 640 414 Mail: darrent at akurit.com.au Web: www.akurit.com.au On 20 September 2014 18:15, Darren Thompson wrote: > 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 > > Alias /Install/ /srv/install/ > > > Options +Indexes +FollowSymLinks > IndexOptions +NameWidth=* > > # Order allow,deny > # Allow from all > Require all granted > > > > > 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 > Web: www.akurit.com.au > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 3692 bytes Desc: not available URL: From jeffm at suse.com Sat Sep 27 09:55:49 2014 From: jeffm at suse.com (Jeff Mahoney) Date: Sat, 27 Sep 2014 11:55:49 -0400 Subject: [sles-beta] btrfs & tooling In-Reply-To: References: <1401278011.31434.37.camel@ibrokeit.suse.de> Message-ID: <5426DE05.1070604@suse.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/24/14, 7:19 AM, Christoph Schumacher wrote: > Hi all, Hi Christoph - > I lately tested RC2 with focus btrfs, subvolumes and tooling. > > I was disappointed to see, that there still are a load of issues > open to especially quota and tooling with btrfs as i mentioned > before. - grp-quota seems to not work at all (i already discussed > with our SE) I'm not sure what issues you're referring to here. Can you elaborate? > - human readable quota-size list does not exist Are you referring to the btrfs qgroup show output? Yes, this could be better. While the output presents all the information correctly, it's not easily translatable by the user. It would probably be more helpful to map the qgroups to subvolumes where possible. As far as the columns go, they correspond to the number of bytes referenced by a subvolume (rfer) and the number of bytes referenced exclusively by a subvolume (excl). > - df ....still no hooks for btrfs quota/subvolumes How would this information be presented? There is no direct mapping in the way there is for LVM volumes. All subvolumes share a common storage pool unless otherwise restricted. There's no way to determine how much space a subvolume occupies because the space referenced by it can be a mix of shared references and exclusive references. So we could present 'used' on a subvolume basis, but if you added up the 'used' space across all subvolumes, we'd end up with a number that could be much larger than the size of the file system. > ...at this point my testing stoped... > > As long as the only option is to just create an entire diskvolume > (without lvm) because of the bad subvolume handling, i see btrfs > not in production stage. As soon as lvm enters the stage, i see no > gain in btrfs. Btrfs subvolumes and LVM subvolumes are different and this is by design. Sure, you can make a loose analogy by using dm thin with snapshots, but the usage/mapping knowledge is still at the block layer. Btrfs subvolumes offer dedupe, reflink copies, and a number of other space-saving operations. - -Jeff > > I'll place all my concerns next week at the expert forum btrfs > workshop, but i had the feeling to point this out on the list. What > about all list participants? Do you plan to use btrfs for > production (at least the OS part)? > > *Dipl.-Inf. Christoph Schumacher* FAI5 Competencecenter Dezentrale > Server Dr. Ing. h.c. F. Porsche AG Porscheplatz 1, D-70435 > Stuttgart Zuffenhausen Telefon: +49 (0)711/911-23729 Fax: > +49 (0)711/911-23171 E-Mail: > christoph.schumacher at porsche.de > > > > From: Christoph Schumacher > To: > sles-beta at lists.suse.com Date: 28/05/2014 14:00 Subject: > Re: [sles-beta] btrfs & tooling Sent by: > sles-beta-bounces at lists.suse.com > ------------------------------------------------------------------------ > > > > > Hi Richard, > > Honestly it'll be a mess to dismiss "df" for a lot of people, > especially the guys coming from any UNIX. > > As i mentioned: on my beta7 install the commands you issued do not > work well or hard to read: > > For example btrfs fi df shows a lot of information and it's hard > to filter at a glance. > > btrfs qgroup show does not work for me at all....what's the quota? > have a guess! > > # btrfs qgroup show /tmp qgroupid rfer excl -------- ---- > ---- 0/5 16384 16384 0/257 2359185408 2359185408 0/258 > 16384 16384 0/259 102576128 102576128 0/260 16384 > 16384 0/261 16384 16384 0/262 16384 16384 0/263 > 97067008 97067008 > > > * Dipl.-Inf. Christoph Schumacher* FAI5 Competence Center > Dezentrale Server Dr. Ing. h.c. F. Porsche AG Porscheplatz 1, > D-70435 Stuttgart Zuffenhausen Telefon: +49 (0)711/911-23729 Fax: > +49 (0)711/911-23171 E-Mail: > christoph.schumacher at porsche.de > > > > From: Richard Brown To: > sles-beta at lists.suse.com Date: 28/05/2014 13:53 Subject: > Re: [sles-beta] btrfs & tooling Sent by: > sles-beta-bounces at lists.suse.com > ------------------------------------------------------------------------ > > > > > Hello Christoph, > > I'm afraid I can't answer all your questions, but I'll take a stab > at a few that I believe I know the answer to > > On Wed, 2014-05-28 at 13:39 +0200, Christoph Schumacher wrote: >> - on subvolume with limits/quota df always shows the size of the >> parent volume also for all subvolumes IMHO it should either show >> the limited size or not show the subvolume at all because it's >> only disturbing > >> - also after "mirroring" a btrfs with a raid1 df shows the sum of >> both volumes in the btrfs despite the real size > > Because of the nature of how btrfs works, df isn't the best tool to > use > > btrfs has it's own tools for the purpose, such as 'btrfs fi show' > which shows you the raw disk usage, and 'btrfs fi df ' > which will show you the equivalent of df, taking into account > things like btrfs RAID, for the subvolume selected by > >> - i can't figure out how to show the quota of a btrfs volume >> easily and clearly ..... what the common known btrfs-tools show >> is cr....not good. > > 'btrfs qgroup show ' where is a location for > your btrfs volume/subvolume, should give you the information you > require. > > Hope this helps, > > - Rich > > -- > ------------------------------------------------------------------- > > Richard Brown, QA Engineer > Phone +4991174053-361, Fax +4991174053-483 SUSE LINUX Products > GmbH, Maxfeldstr. 5, D-90409 Nuernberg Geschaeftsfuehrer: Jeff > Hawn, Jennifer Guild, Felix Imendoerffer, HRB 16746 (AG Nuernberg) > ------------------------------------------------------------------- > > > > _______________________________________________ sles-beta mailing > list sles-beta at lists.suse.com_ > __http://lists.suse.com/mailman/listinfo/sles-beta_ > > > Dr. Ing. h.c. F. Porsche Aktiengesellschaft Sitz der Gesellschaft: > Stuttgart Registergericht: Amtsgericht Stuttgart HRB-Nr. 730623 > Vorsitzender des Aufsichtsrats: Dr. Wolfgang Porsche Vorstand: > Matthias M?ller, Vorsitzender Thomas Edig, stv. Vorsitzender Dr. > Oliver Blume, Wolfgang Hatz, Bernhard Maier, Lutz Meschke, > Uwe-Karsten St?dter > > Die vorgenannten Angaben werden jeder E-Mail automatisch > hinzugef?gt. Dies ist kein Anerkenntnis, dass es sich beim Inhalt > dieser E-Mail um eine rechtsverbindliche Erkl?rung der Porsche AG > handelt. Erkl?rungen, die die Porsche AG verpflichten, bed?rfen > jeweils der Unterschrift durch zwei zeichnungs- berechtigte > Personen der AG._______________________________________________ > sles-beta mailing list sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta > > > Dr. Ing. h.c. F. Porsche Aktiengesellschaft Sitz der Gesellschaft: > Stuttgart Registergericht: Amtsgericht Stuttgart HRB-Nr. 730623 > Vorsitzender des Aufsichtsrats: Dr. Wolfgang Porsche Vorstand: > Matthias M?ller, Vorsitzender Thomas Edig, stv. Vorsitzender Dr. > Oliver Blume, Wolfgang Hatz, Bernhard Maier, Lutz Meschke, > Uwe-Karsten St?dter > > Die vorgenannten Angaben werden jeder E-Mail automatisch > hinzugef?gt. Dies ist kein Anerkenntnis, dass es sich beim Inhalt > dieser E-Mail um eine rechtsverbindliche Erkl?rung der Porsche AG > handelt. Erkl?rungen, die die Porsche AG verpflichten, bed?rfen > jeweils der Unterschrift durch zwei zeichnungs- berechtigte > Personen der AG. > > > _______________________________________________ sles-beta mailing > list sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta > - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJUJt4FAAoJEB57S2MheeWy1MsQAMQIWLyfRzrgloR0Gt21rdiF HTtpfgBbsrdxzHWBG9Z2YVBQdjTdC5mQMz81/2aUnqsOX+LO5PznMlShP+3VykUv qXCRxH42D0zKbID2GwAgX7Y3446kmMfHJu70DRgkQMy1n+WzAl7dWXe2dqyCrKlw V+oXto2qZjWJPJ83HKqqDSDDjzCExM4bLVbamdT3O2sLs6fDSM2R8OBA61RdBEwp 1lTQ5ePwIm5E7DyztwyOIN5FutMzKVHyIOq5B5QxQAovQdXJXsl5xfvh7daknTmf oEvpmx2fzJn7qIi3oB+C1PkpcJeSFFJa0HtemRvVRXtUzyiLHkPdIBMAe1NxRjr9 k7io6kvEOTP/CXsHJ8Nuu0r1zev/HvtF3+u6hK15GdNp2qTtFvAdgCGmo3uUwSmF 9CdllKUJgk5SLaNHqf47mXT/2WbX8ygBZA5Dp1EewRJWLOOKz0Kd61ehrm61xdhY 9EfUJAfVu0Hz/WbHuZeAqVRdIQhd82qfoXN1SX1R1rW82LJFK7IVZqGTpLS1EIvC 5Zo3v+bag6ugxi8fCwSmSvfUkQAS/guMMn+1P4Co5pyzLByPM6Zzy2F+g5HoZ52g Gy3ZbMH0gI01T59E3RQCmvc9MmwV+jnshyN3MyY41HopfcjRA4f1cxcib4mgYypJ 8n5Cbx9TUdgQZSWwqev7 =S8xi -----END PGP SIGNATURE-----