From fcrozat at suse.com Mon Aug 4 02:27:14 2014 From: fcrozat at suse.com (Frederic Crozat) Date: Mon, 04 Aug 2014 10:27:14 +0200 Subject: [sles-beta] Disabling auto mounting of DVD/CD In-Reply-To: References: Message-ID: <1407140834.2140.11.camel@par-r81vxc7.par.novell.com> Le vendredi 01 ao?t 2014 ? 22:26 +0000, Harold Longley a ?crit : > For SLES11SP3 and earlier, I was able to use the commands below to > prevent the auto mounting of a DVD/CD. I added these commands to a > post-script in my autoinst.xml file. > > > How can this be done with SLES 12? There is no /apps/nautilus in my > installed system. I tried these commands, but they did not have the > desired effect. > > > # > # Fix up the gnome/nautilus desktop configuration to prevent icon > autocreation and > # automounting of detected filesystems. > # > > > gconftool-2 > --config-source=xml:readwrite:/etc/gconf/gconf.xml.mandatory --direct > --type bool -s /apps/nautilus/preferences/media_automount false > gconftool-2 > --config-source=xml:readwrite:/etc/gconf/gconf.xml.mandatory --direct > --type bool -s /apps/nautilus/preferences/media_automount_open false > gconftool-2 > --config-source=xml:readwrite:/etc/gconf/gconf.xml.mandatory --direct > --type bool -s /apps/nautilus/preferences/media_autorun_never true > gconftool-2 > --config-source=xml:readwrite:/etc/gconf/gconf.xml.mandatory --direct > --type bool -s /apps/nautilus/desktop/volumes_visible false Those old keys should be automatically handled (thanks to GConf to gsettings mapping) but the new keys should be set this way: (the how-to is from https://help.gnome.org/admin/system-admin-guide/stable/dconf-lockdown.html.en ) -to set the default values, create file /etc/dconf/db/local.d/00-defaults containing : [org.gnome.desktop.media-handling] automount=false automount-open=false autorun-never=false [org.gnome.nautilus.desktop] volumes-visible=false - then you need to lock them, by creating /etc/dconf/db/local.d/locks/defaults containing: /org/gnome/desktop/media-handling/automount /org/gnome/desktop/media-handling/automount-open /org/gnome/desktop/media-handling/autorun-never /org/gnome/nautilus/desktop/volumes-visible - and you need to create/update dconf database by running: dconf update (as root) -- Frederic Crozat Project Manager Enterprise Desktop SUSE From fcrozat at suse.com Mon Aug 4 02:27:41 2014 From: fcrozat at suse.com (Frederic Crozat) Date: Mon, 04 Aug 2014 10:27:41 +0200 Subject: [sles-beta] yast-control-center-qt missing In-Reply-To: <2072575.SBevImYi2k@gjn.priv.at> References: <2072575.SBevImYi2k@gjn.priv.at> Message-ID: <1407140861.2140.12.camel@par-r81vxc7.par.novell.com> Le samedi 02 ao?t 2014 ? 15:11 +0200, G?nther J. Niederwimmer a ?crit : > Hello, > > Is this YaSt Module deleted or only missing ? It is replaced by yast2-control-center-gnome. -- Frederic Crozat Project Manager Enterprise Desktop SUSE From gjn at gjn.priv.at Mon Aug 4 03:42:51 2014 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Mon, 04 Aug 2014 11:42:51 +0200 Subject: [sles-beta] yast-control-center-qt missing In-Reply-To: <1407140861.2140.12.camel@par-r81vxc7.par.novell.com> References: <2072575.SBevImYi2k@gjn.priv.at> <1407140861.2140.12.camel@par-r81vxc7.par.novell.com> Message-ID: <2502521.9QYjE7IMRT@gjn.priv.at> Hello, Am Montag, 4. August 2014, 10:27:41 schrieb Frederic Crozat: > Le samedi 02 ao?t 2014 ? 15:11 +0200, G?nther J. Niederwimmer a ?crit : > > Hello, > > > > Is this YaSt Module deleted or only missing ? > > It is replaced by yast2-control-center-gnome. I make a zipper dup in the KVM Clients, this is the first time the qt Version working correct :-)). -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From mge at suse.com Mon Aug 4 03:49:06 2014 From: mge at suse.com (Matthias G. Eckermann) Date: Mon, 4 Aug 2014 11:49:06 +0200 Subject: [sles-beta] Request for Improvement In-Reply-To: References: Message-ID: <20140804094906.GE29555@suse.com> Hello Darren and all, On 2014-08-03 T 16:02 +1000 Darren Thompson wrote: > Sorry if this is not the correct forum for this... > > The LIO ISCSI target service is called target.service > Sadly "target" is an "overloaded" name in systemd > (There are lots of {name}.target files). thanks for your suggestion. I agree that this can lead to confusion. > Would it be possible to rename the target.service to > something more unique > > Possible examples: > > LIO.service > LIOtarget.service We looked into this, and it seems that "target.service" is the name used by the upstream LIO project. Unfortunately. And while deviating from an upstream project in an area where it impacts administrators (system configuration) is possible and sometimes even mandatory for a Linux distribution, in this case we think that working with the upstream project to help them find a better name, and change SUSE Linux Enterprise accordingly afterwards is the right approach. Hope this explains. so long - MgE -- Matthias G. Eckermann Senior Product Manager SUSE? Linux Enterprise Phone: +49 30 44315731 Mobile: +49 179 2949448 E-Mail: mge at suse.com SUSE LINUX Products GmbH Maxfeldstra?e 5 90409 N?rnberg Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) From fcastelli at suse.com Tue Aug 5 02:01:30 2014 From: fcastelli at suse.com (Flavio Castelli) Date: Tue, 05 Aug 2014 10:01:30 +0200 Subject: [sles-beta] SLES12RC1 Docker Ping Problem After Machine Reboot In-Reply-To: References: Message-ID: <53E08F5A.6050106@suse.com> On 08/05/2014 06:23 AM, Bonazzoli Giandomenico - Technogym SPA wrote: > If you reboot a SLES12 RC1 after a successful docker pull & docker run when you retry the docker run the container is without any external connection, so for example ping does just not work. As a quick workaround you can execute this command manually: /usr/sbin/sysctl -p /etc/sysctl.d/200-docker.conf This is done whenever the docker service is started. Do you have some special firewall rule in place? Does the problem happen immediately after you reboot the machine or after some time it has been running? Feel free to contact me privately to discuss this issue if you don't want to share such details here. Cheers Flavio From darrent at akurit.com.au Tue Aug 5 02:38:02 2014 From: darrent at akurit.com.au (Darren Thompson) Date: Tue, 5 Aug 2014 18:38:02 +1000 Subject: [sles-beta] SLES12 x86_64 beta RC1 autoyast network installation not working In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9C1716@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9C1716@HXMB12.pnet.ch> Message-ID: Urs It's possible the autoyast file format has changed (they have been doing lots of work with autoyast over the last few betas/rc). I have recreated my autoyast files and they seem to be working as expected. Darren On 5 August 2014 18:32, wrote: > Hi > > > > I am trying to install SLES12 x86_64 RC1 using my autoyast.xml profile > which was well working with SLES12 Beta9 now with RC1 > > > > With RC1 Linuxrc process asks me the IP address, why?? > > In my info file in the initrd the IP-address is well defined, well working > with beta9 > > > > freyu at v04yf4:~> cat /appl/custom_iso/info_sles12_v03er9 > > netwait: 40 > > splash : verbose > > net.ifnames: 0 > > install: http://172.27.40.68/sles12_64 > > netdevice: eth0 > > hostname: v03er9 > > hostip: 10.1.100.167 > > netmask: 255.255.254.0 > > gateway: 10.1.101.254 > > nameserver: 10.1.121.11 > > autoyast: http://172.27.40.68/pstkits/profiles/sles12_autoinst_v03er9.xml > > netsetup:-dhcp,+hostip,+gateway,+netmask,+nameserver > > udev.rule: "mac=00:50:56:b7:02:a9,name=eth0" > > freyu at v04yf4:~> > > > > When I enter the network address 10.1.100.167/23, all network parameters > are asked, gateway, nameserver, dns search domains, even they are defined > in the info file > > After defining these parameters I get the screen, that the installation > media can not been found > > > > > > With ALT-F9 I can see, that the network did not get defined. So it is > obvious, that the installation media can not been found. > > > > > > I state Network installation with autoyast SLES12 x86_64 RC1 is not > possible due to a bug in Linuxrc Network configuration > > > > 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 > > > > > > _______________________________________________ > sles-beta mailing list > sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta > > -- Darren Thompson Professional Services Engineer / Consultant *[image: cid:image001.jpg at 01CB7C0C.6C6A2AE0]* Level 3, 60 City Road Southgate, VIC 3006 Mb: 0400 640 414 Mail: darrent at akurit.com.au 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 74012 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 77277 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 98217 bytes Desc: not available URL: From urs.frey at post.ch Tue Aug 5 02:42:48 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Tue, 5 Aug 2014 08:42:48 +0000 Subject: [sles-beta] SLES12 x86_64 beta RC1 autoyast network installation not working In-Reply-To: References: <40637DBB36AF3941B243A286A432CA0B0F9C1716@HXMB12.pnet.ch> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9C173E@HXMB12.pnet.ch> Hi Darren It is not autoyast, it is linuxrc causing problems with the network configration. I am not yet in yast, no autoinst.xml profile fetched yet. I am at the very beginning, trying to configure the network in linuxrc getting a connection to me network install server to fetch autoinst.xml later In the changelog Beta10-RC1 I can see the following entries concerning linuxrc ------------------------------------- o Updated linuxrc (security/bugfix/feature) - fix point-to-point interface handling (bnc #889580) - 5.0.8 - pass along hostname if explicitly set (bnc #889374) - 5.0.7 - add missing break - more dead code cleanup - fix evil nameserver config bug - make debugwait option more useful - make log file script behave - 5.0.6 - remove more parts of old network code - remove obsolete config.netdevice - 5.0.5 - ui directly uses new network code, remove obsolete code - remove obsolete yast2_color var - remove sax2 option - don't write network info into /etc/install.inf - remove obsolete pcmcia code - 5.0.4 - fix network setup - 5.0.3 - use wicked to setup static network config - support ptp setups and accept global default netmask value for all ips - put copy of old-style config into new config - better internal logging of network config entries - 5.0.2 - continue network code reworking: - fix network re-config (bnc #887841) - move network setup into separate menu item - move various net_activate_s390_devs() calls into a single place - unify network config code - remove obsolete code - 5.0.1 - fix proxy handling in linuxrc - 5.0.0 - avoid server name resolution - don't resolve proxy name - enable ipv6 by default - clean up cifs and nfs code - fix segfault and accept ipv6 netmasks (bnc 887501) - 4.2.45 --------------------------------- So there have been many changes Obviously the network configuration in the linuxrc process has changed and therefore the info file parameters 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 Von: Darren Thompson [mailto:darrent at akurit.com.au] Gesendet: Tuesday, August 05, 2014 10:38 AM An: Frey Urs, IT222 Cc: sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES12 x86_64 beta RC1 autoyast network installation not working Urs It's possible the autoyast file format has changed (they have been doing lots of work with autoyast over the last few betas/rc). I have recreated my autoyast files and they seem to be working as expected. Darren On 5 August 2014 18:32, > wrote: Hi I am trying to install SLES12 x86_64 RC1 using my autoyast.xml profile which was well working with SLES12 Beta9 now with RC1 With RC1 Linuxrc process asks me the IP address, why?? In my info file in the initrd the IP-address is well defined, well working with beta9 freyu at v04yf4:~> cat /appl/custom_iso/info_sles12_v03er9 netwait: 40 splash : verbose net.ifnames: 0 install: http://172.27.40.68/sles12_64 netdevice: eth0 hostname: v03er9 hostip: 10.1.100.167 netmask: 255.255.254.0 gateway: 10.1.101.254 nameserver: 10.1.121.11 autoyast: http://172.27.40.68/pstkits/profiles/sles12_autoinst_v03er9.xml netsetup:-dhcp,+hostip,+gateway,+netmask,+nameserver udev.rule: "mac=00:50:56:b7:02:a9,name=eth0" freyu at v04yf4:~> [cid:image001.png at 01CFB099.FF864C30] When I enter the network address 10.1.100.167/23, all network parameters are asked, gateway, nameserver, dns search domains, even they are defined in the info file After defining these parameters I get the screen, that the installation media can not been found [cid:image002.png at 01CFB099.FF864C30] With ALT-F9 I can see, that the network did not get defined. So it is obvious, that the installation media can not been found. [cid:image004.png at 01CFB099.FF864C30] I state Network installation with autoyast SLES12 x86_64 RC1 is not possible due to a bug in Linuxrc Network configuration 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 _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta -- Darren Thompson Professional Services Engineer / Consultant [cid:image001.jpg at 01CB7C0C.6C6A2AE0] Level 3, 60 City Road Southgate, VIC 3006 Mb: 0400 640 414 Mail: darrent at akurit.com.au Web: www.akurit.com.au -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 74012 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 77277 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 98217 bytes Desc: image004.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 3692 bytes Desc: image005.jpg URL: From kukuk at suse.de Tue Aug 5 03:16:12 2014 From: kukuk at suse.de (Thorsten Kukuk) Date: Tue, 5 Aug 2014 11:16:12 +0200 Subject: [sles-beta] SLES12 x86_64 beta RC1 autoyast network installation not working In-Reply-To: <53E09EEE.5050909@balabit.hu> References: <40637DBB36AF3941B243A286A432CA0B0F9C1716@HXMB12.pnet.ch> <53E09EEE.5050909@balabit.hu> Message-ID: <20140805091612.GA12407@suse.de> On Tue, Aug 05, Peter Czanik wrote: > Hi, > > On 08/05/2014 10:32 AM, urs.frey at post.ch wrote: > > > >I state Network installation with autoyast SLES12 x86_64 RC1 is > >not possible due to a bug in Linuxrc Network configuration > > > > > Not just Linuxrc. I did a DVD install in vmware. First I could not > register, as there was no network (even after doing "network > configuration" in the upper right corner. Then I tried to set up > networking in the running system, and it did not work either. If you change at this point to tty2: what does "wicked ifstatus all" report? 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 snwint at suse.de Tue Aug 5 04:04:36 2014 From: snwint at suse.de (Steffen Winterfeldt) Date: Tue, 5 Aug 2014 12:04:36 +0200 (CEST) Subject: [sles-beta] [urs.frey@post.ch: SLES12 x86_64 linuxrc pnetwork configuration for autoyast not working] In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9C17DA@HXMB12.pnet.ch> References: <20140805085815.GA11900@suse.de> <40637DBB36AF3941B243A286A432CA0B0F9C17DA@HXMB12.pnet.ch> Message-ID: Hi Urs, On Tue, 5 Aug 2014, urs.frey at post.ch wrote: > Now Linuxrc tells me, that there has been a network configuration created [...] > But I still get the message, that the installation media can not been found [...] > So I state the network configuration gets written, but the network itself does not get started > with this configuration. So, your network doesn't work (ping gets nowhere)? Are the routing data correct? If you start with linuxrc.debug=1 (or 2 for even more) there will be lots of logs in /var/log/wickedd.log. (But I can't help you interpreting those.) Steffen From snwint at suse.de Tue Aug 5 05:05:21 2014 From: snwint at suse.de (Steffen Winterfeldt) Date: Tue, 5 Aug 2014 13:05:21 +0200 (CEST) Subject: [sles-beta] SLES12 x86_64 linuxrc network configuration not working, automated installation not possible In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9C17F6@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9C17F6@HXMB12.pnet.ch> Message-ID: On Tue, 5 Aug 2014, urs.frey at post.ch wrote: > netwait: 40 > > splash : verbose > > net.ifnames: 0 > > install: http://172.27.40.68/sles12_64 > > netdevice: eth0 > > hostname: v03er9 > > hostip: 10.1.100.167/23 > > gateway: 10.1.101.254 > > nameserver: 10.1.121.11 > > autoyast: http://172.27.40.68/pstkits/profiles/sles12_autoinst_v03er9.xml > > udev.rule: "mac=00:50:56:b7:02:a9,name=eth0" > > ? > > But obviously in linuxrc the NIC configuration gets written, but to implement the configured NIC > the network does not get restarted the correct way: In that case, please run with linuxrc.debug=1 linuxrc.log=/foo.log and send me the log. There's one other thing you can try: instead of the network options you used above, use ifcfg: eth0=10.1.100.167/23,10.1.101.254,10.1.121.11 > I can do this manually on the Linuxrc ALT-F9 screen, but unfortunately the installation does not > continue and is not possible Actually you should be able to work your way through linuxrc's dialogs just fine. Steffen From snwint at suse.de Tue Aug 5 06:38:41 2014 From: snwint at suse.de (Steffen Winterfeldt) Date: Tue, 5 Aug 2014 14:38:41 +0200 (CEST) Subject: [sles-beta] SLES12 x86_64 linuxrc network configuration not working, automated installation not possible In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9C188A@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9C17F6@HXMB12.pnet.ch> <40637DBB36AF3941B243A286A432CA0B0F9C188A@HXMB12.pnet.ch> Message-ID: On Tue, 5 Aug 2014, urs.frey at post.ch wrote: > Why does IPV6 configure the network? I have an IPV4 address only configured! I can't really say without a log. :-( If you have only v4 and v6 autoconfig gets in the way, use ipv4only=1. > Second try. There MUST be a netwait of min 40sec because of the check-point firewalls and CISCO > switches!!! Uhm, that might explain it. netwait is currently not applied to static configs (yes, a bug). :-/ For testing, you can use 'debug.wait=net:2501'. Whis will stop right after 'wicked ifup' and offer you a shell for debugging. Just wait there and continue when the network is ready. Steffen From urs.frey at post.ch Tue Aug 5 06:46:59 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Tue, 5 Aug 2014 12:46:59 +0000 Subject: [sles-beta] SLES12 x86_64 linuxrc network configuration not working, automated installation not possible In-Reply-To: References: <40637DBB36AF3941B243A286A432CA0B0F9C17F6@HXMB12.pnet.ch> <40637DBB36AF3941B243A286A432CA0B0F9C188A@HXMB12.pnet.ch> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9C18D7@HXMB12.pnet.ch> Hi Steffen I am sorry, but I cannot continue testing for now. SLES12 is too instable to spend further work on it. No permission anymore from my boss. Because such basic things like automated installation from network do not work, it makes no sense even to try harder. Please tell me if I have to wait for RC2, or if there will be an intermediate fix. 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: Steffen Winterfeldt [mailto:snwint at suse.de] Gesendet: Tuesday, August 05, 2014 2:39 PM An: Frey Urs, IT222 Cc: sles-beta at lists.suse.com Betreff: Re: AW: SLES12 x86_64 linuxrc network configuration not working, automated installation not possible On Tue, 5 Aug 2014, urs.frey at post.ch wrote: > Why does IPV6 configure the network? I have an IPV4 address only configured! I can't really say without a log. :-( If you have only v4 and v6 autoconfig gets in the way, use ipv4only=1. > Second try. There MUST be a netwait of min 40sec because of the check-point firewalls and CISCO > switches!!! Uhm, that might explain it. netwait is currently not applied to static configs (yes, a bug). :-/ For testing, you can use 'debug.wait=net:2501'. Whis will stop right after 'wicked ifup' and offer you a shell for debugging. Just wait there and continue when the network is ready. Steffen From snwint at suse.de Tue Aug 5 06:56:41 2014 From: snwint at suse.de (Steffen Winterfeldt) Date: Tue, 5 Aug 2014 14:56:41 +0200 (CEST) Subject: [sles-beta] SLES12 x86_64 linuxrc network configuration not working, automated installation not possible In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9C18D7@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9C17F6@HXMB12.pnet.ch> <40637DBB36AF3941B243A286A432CA0B0F9C188A@HXMB12.pnet.ch> <40637DBB36AF3941B243A286A432CA0B0F9C18D7@HXMB12.pnet.ch> Message-ID: On Tue, 5 Aug 2014, urs.frey at post.ch wrote: > Hi Steffen > I am sorry, but I cannot continue testing for now. > SLES12 is too instable to spend further work on it. > No permission anymore from my boss. > Because such basic things like automated installation from network do not work, it makes no sense even to try harder. The network code is completely new in sle12; not only wicked itself but also in linuxrc. And not all workarounds are back in place. You are probably just hit by the missing 'netwait'. Steffen From urs.frey at post.ch Tue Aug 5 07:06:17 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Tue, 5 Aug 2014 13:06:17 +0000 Subject: [sles-beta] SLES12 x86_64 linuxrc network configuration not working, automated installation not possible In-Reply-To: References: <40637DBB36AF3941B243A286A432CA0B0F9C17F6@HXMB12.pnet.ch> <40637DBB36AF3941B243A286A432CA0B0F9C188A@HXMB12.pnet.ch> <40637DBB36AF3941B243A286A432CA0B0F9C18D7@HXMB12.pnet.ch> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9C18EF@HXMB12.pnet.ch> Hi Steffen >> Hi Steffen >> I am sorry, but I cannot continue testing for now. >> SLES12 is too instable to spend further work on it. >> No permission anymore from my boss. >> Because such basic things like automated installation from network do not work, it makes no sense even to try harder. > >The network code is completely new in sle12; not only wicked itself but also >in linuxrc. And not all workarounds are back in place. You are probably just >hit by the missing 'netwait'. I do not agree. I tried to start the network manually several times without any success on the ALT-F9 screen. I spent now more than 6 hours without a result, so it is time now to let it be. It is really bad that such things do pop up in a RC release and have not already been noted during beta Best regards Steffen 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: Steffen Winterfeldt [mailto:snwint at suse.de] Gesendet: Tuesday, August 05, 2014 2:57 PM An: Frey Urs, IT222 Cc: sles-beta at lists.suse.com Betreff: Re: AW: AW: SLES12 x86_64 linuxrc network configuration not working, automated installation not possible On Tue, 5 Aug 2014, urs.frey at post.ch wrote: > Hi Steffen > I am sorry, but I cannot continue testing for now. > SLES12 is too instable to spend further work on it. > No permission anymore from my boss. > Because such basic things like automated installation from network do not work, it makes no sense even to try harder. The network code is completely new in sle12; not only wicked itself but also in linuxrc. And not all workarounds are back in place. You are probably just hit by the missing 'netwait'. Steffen From urs.frey at post.ch Tue Aug 5 07:20:53 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Tue, 5 Aug 2014 13:20:53 +0000 Subject: [sles-beta] SLES12 x86_64 linuxrc network configuration not working, automated installation not possible In-Reply-To: References: <40637DBB36AF3941B243A286A432CA0B0F9C17F6@HXMB12.pnet.ch> <40637DBB36AF3941B243A286A432CA0B0F9C188A@HXMB12.pnet.ch> <40637DBB36AF3941B243A286A432CA0B0F9C18D7@HXMB12.pnet.ch> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9C1905@HXMB12.pnet.ch> Hi Peter This might indeed be the case, because Steffen wrote: >If you have only v4 and v6 autoconfig gets in the way, use ipv4only=1. I could observe, when not booting with ipv6=0 ipv4=1 ipv4only=1, then IPV6 did autoconfigure to DHCP and no more ipv4 configuration was possible. So there something does mix up the entire network configuration process. 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 Von: Czanik, P?ter [mailto:peter.czanik at balabit.com] Gesendet: Tuesday, August 05, 2014 3:15 PM An: Steffen Winterfeldt Cc: Frey Urs, IT222; sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES12 x86_64 linuxrc network configuration not working, automated installation not possible Hi, On Tue, Aug 5, 2014 at 2:56 PM, Steffen Winterfeldt > wrote: On Tue, 5 Aug 2014, urs.frey at post.ch wrote: Hi Steffen I am sorry, but I cannot continue testing for now. SLES12 is too instable to spend further work on it. No permission anymore from my boss. Because such basic things like automated installation from network do not work, it makes no sense even to try harder. The network code is completely new in sle12; not only wicked itself but also in linuxrc. And not all workarounds are back in place. You are probably just hit by the missing 'netwait'. No, as I wrote, I could not setup networking on the running system either. Just a guess: could it be a problem, that I also have an IPv4 only environment? Bye, -- Peter Czanik (CzP) > BalaBit IT Security / syslog-ng upstream http://czanik.blogs.balabit.com/ https://twitter.com/PCzanik -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.czanik at balabit.com Tue Aug 5 07:14:47 2014 From: peter.czanik at balabit.com (=?UTF-8?B?Q3phbmlrLCBQw6l0ZXI=?=) Date: Tue, 5 Aug 2014 15:14:47 +0200 Subject: [sles-beta] SLES12 x86_64 linuxrc network configuration not working, automated installation not possible In-Reply-To: References: <40637DBB36AF3941B243A286A432CA0B0F9C17F6@HXMB12.pnet.ch> <40637DBB36AF3941B243A286A432CA0B0F9C188A@HXMB12.pnet.ch> <40637DBB36AF3941B243A286A432CA0B0F9C18D7@HXMB12.pnet.ch> Message-ID: Hi, On Tue, Aug 5, 2014 at 2:56 PM, Steffen Winterfeldt wrote: > On Tue, 5 Aug 2014, urs.frey at post.ch wrote: > > Hi Steffen >> I am sorry, but I cannot continue testing for now. >> SLES12 is too instable to spend further work on it. >> No permission anymore from my boss. >> Because such basic things like automated installation from network do not >> work, it makes no sense even to try harder. >> > > The network code is completely new in sle12; not only wicked itself but > also > in linuxrc. And not all workarounds are back in place. You are probably > just > hit by the missing 'netwait'. No, as I wrote, I could not setup networking on the running system either. Just a guess: could it be a problem, that I also have an IPv4 only environment? Bye, -- Peter Czanik (CzP) BalaBit IT Security / syslog-ng upstream http://czanik.blogs.balabit.com/ https://twitter.com/PCzanik -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbrown at suse.de Tue Aug 5 07:33:54 2014 From: rbrown at suse.de (Richard Brown) Date: Tue, 05 Aug 2014 15:33:54 +0200 Subject: [sles-beta] SLES12 x86_64 linuxrc network configuration not working, automated installation not possible In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9C18EF@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9C17F6@HXMB12.pnet.ch> <40637DBB36AF3941B243A286A432CA0B0F9C188A@HXMB12.pnet.ch> <40637DBB36AF3941B243A286A432CA0B0F9C18D7@HXMB12.pnet.ch> <40637DBB36AF3941B243A286A432CA0B0F9C18EF@HXMB12.pnet.ch> Message-ID: <1407245634.9681.50.camel@ibrokeit.suse.de> Hi Urs, On Tue, 2014-08-05 at 13:06 +0000, urs.frey at post.ch wrote: > >> Because such basic things like automated installation from network > do not work, it makes no sense even to try harder. I do not mean this to sound argumentative, but I have tested automatic installation from network with every combination of static/dhcp/autoconf, on both IPv4, IPv6 and IPv4+IPv6 Networks To imply that it 'does not work' would be incorrect - although I don't deny that it clearly is having problems in your environment. I understand your frustration, but if you are able to provide Steffen with the logs he's requested and/or testing his suggested 'debug.wait=net:2501' , you would be helping us not only solve the issue for yourself and others, but hopefully providing enough information that it can lead to better informed test cases so we can catch these things earlier in the future Kind Regards, Richard Brown -- Richard Brown QA Engineer openSUSE Chairman Phone +4991174053-361 SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Geschaeftsfuehrer: Jeff Hawn, Jennifer Guild, Felix Imendoerffer, HRB 16746 (AG Nuernberg) From kukuk at suse.de Tue Aug 5 07:36:16 2014 From: kukuk at suse.de (Thorsten Kukuk) Date: Tue, 5 Aug 2014 15:36:16 +0200 Subject: [sles-beta] SLES12 x86_64 linuxrc network configuration not working, automated installation not possible In-Reply-To: References: <40637DBB36AF3941B243A286A432CA0B0F9C17F6@HXMB12.pnet.ch> <40637DBB36AF3941B243A286A432CA0B0F9C188A@HXMB12.pnet.ch> <40637DBB36AF3941B243A286A432CA0B0F9C18D7@HXMB12.pnet.ch> Message-ID: <20140805133616.GA6173@suse.de> On Tue, Aug 05, Czanik, P?ter wrote: > No, as I wrote, I could not setup networking on the running system either. > Just a guess: could it be a problem, that I also have an IPv4 only > environment? To answer that, we would at minimum need the data I asked you already for today. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) From urs.frey at post.ch Tue Aug 5 08:08:06 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Tue, 5 Aug 2014 14:08:06 +0000 Subject: [sles-beta] SLES12 x86_64 linuxrc network configuration not working, automated installation not possible In-Reply-To: <1407245634.9681.50.camel@ibrokeit.suse.de> References: <40637DBB36AF3941B243A286A432CA0B0F9C17F6@HXMB12.pnet.ch> <40637DBB36AF3941B243A286A432CA0B0F9C188A@HXMB12.pnet.ch> <40637DBB36AF3941B243A286A432CA0B0F9C18D7@HXMB12.pnet.ch> <40637DBB36AF3941B243A286A432CA0B0F9C18EF@HXMB12.pnet.ch> <1407245634.9681.50.camel@ibrokeit.suse.de> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9C1945@HXMB12.pnet.ch> Hi Richard >I understand your frustration, but if you are able to provide Steffen >with the logs he's requested and/or testing his suggested It is not that I do not want to, but there are simply too many thins missing, mixed up and wrong. As you can see below, I tried to boot using debug.wait=net:2501 and I entered the shell, but this shell is not usable on v-sphere VMWare ESXi console Here my protocol [cid:image001.png at 01CFB0C4.0B93ADE0] [cid:image002.png at 01CFB0C4.922B3EE0] I used again ALT-F9 and on this screen I entered # ifdown eth0 # ifup eth0 This way I could start the network and the installation. Autoyast second stage. As you can see, on the black screen nothing can be really seen the right way [cid:image003.png at 01CFB0C6.EE98D3C0] After the installation I would of course see the linuxrc.log=/foo.log file but nothing can be found So how to continue?? [cid:image004.png at 01CFB0C6.EE98D3C0] So how to provide a log file for further treatment and debugging, when this logfile is not persistent in the system and can not be found after installation? See, all this takes a lot of time, where I do not have credits anymore Of course I would be interested in having a working SLES12. But the way to there is to frustrating at the moment 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: Richard Brown [mailto:rbrown at suse.de] Gesendet: Tuesday, August 05, 2014 3:34 PM An: Frey Urs, IT222 Cc: snwint at suse.de; sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES12 x86_64 linuxrc network configuration not working, automated installation not possible Hi Urs, On Tue, 2014-08-05 at 13:06 +0000, urs.frey at post.ch wrote: > >> Because such basic things like automated installation from network > do not work, it makes no sense even to try harder. I do not mean this to sound argumentative, but I have tested automatic installation from network with every combination of static/dhcp/autoconf, on both IPv4, IPv6 and IPv4+IPv6 Networks To imply that it 'does not work' would be incorrect - although I don't deny that it clearly is having problems in your environment. I understand your frustration, but if you are able to provide Steffen with the logs he's requested and/or testing his suggested 'debug.wait=net:2501' , you would be helping us not only solve the issue for yourself and others, but hopefully providing enough information that it can lead to better informed test cases so we can catch these things earlier in the future Kind Regards, Richard Brown -- Richard Brown QA Engineer openSUSE Chairman Phone +4991174053-361 SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Geschaeftsfuehrer: Jeff Hawn, Jennifer Guild, Felix Imendoerffer, HRB 16746 (AG Nuernberg) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 114429 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 47879 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 65952 bytes Desc: image003.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 196651 bytes Desc: image004.png URL: From snwint at suse.de Tue Aug 5 08:19:05 2014 From: snwint at suse.de (Steffen Winterfeldt) Date: Tue, 5 Aug 2014 16:19:05 +0200 (CEST) Subject: [sles-beta] SLES12 x86_64 linuxrc network configuration not working, automated installation not possible In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9C1945@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9C17F6@HXMB12.pnet.ch> <40637DBB36AF3941B243A286A432CA0B0F9C188A@HXMB12.pnet.ch> <40637DBB36AF3941B243A286A432CA0B0F9C18D7@HXMB12.pnet.ch> <40637DBB36AF3941B243A286A432CA0B0F9C18EF@HXMB12.pnet.ch> <1407245634.9681.50.camel@ibrokeit.suse.de> <40637DBB36AF3941B243A286A432CA0B0F9C1945@HXMB12.pnet.ch> Message-ID: On Tue, 5 Aug 2014, urs.frey at post.ch wrote: > As you can see below, I tried to boot using debug.wait=net:2501 and I entered the shell, but > this shell is not usable on v-sphere VMWare ESXi console [...] > I used again ALT-F9 and on this screen I entered > > # ifdown eth0 > > # ifup eth0 > > This way I could start the network and the installation. Thanks! This at least indicates that it's the missing netwait in your case. > After the installation I would of course see the linuxrc.log=/foo.log file but nothing can be > found > > So how to continue?? What I usually do is using startshell=1 and starting an sshd (service_start sshd + setting a password). Steffen From kukuk at suse.de Tue Aug 5 08:51:07 2014 From: kukuk at suse.de (Thorsten Kukuk) Date: Tue, 5 Aug 2014 16:51:07 +0200 Subject: [sles-beta] SLES12 x86_64 RC1 where can I find facter? In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9C1997@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9C1997@HXMB12.pnet.ch> Message-ID: <20140805145107.GA11160@suse.de> On Tue, Aug 05, urs.frey at post.ch wrote: > Hi > > When having installed SLES12 x86_64 RC1 and I want to use puppet together with some facts, I can not find facter > On the installation media the package facter seems to be missing > > WHY? facter was moved together with puppet to the adv. system management module. Thorsten > In Beta9 the package facter was still there > > v03g27:/data/sles_install_sources # find sles12_* | grep facter > sles12_64_beta9/suse/x86_64/facter-2.0.1-1.2.x86_64.rpm > v03g27:/data/sles_install_sources # > > What is the reason to ban the package facter from the SLES12 media > > freyu at h039uc:~/sles12> zgrep facter ChangeLog-Beta* > ChangeLog-Beta5-Beta6.txt.gz:- require facter > 1.6.0 as upstream does > ChangeLog-Beta6-Beta7.txt.gz:o Updated facter (security/bugfix/feature) > ChangeLog-Beta6-Beta7.txt.gz: * http://docs.puppetlabs.com/facter/1.7/release_notes.html > ChangeLog-Beta6-Beta7.txt.gz: * http://docs.puppetlabs.com/facter/2.0/release_notes.html > freyu at h039uc:~/sles12> > > > I mean when using puppet, facter is a MUST and basic > > Thanks you your answer > > 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 > > > > _______________________________________________ > sles-beta mailing list > sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta -- 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 ronny.pretzsch at dfs.de Tue Aug 5 09:08:10 2014 From: ronny.pretzsch at dfs.de (Ronny Pretzsch) Date: Tue, 5 Aug 2014 17:08:10 +0200 Subject: [sles-beta] SLES12 RC1 Installation - a first impression Message-ID: <1407251290.28735.2.camel@ronnylinux.prod.bk.dfs> Hello, For now we are very disappointed by this so called "Release Candidate". As posted before with beta 10: Basic Autoyast things do not work. (1) If you use a classic root + separate boot partition the system does not boot into stage 2 unless you explicitly activate the boot partition in the xml file. https://bugzilla.novell.com/show_bug.cgi?id=889687 (2) Still the network config from autoyast.xml is not applied in stage1, thus registering with SMT / Customer Center is impossible. https://bugzilla.novell.com/show_bug.cgi?id=890073 (3) The autoyast init-script is still executed while the login prompt (tty1-6) appears. Thus the user thinks the system is ready while it's not. (4) After manual installation with setting up network config early and registering to SMT the resulting /root/autoinst.xml does not contain any hint of this. https://bugzilla.novell.com/show_bug.cgi?id=890074 (5) After manunal installation with firewall enabled (default) the resulting /root/autoinst.xml does not contain a firewall section. 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 From ronny.pretzsch at dfs.de Tue Aug 5 09:23:12 2014 From: ronny.pretzsch at dfs.de (Ronny Pretzsch) Date: Tue, 5 Aug 2014 17:23:12 +0200 Subject: [sles-beta] SLES12 RC1 Manual installation Message-ID: <1407252192.29583.2.camel@ronnylinux.prod.bk.dfs> Hello again, we have a local SMT-Beta running on SLES11 SP3: smt-2.0.0-0.12.1 We started SLES12 RC1 Installer (PXE), configuring the network early and pressing the "Local Registration Server" Button. Here we entered "http:///" Then we clicked "Next" and a saw the following error: Then We could continue the installation with no obvious problems (clicking "Next"). Afterwards the system was successfully registered to the SMT. But as mentioned the /root/autoyast.xml file did not contain this. Ronny Pretzsch -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-1.png Type: image/png Size: 13429 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot.png Type: image/png Size: 10225 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: y2log-1.gz Type: application/x-gzip Size: 517642 bytes Desc: not available URL: -------------- next part -------------- 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 From lslezak at suse.cz Wed Aug 6 01:57:52 2014 From: lslezak at suse.cz (Ladislav Slezak) Date: Wed, 06 Aug 2014 09:57:52 +0200 Subject: [sles-beta] SLES12 RC1 Manual installation In-Reply-To: <1407252192.29583.2.camel@ronnylinux.prod.bk.dfs> References: <1407252192.29583.2.camel@ronnylinux.prod.bk.dfs> Message-ID: <53E1E000.20800@suse.cz> Hello, Dne 5.8.2014 17:23, Ronny Pretzsch napsal(a): > Hello again, > > we have a local SMT-Beta running on SLES11 SP3: > smt-2.0.0-0.12.1 > > We started SLES12 RC1 Installer (PXE), > configuring the network early and > pressing the "Local Registration Server" Button. > Here we entered "http:///" > > Then we clicked "Next" and a saw the following error: The "Details: Not Found" indicates HTTP Error 404 (Not Found), according to the log the base product registration succeeded. Yast then wants to download the list of available extensions. That also succeeded, but the next SMT call which should download the extension status (to know which extensions were already activated) it fails with 404 error. I just have tested a SMT installation and it was OK for me, but the testing instance I used is not maintained by me so I actually do not know the exact version which is deployed, but it should be a development instance with the latest version... IIRC this extensions status call was added recently, could you verify that your SMT server is running the latest SMT-Beta release? Anyway, yast should not crash in that situation, looks like a missing error handling. Please open a bug report for this issue. -- Ladislav Slez?k Appliance department / YaST Developer Lihovarsk? 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak at suse.com SUSE From jsrain at suse.cz Wed Aug 6 03:35:48 2014 From: jsrain at suse.cz (Jiri Srain) Date: Wed, 06 Aug 2014 11:35:48 +0200 Subject: [sles-beta] SLES12 RC1 Manual installation In-Reply-To: <53E1E000.20800@suse.cz> References: <1407252192.29583.2.camel@ronnylinux.prod.bk.dfs> <53E1E000.20800@suse.cz> Message-ID: <53E1F6F4.2050802@suse.cz> Hello, On 08/06/2014 09:57 AM, Ladislav Slezak wrote: > Hello, > > Dne 5.8.2014 17:23, Ronny Pretzsch napsal(a): >> Hello again, >> >> we have a local SMT-Beta running on SLES11 SP3: >> smt-2.0.0-0.12.1 >> >> We started SLES12 RC1 Installer (PXE), >> configuring the network early and >> pressing the "Local Registration Server" Button. >> Here we entered "http:///" >> >> Then we clicked "Next" and a saw the following error: > > The "Details: Not Found" indicates HTTP Error 404 (Not Found), > according to the log the base product registration succeeded. > > Yast then wants to download the list of available extensions. > That also succeeded, but the next SMT call which should > download the extension status (to know which extensions were > already activated) it fails with 404 error. > > I just have tested a SMT installation and it was OK for me, > but the testing instance I used is not maintained by me so I actually > do not know the exact version which is deployed, but it should be > a development instance with the latest version... I intend to provide a new testing version of SMT, I believe that the announcement will go to sles-beta list during this week. > IIRC this extensions status call was added recently, could you verify > that your SMT server is running the latest SMT-Beta release? The used version is currently the latest available. Please, wait a few days before next testing attempt. Sorry for inconvenience, Jiri -- 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 ronny.pretzsch at dfs.de Wed Aug 6 04:40:11 2014 From: ronny.pretzsch at dfs.de (Ronny Pretzsch) Date: Wed, 6 Aug 2014 12:40:11 +0200 Subject: [sles-beta] RC1 NRPE Package (nagios) Message-ID: <1407321611.7092.12.camel@ronnylinux.prod.bk.dfs> Hi, We added SLES, SDK and Adv.Sysmgmt as install sources. There seems to be a srcpackage "nrpe". But there is no package "nrpe" - only the plugin. 0 testvm002:~ # zypper se nrpe Loading repository data... Reading installed packages... S | Name | Summary | Type --+-------------------------+--------------------------------+----------- i | monitoring-plugins-nrpe | NRPE plugin | package | nrpe | Nagios Remote Plug-In Executor | srcpackage We tried to install the srcpackage, but it fails: 0 testvm002:~ # zypper in -t srcpackage nrpe Loading repository data... Reading installed packages... Resolving package dependencies... The following source package is going to be installed: nrpe 1 source package to install. Overall download size: 438.1 KiB. Already cached: 0 B After the operation, additional 447.1 KiB will be used. Continue? [y/n/? shows all options] (y): Media source 'http://install.prod.bk.dfs/sles12-64' does not contain the desired medium Abort, retry, ignore? [a/r/i/? shows all options] (a): Problem occured during or after installation or removal of packages: Installation aborted by user What's wrong with the install medium? Are there any plans to provide the nrpe binary (server - usually started by xinetd) in SLE12? The mere plugin makes no sence, does it? We use nrpe to monitor our systems with nagios/icinga. In SLE11 we compiled nrpe by ourselves. 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 From kukuk at suse.de Wed Aug 6 05:14:53 2014 From: kukuk at suse.de (Thorsten Kukuk) Date: Wed, 6 Aug 2014 13:14:53 +0200 Subject: [sles-beta] RC1 NRPE Package (nagios) In-Reply-To: <1407321611.7092.12.camel@ronnylinux.prod.bk.dfs> References: <1407321611.7092.12.camel@ronnylinux.prod.bk.dfs> Message-ID: <20140806111453.GA14801@suse.de> On Wed, Aug 06, Ronny Pretzsch wrote: > 1 source package to install. > Overall download size: 438.1 KiB. Already cached: 0 B After the > operation, additional 447.1 KiB will be used. > Continue? [y/n/? shows all options] (y): > Media source 'http://install.prod.bk.dfs/sles12-64' does not contain the > desired medium The URL looks wrong. You should have something like: http://install.prod.bk.dfs/sles12-64/DVD1 http://install.prod.bk.dfs/sles12-64/DVD2 Else YaST cannot automatically change the DVD. 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 schubi at suse.de Wed Aug 6 09:19:00 2014 From: schubi at suse.de (Stefan Schubert) Date: Wed, 06 Aug 2014 17:19:00 +0200 Subject: [sles-beta] SLES12 RC1 Installation - a first impression In-Reply-To: <1407251290.28735.2.camel@ronnylinux.prod.bk.dfs> References: <1407251290.28735.2.camel@ronnylinux.prod.bk.dfs> Message-ID: <53E24764.9020309@suse.de> Hello, thanks for bringing up that points and reported it. So we can take care about. This feedback is important for us, in order to set the priorities of bug fixing. But some of these bugs have been reported too late for RC1. So we have had no chance to fix it. Now we will go through this list and will set the priorities again for RC2. Am 05.08.2014 17:08, schrieb Ronny Pretzsch: > > (3) > The autoyast init-script is still executed while the login prompt > (tty1-6) appears. Thus the user thinks the system is ready while it's > not. I have not found an bugzilla entry. Could you please generate one ? > > (4) > After manual installation with setting up network config early and > registering to SMT the resulting /root/autoinst.xml does not contain any > hint of this. > https://bugzilla.novell.com/show_bug.cgi?id=890074 > > (5) > After manunal installation with firewall enabled (default) the resulting /root/autoinst.xml does not contain a firewall section. This is reported in: https://bugzilla.novell.com/show_bug.cgi?id=887406 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 pwieczorkiewicz at suse.de Wed Aug 6 23:39:17 2014 From: pwieczorkiewicz at suse.de (Pawel Wieczorkiewicz) Date: Thu, 7 Aug 2014 07:39:17 +0200 Subject: [sles-beta] SLES12 x86_64 RC1 installation on HP ProliantBlade 460cGen8 network does not work In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9C1C91@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9C1C91@HXMB12.pnet.ch> Message-ID: <20140807073917.67efb9ed@DELL> On Wed, 6 Aug 2014 13:42:30 +0000 wrote: > Hi > When installing SLES12 x86_64 on HP Proliangt Blade BL460c-Gen8 using > the boot parameters ipv4=1 ipv6=0 ipv4only, the installation does > work, but afterwards the network is dead > > # wicked ifstatus eth0 does show me the following > > [cid:image001.png at 01CFB18C.6B748590] > > Somehow the static network configuration does not get applied > [cid:image002.png at 01CFB18C.6B748590] > > So in my mind there is a bug again with wicked preventing my server > from having network connection > > The device is known, but it is not taken. Wicked takes eth0 as > unknown device [cid:image003.png at 01CFB18D.04417EE0] > > I am really not happy about this, because the installation did work > perfectly under SLES12 Beta9, with this configuration and > autoinst.xml It also works best under SLES11-SP3 > > 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 > > Hi, Thank you for reporting this. I believe this has been already fixed in 0.6.1 version of wicked, but to be sure I would need to look into the logs of wickedd and wickedd-nanny. I think the logs attached to: Bug 890643 - wicked doesn't wait long enough on large networks (https://bugzilla.novell.com/show_bug.cgi?id=890643) already correspond to this issue, isn't it? Otherwise could you please attach new logs as per instruction: ? set DEBUG=all in /etc/sysconfig/network/config ? systemctl restart wickedd ? wicked --debug all ifup all # systemctl restart wicked ? wicked ifstatus all > status.log ? wicked show-config > configs.log ? journalctl -b -o short-iso > wicked.log Thank you. P.S. If you are willing to re-test with wicked 0.6.1, I can provide you with the RPMs. Just tell me... -- Best Regards, Pawel Wieczorkiewicz , Linux System Developer SUSE LINUX Products GmbH GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) Maxfeldstr. 5 / D-90409 N?rnberg / Phone: +49-911-740 53 - 613 From urs.frey at post.ch Thu Aug 7 04:03:40 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Thu, 7 Aug 2014 10:03:40 +0000 Subject: [sles-beta] SLES12 x86_64 RC1 installation on HP ProliantBlade 460cGen8 network does not work In-Reply-To: <20140807073917.67efb9ed@DELL> References: <40637DBB36AF3941B243A286A432CA0B0F9C1C91@HXMB12.pnet.ch> <20140807073917.67efb9ed@DELL> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9C5FD9@HXMB12.pnet.ch> Hi Pawel >Thank you for reporting this. >>I believe this has been already fixed in 0.6.1 version of wicked, but >to be sure I would need to look into the logs of wickedd and >wickedd-nanny. >I think the logs attached to: >Bug 890643 - wicked doesn't wait long enough on large networks >(https://bugzilla.novell.com/show_bug.cgi?id=890643) >already correspond to this issue, isn't it? NO this is not the case, because these are the logfiles from LINUXRC from a server installation on VMware ESXi >Otherwise could you please attach new logs as per instruction: > >? set DEBUG=all in /etc/sysconfig/network/config >? systemctl restart wickedd >? wicked --debug all ifup all # systemctl restart wicked >? wicked ifstatus all > status.log [cid:image006.png at 01CFB236.CDD10740] >? wicked show-config > configs.log [cid:image004.jpg at 01CFB237.9FD22AD0] [cid:image005.jpg at 01CFB237.9FD22AD0] >? journalctl -b -o short-iso > wicked.log > >Thank you. > >P.S. If you are willing to re-test with wicked 0.6.1, I can provide you >with the RPMs. Just tell me... Because I cannot get the network running at all, there is no way to get logfiles out of the system I would really like to send you the logs requested, but any idea to get the network running? This is from grep wicked /var/log/messages. You can only see, that wicked somehow [cid:image003.png at 01CFB237.3A5FB550] This is from ipup eth0 in wicked debug mode [cid:image008.png at 01CFB237.9FD22AD0] 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 Pawel Wieczorkiewicz Gesendet: Thursday, August 07, 2014 7:39 AM An: sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES12 x86_64 RC1 installation on HP ProliantBlade 460cGen8 network does not work On Wed, 6 Aug 2014 13:42:30 +0000 > wrote: > Hi > When installing SLES12 x86_64 on HP Proliangt Blade BL460c-Gen8 using > the boot parameters ipv4=1 ipv6=0 ipv4only, the installation does > work, but afterwards the network is dead > > # wicked ifstatus eth0 does show me the following > > [cid:image001.png at 01CFB18C.6B748590] > > Somehow the static network configuration does not get applied > [cid:image002.png at 01CFB18C.6B748590] > > So in my mind there is a bug again with wicked preventing my server > from having network connection > > The device is known, but it is not taken. Wicked takes eth0 as > unknown device [cid:image003.png at 01CFB18D.04417EE0] > > I am really not happy about this, because the installation did work > perfectly under SLES12 Beta9, with this configuration and > autoinst.xml It also works best under SLES11-SP3 > > 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> > > Hi, Thank you for reporting this. I believe this has been already fixed in 0.6.1 version of wicked, but to be sure I would need to look into the logs of wickedd and wickedd-nanny. I think the logs attached to: Bug 890643 - wicked doesn't wait long enough on large networks (https://bugzilla.novell.com/show_bug.cgi?id=890643) already correspond to this issue, isn't it? Otherwise could you please attach new logs as per instruction: ? set DEBUG=all in /etc/sysconfig/network/config ? systemctl restart wickedd ? wicked --debug all ifup all # systemctl restart wicked ? wicked ifstatus all > status.log ? wicked show-config > configs.log ? journalctl -b -o short-iso > wicked.log Thank you. P.S. If you are willing to re-test with wicked 0.6.1, I can provide you with the RPMs. Just tell me... -- Best Regards, Pawel Wieczorkiewicz >, Linux System Developer SUSE LINUX Products GmbH GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) Maxfeldstr. 5 / D-90409 N?rnberg / Phone: +49-911-740 53 - 613 _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.png Type: image/png Size: 72198 bytes Desc: image006.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 528380 bytes Desc: image003.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 97834 bytes Desc: image004.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 63940 bytes Desc: image005.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image008.png Type: image/png Size: 258112 bytes Desc: image008.png URL: From jsrain at suse.cz Thu Aug 7 04:41:59 2014 From: jsrain at suse.cz (Jiri Srain) Date: Thu, 07 Aug 2014 12:41:59 +0200 Subject: [sles-beta] New testing snapshot of SMT11-SP3 update available Message-ID: <53E357F7.9060809@suse.cz> Dear SLES12 testers, testing version of SMT, which allows registration of SLES12 RC1, is now available at http://beta.suse.com/private/SMT-Beta/ Please, update to this version, otherwise SLES12 RC1 installer reports an error during registration against SMT (as already reported on sles-beta list) This version also solves reported errors during upgrade from SLE11, when registered against SMT. For updating, make sure to use the latest repo, as referenced at the URL above. 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 From ronny.pretzsch at dfs.de Thu Aug 7 06:48:49 2014 From: ronny.pretzsch at dfs.de (Ronny Pretzsch) Date: Thu, 7 Aug 2014 14:48:49 +0200 Subject: [sles-beta] RC1 NRPE Package (nagios) In-Reply-To: <20140806111453.GA14801@suse.de> References: <1407321611.7092.12.camel@ronnylinux.prod.bk.dfs> <20140806111453.GA14801@suse.de> Message-ID: <1407415729.26168.5.camel@ronnylinux.prod.bk.dfs> On Wed, 2014-08-06 at 13:14 +0200, Thorsten Kukuk wrote: > On Wed, Aug 06, Ronny Pretzsch wrote: > > > 1 source package to install. > > Overall download size: 438.1 KiB. Already cached: 0 B After the > > operation, additional 447.1 KiB will be used. > > Continue? [y/n/? shows all options] (y): > > Media source 'http://install.prod.bk.dfs/sles12-64' does not contain the > > desired medium > > The URL looks wrong. > You should have something like: > http://install.prod.bk.dfs/sles12-64/DVD1 > http://install.prod.bk.dfs/sles12-64/DVD2 > The URL is correct. Otherwise "zypper search" would not work at all and I could not install other packages. But I can. Behind that URL is DVD1 only - I did not use DVD2 in any way. To my knowledge DVD2 contains only srpms and is not necessary for installation. If the nrpe srcpackage is on DVD2 (what I assume) then "zypper search" must not find nrpe srcpackage as the metadata of DVD1 should not contain any (src)packages from DVD2. Or am I getting anything wrong? 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 From kukuk at suse.de Thu Aug 7 06:55:45 2014 From: kukuk at suse.de (Thorsten Kukuk) Date: Thu, 7 Aug 2014 14:55:45 +0200 Subject: [sles-beta] RC1 NRPE Package (nagios) In-Reply-To: <1407415729.26168.5.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> Message-ID: <20140807125545.GA4404@suse.de> On Thu, Aug 07, Ronny Pretzsch wrote: > On Wed, 2014-08-06 at 13:14 +0200, Thorsten Kukuk wrote: > > On Wed, Aug 06, Ronny Pretzsch wrote: > > > > > 1 source package to install. > > > Overall download size: 438.1 KiB. Already cached: 0 B After the > > > operation, additional 447.1 KiB will be used. > > > Continue? [y/n/? shows all options] (y): > > > Media source 'http://install.prod.bk.dfs/sles12-64' does not contain the > > > desired medium > > > > The URL looks wrong. > > You should have something like: > > http://install.prod.bk.dfs/sles12-64/DVD1 > > http://install.prod.bk.dfs/sles12-64/DVD2 > > > > The URL is correct. Otherwise "zypper search" would not work at > all and I could not install other packages. But I can. Your setup does not work as you see above: zypper cannot find your source RPM. > Behind that URL is DVD1 only - I did not use DVD2 in any way. > To my knowledge DVD2 contains only srpms and is not necessary for installation. Correct, byt you tried to install a source RPM: "We tried to install the srcpackage". > If the nrpe srcpackage is on DVD2 (what I assume) then "zypper search" must not find nrpe srcpackage as the metadata of DVD1 should not contain any (src)packages from DVD2. Or am I getting anything wrong? The meta data on DVD1 contains all RPMs of that product, regardless on which DVD it is. This is the case since over 15 years for all products shipped on multiple medias and hasn't changed. And if your installation setup would be correct (DVD1 and DVD2 at the end of the URL), zypper could switch correctly between the medias. If you burn the ISO images to a media, zypper will ask you to switch the DVD. 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 S.M.Flood at ucs.cam.ac.uk Thu Aug 7 07:11:12 2014 From: S.M.Flood at ucs.cam.ac.uk (Simon Flood) Date: Thu, 07 Aug 2014 14:11:12 +0100 Subject: [sles-beta] RC1 NRPE Package (nagios) In-Reply-To: <20140807125545.GA4404@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> Message-ID: <53E37AF0.8090705@ucs.cam.ac.uk> On 07/08/2014 13:55, Thorsten Kukuk wrote: > Correct, byt you tried to install a source RPM: > "We tried to install the srcpackage". I think Ronny tried installing the srcpackage because they couldn't install the nrpe package as per > There seems to be a srcpackage "nrpe". > But there is no package "nrpe" - only the plugin. So where is nagios-nrpe or any other nagios packages in SLES12? They'res not in SLES12 RC1 DVD1, mini, modules (legacy, adv. system mgmt, web scripting) or Workstation Extension. There is a monitoring-plugins-nrpe package which I believe is the new name for nagios-plugins-nrpe (as was in SLES11). Thanks, Simon -- Simon Flood Senior Systems Specialist University of Cambridge United Kingdom Novell/SUSE/NetIQ Knowledge Partner From pwieczorkiewicz at suse.de Thu Aug 7 09:08:04 2014 From: pwieczorkiewicz at suse.de (Pawel Wieczorkiewicz) Date: Thu, 7 Aug 2014 17:08:04 +0200 Subject: [sles-beta] [ANNOUNCE] SLES12 RC1 wicked update Message-ID: <20140807170804.2d2627cf@wioo.suse.de> Hi, Please be informed that wicked version 0.6.1 has been released for SLES12 RC1 online update. This version will not help with installation issues (new ISO is required here), but it will help with network configuration failures after boot-up. Please test. Thank you. -- Best Regards, Pawel Wieczorkiewicz , Linux System Developer SUSE LINUX Products GmbH GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) Maxfeldstr. 5 / D-90409 N?rnberg / Phone: +49-911-740 53 - 613 From czanik at balabit.hu Thu Aug 7 09:40:22 2014 From: czanik at balabit.hu (Peter Czanik) Date: Thu, 07 Aug 2014 17:40:22 +0200 Subject: [sles-beta] [ANNOUNCE] SLES12 RC1 wicked update In-Reply-To: <20140807170804.2d2627cf@wioo.suse.de> References: <20140807170804.2d2627cf@wioo.suse.de> Message-ID: <53E39DE6.9000301@balabit.hu> On 08/07/2014 05:08 PM, Pawel Wieczorkiewicz wrote: > Hi, > > Please be informed that wicked version 0.6.1 has been released for > SLES12 RC1 online update. > > This version will not help with installation issues (new ISO > is required here), but it will help with network configuration failures > after boot-up. > > Please test. Thank you. > This time I wanted to register to be able to test the update, but while it worked a couple of weeks ago, now I get "Evaluation registration code is expired". Which is right, as it expired in 2013, but if it worked fine until now, why does not it work any more? Bye, -- Peter Czanik (CzP) BalaBit IT Security / syslog-ng upstream http://czanik.blogs.balabit.com/ https://twitter.com/PCzanik From kukuk at suse.de Thu Aug 7 09:42:39 2014 From: kukuk at suse.de (Thorsten Kukuk) Date: Thu, 7 Aug 2014 17:42:39 +0200 Subject: [sles-beta] SLES 12 x86_64 RC1 snapper does not do snapshots as configured In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9C7243@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9C7243@HXMB12.pnet.ch> Message-ID: <20140807154239.GA8245@suse.de> On Thu, Aug 07, urs.frey at post.ch wrote: > Hi > When having SLES12 x86_64 RC1 installed using btrfs snapper should do hourly snapshots as configured under /etc/snapper/configs/root, right? Not for the root partition. > Why this? The root partition is normally not changed that often, so all this empty snapshots will fill up your harddisk and makes it pretty hard to find the right snapshot later/to not delete the only important snapshot during cleanup. We got a lot of complains about this, thus we changed the default. > There is nothing in the Changelog-Beta10-RC1. > > Without automated snapshots btrfs is not working for me. ? If you make changes to the system with YaST or zypper, you should still get a new snapshot. Only cron will not kill your filesystem with a huge amount of empty snapshots. Else you can still enable it again, nobody prevents you from doing so. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) From urs.frey at post.ch Thu Aug 7 09:58:19 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Thu, 7 Aug 2014 15:58:19 +0000 Subject: [sles-beta] SLES 12 x86_64 RC1 snapper does not do snapshots as configured In-Reply-To: <20140807154239.GA8245@suse.de> References: <40637DBB36AF3941B243A286A432CA0B0F9C7243@HXMB12.pnet.ch> <20140807154239.GA8245@suse.de> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9C7264@HXMB12.pnet.ch> Hi Thanks for clarification. I see you optimized, and on my side I took the previous state as a standard. >Not for the root partition. Under default btrfs installation not only root is within the / snapshot. There are many subvolumes undergoing quite often changes v03er9:~ # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda3 20973568 1659992 17410152 9% / devtmpfs 949948 0 949948 0% /dev tmpfs 957800 0 957800 0% /dev/shm tmpfs 957800 9892 947908 2% /run tmpfs 957800 0 957800 0% /sys/fs/cgroup /dev/sda3 20973568 1659992 17410152 9% /var/tmp /dev/sda3 20973568 1659992 17410152 9% /var/spool /dev/sda3 20973568 1659992 17410152 9% /var/opt /dev/sda3 20973568 1659992 17410152 9% /var/log /dev/sda3 20973568 1659992 17410152 9% /var/lib/named /dev/sda3 20973568 1659992 17410152 9% /var/lib/pgqsl /dev/sda3 20973568 1659992 17410152 9% /srv /dev/sda3 20973568 1659992 17410152 9% /var/lib/mailman /dev/sda3 20973568 1659992 17410152 9% /var/crash /dev/sda3 20973568 1659992 17410152 9% /usr/local /dev/sda3 20973568 1659992 17410152 9% /.snapshots /dev/sda3 20973568 1659992 17410152 9% /opt /dev/sda3 20973568 1659992 17410152 9% /boot/grub2/x86_64-efi /dev/sda3 20973568 1659992 17410152 9% /@ /dev/sda3 20973568 1659992 17410152 9% /boot/grub2/i386-pc >> Without automated snapshots btrfs is not working for me. >? >If you make changes to the system with YaST or zypper, you >should still get a new snapshot. Only cron will not kill your >filesystem with a huge amount of empty snapshots. With the hourly snapshots there is an aspect which is very practical: For the first time one can see what changes from hour to hour on the so called "static" filesystems. It is a kind of security feature, when feeding the output from snapper detected changes into splunk, as example. I had it running for weeks now and it grew very moderately because of the well defined default cleanup rules. So I would encourage everybody to re-enable the hourly snapshots and get a free monitor of what had changed within the last hours on the server on the most valuable filesystems. It makes life in a production environment with operators a bit more transparent. 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 Thorsten Kukuk Gesendet: Thursday, August 07, 2014 5:43 PM An: sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES 12 x86_64 RC1 snapper does not do snapshots as configured On Thu, Aug 07, urs.frey at post.ch wrote: > Hi > When having SLES12 x86_64 RC1 installed using btrfs snapper should do hourly snapshots as configured under /etc/snapper/configs/root, right? Not for the root partition. > Why this? The root partition is normally not changed that often, so all this empty snapshots will fill up your harddisk and makes it pretty hard to find the right snapshot later/to not delete the only important snapshot during cleanup. We got a lot of complains about this, thus we changed the default. > There is nothing in the Changelog-Beta10-RC1. > > Without automated snapshots btrfs is not working for me. ? If you make changes to the system with YaST or zypper, you should still get a new snapshot. Only cron will not kill your filesystem with a huge amount of empty snapshots. Else you can still enable it again, nobody prevents you from doing so. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta From mge at suse.com Thu Aug 7 10:10:36 2014 From: mge at suse.com (Matthias G. Eckermann) Date: Thu, 7 Aug 2014 18:10:36 +0200 Subject: [sles-beta] SLES 12 x86_64 RC1 snapper does not do snapshots as configured In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9C7264@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9C7243@HXMB12.pnet.ch> <20140807154239.GA8245@suse.de> <40637DBB36AF3941B243A286A432CA0B0F9C7264@HXMB12.pnet.ch> Message-ID: <20140807161036.GA31816@suse.com> Hello Urs and all, On 2014-08-07 T 15:58 +0000 urs.frey at post.ch wrote: > With the hourly snapshots there is an aspect which is > very practical: For the first time one can see what > changes from hour to hour on the so called "static" > filesystems. It is a kind of security feature, when > feeding the output from snapper detected changes into > splunk, as example. I had it running for weeks now > and it grew very moderately because of the well > defined default cleanup rules. So I would encourage > everybody to re-enable the hourly snapshots and get a > free monitor of what had changed within the last hours > on the server on the most valuable filesystems. It > makes life in a production environment with operators > a bit more transparent. I agree with your Use Case, and this one of the reasons, why hourly snapshots have been implemented and had been default before. However, as Thorsten stated, we got feedback that the number of snapshots were overwhelming and confusing, and thus we decided to not switch it on by default. This reduces risk, reduces space needed and reduces pain for people not so much experienced in working with btrfs and snapper. Certainly, you are free to change the snapper settings! What I specifically liked in your statement in addition, was this: "well defined default cleanup rules". This is the key part of working with hourly snapshots, and making use of it in an efficient way; and I think "well defined" will be different for everybody here in the one or other way, ... So long - MgE -- Matthias G. Eckermann Senior Product Manager SUSE? Linux Enterprise Phone: +49 30 44315731 Mobile: +49 179 2949448 E-Mail: mge at suse.com SUSE LINUX Products GmbH Maxfeldstra?e 5 90409 N?rnberg Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) From gjn at gjn.priv.at Thu Aug 7 10:49:14 2014 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Thu, 07 Aug 2014 18:49:14 +0200 Subject: [sles-beta] [ANNOUNCE] SLES12 RC1 wicked update In-Reply-To: <20140807170804.2d2627cf@wioo.suse.de> References: <20140807170804.2d2627cf@wioo.suse.de> Message-ID: <2189488.Axzer77dtC@gjn.priv.at> Am Donnerstag, 7. August 2014, 17:08:04 schrieb Pawel Wieczorkiewicz: > Hi, > > Please be informed that wicked version 0.6.1 has been released for > SLES12 RC1 online update. > > This version will not help with installation issues (new ISO > is required here), but it will help with network configuration failures > after boot-up. > > Please test. Thank you. Is OVS supported now ? -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From abonilla at suse.com Thu Aug 7 11:47:21 2014 From: abonilla at suse.com (Alejandro Bonilla) Date: Thu, 07 Aug 2014 18:47:21 +0100 Subject: [sles-beta] SLES 12 x86_64 RC1 snapper does not do snapshots as configured In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9C7264@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9C7243@HXMB12.pnet.ch> <20140807154239.GA8245@suse.de> <40637DBB36AF3941B243A286A432CA0B0F9C7264@HXMB12.pnet.ch> Message-ID: <53E3C9C0020000A2000A57C1@mail.emea.novell.com> Hi Urs, I don't think managing hourly snapshots can scale very well. I would vote for Hourly being disabled. Again, you can enable it. Original Message From: Sent: Thursday, August 7, 2014 11:58 AM To: kukuk at suse.de Cc: sles-beta at lists.suse.com Subject: Re: [sles-beta] SLES 12 x86_64 RC1 snapper does not do snapshots as configured Hi Thanks for clarification. I see you optimized, and on my side I took the previous state as a standard. >Not for the root partition. Under default btrfs installation not only root is within the / snapshot. There are many subvolumes undergoing quite often changes v03er9:~ # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda3 20973568 1659992 17410152 9% / devtmpfs 949948 0 949948 0% /dev tmpfs 957800 0 957800 0% /dev/shm tmpfs 957800 9892 947908 2% /run tmpfs 957800 0 957800 0% /sys/fs/cgroup /dev/sda3 20973568 1659992 17410152 9% /var/tmp /dev/sda3 20973568 1659992 17410152 9% /var/spool /dev/sda3 20973568 1659992 17410152 9% /var/opt /dev/sda3 20973568 1659992 17410152 9% /var/log /dev/sda3 20973568 1659992 17410152 9% /var/lib/named /dev/sda3 20973568 1659992 17410152 9% /var/lib/pgqsl /dev/sda3 20973568 1659992 17410152 9% /srv /dev/sda3 20973568 1659992 17410152 9% /var/lib/mailman /dev/sda3 20973568 1659992 17410152 9% /var/crash /dev/sda3 20973568 1659992 17410152 9% /usr/local /dev/sda3 20973568 1659992 17410152 9% /.snapshots /dev/sda3 20973568 1659992 17410152 9% /opt /dev/sda3 20973568 1659992 17410152 9% /boot/grub2/x86_64-efi /dev/sda3 20973568 1659992 17410152 9% /@ /dev/sda3 20973568 1659992 17410152 9% /boot/grub2/i386-pc >> Without automated snapshots btrfs is not working for me. >? >If you make changes to the system with YaST or zypper, you >should still get a new snapshot. Only cron will not kill your >filesystem with a huge amount of empty snapshots. With the hourly snapshots there is an aspect which is very practical: For the first time one can see what changes from hour to hour on the so called "static" filesystems. It is a kind of security feature, when feeding the output from snapper detected changes into splunk, as example. I had it running for weeks now and it grew very moderately because of the well defined default cleanup rules. So I would encourage everybody to re-enable the hourly snapshots and get a free monitor of what had changed within the last hours on the server on the most valuable filesystems. It makes life in a production environment with operators a bit more transparent. 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 Thorsten Kukuk Gesendet: Thursday, August 07, 2014 5:43 PM An: sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES 12 x86_64 RC1 snapper does not do snapshots as configured On Thu, Aug 07, urs.frey at post.ch wrote: > Hi > When having SLES12 x86_64 RC1 installed using btrfs snapper should do hourly snapshots as configured under /etc/snapper/configs/root, right? Not for the root partition. > Why this? The root partition is normally not changed that often, so all this empty snapshots will fill up your harddisk and makes it pretty hard to find the right snapshot later/to not delete the only important snapshot during cleanup. We got a lot of complains about this, thus we changed the default. > There is nothing in the Changelog-Beta10-RC1. > > Without automated snapshots btrfs is not working for me. ? If you make changes to the system with YaST or zypper, you should still get a new snapshot. Only cron will not kill your filesystem with a huge amount of empty snapshots. Else you can still enable it again, nobody prevents you from doing so. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common CoGF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta From kukuk at suse.de Thu Aug 7 13:46:40 2014 From: kukuk at suse.de (Thorsten Kukuk) Date: Thu, 7 Aug 2014 21:46:40 +0200 Subject: [sles-beta] SLES 12 x86_64 RC1 snapper does not do snapshots as configured In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9C7264@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9C7243@HXMB12.pnet.ch> <20140807154239.GA8245@suse.de> <40637DBB36AF3941B243A286A432CA0B0F9C7264@HXMB12.pnet.ch> Message-ID: <20140807194640.GA14799@suse.de> Hi, On Thu, Aug 07, urs.frey at post.ch wrote: > >Not for the root partition. > > Under default btrfs installation not only root is within the / snapshot. There are many subvolumes undergoing quite often changes All subvolumes are excluded from snapshots. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) From urs.frey at post.ch Fri Aug 8 01:37:04 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Fri, 8 Aug 2014 07:37:04 +0000 Subject: [sles-beta] SLES 12 x86_64 RC1 snapper does not do snapshots as configured In-Reply-To: <53E3C9C0020000A2000A57C1@mail.emea.novell.com> References: <40637DBB36AF3941B243A286A432CA0B0F9C7243@HXMB12.pnet.ch> <20140807154239.GA8245@suse.de> <40637DBB36AF3941B243A286A432CA0B0F9C7264@HXMB12.pnet.ch> <53E3C9C0020000A2000A57C1@mail.emea.novell.com> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9C7329@HXMB12.pnet.ch> Hi In my production environment I have a CMDB and puppet to configure the servers and manage user accounts. Puppet jobs do run hourly. So in my specific environment the filesystems within btrfs root are not really static. In fact they are undergoing changes whenever a new configuration gets implemented by puppet. Used case: time servers get migrated. So on all servers the /etc/ntp.conf must be changed. In order to keep control, not only the puppet logfile is there but also the btrfs snapshot showing exactly in which hour which file, and what content has been changed. This btrfs double-check is very welcome here. v03er9:~ # snapper list Type | # | Pre # | Date | User | Cleanup | Description | Userdata -------+----+-------+--------------------------+------+----------+----------------+------------- single | 0 | | | root | | current | pre | 1 | | Wed Aug 6 16:39:50 2014 | root | number | zypp(zypper) | important=no post | 2 | 1 | Wed Aug 6 16:39:51 2014 | root | number | | important=no pre | 3 | | Wed Aug 6 16:39:52 2014 | root | number | zypp(zypper) | important=no post | 4 | 3 | Wed Aug 6 16:39:53 2014 | root | number | | important=no pre | 5 | | Wed Aug 6 16:39:54 2014 | root | number | zypp(zypper) | important=no post | 6 | 5 | Wed Aug 6 16:39:56 2014 | root | number | | important=no pre | 7 | | Wed Aug 6 16:40:03 2014 | root | number | zypp(zypper) | important=no post | 8 | 7 | Wed Aug 6 16:40:05 2014 | root | number | | important=no pre | 9 | | Thu Aug 7 17:11:22 2014 | root | number | yast sw_single | post | 10 | 9 | Thu Aug 7 17:13:57 2014 | root | number | | single | 11 | | Thu Aug 7 18:15:01 2014 | root | timeline | timeline | single | 12 | | Thu Aug 7 19:15:02 2014 | root | timeline | timeline | single | 13 | | Thu Aug 7 20:15:01 2014 | root | timeline | timeline | single | 14 | | Thu Aug 7 21:15:01 2014 | root | timeline | timeline | single | 15 | | Thu Aug 7 22:15:01 2014 | root | timeline | timeline | single | 16 | | Thu Aug 7 23:15:01 2014 | root | timeline | timeline | single | 17 | | Fri Aug 8 00:15:01 2014 | root | timeline | timeline | single | 18 | | Fri Aug 8 01:15:01 2014 | root | timeline | timeline | single | 19 | | Fri Aug 8 02:15:01 2014 | root | timeline | timeline | single | 20 | | Fri Aug 8 03:15:01 2014 | root | timeline | timeline | single | 21 | | Fri Aug 8 04:15:01 2014 | root | timeline | timeline | single | 22 | | Fri Aug 8 05:15:02 2014 | root | timeline | timeline | single | 23 | | Fri Aug 8 06:15:01 2014 | root | timeline | timeline | single | 24 | | Fri Aug 8 07:15:01 2014 | root | timeline | timeline | single | 25 | | Fri Aug 8 08:15:01 2014 | root | timeline | timeline | single | 26 | | Fri Aug 8 09:15:01 2014 | root | timeline | timeline | v03er9:~ # snapper status 25..26 c..... /var/lib/puppet/client_data/catalog/v03er9.pnet.ch.json c..... /var/lib/puppet/state/last_run_summary.yaml c..... /var/lib/puppet/state/puppet_user_report_date.patchnix c..... /var/lib/puppet/state/puppet_user_summary.log c..... /var/lib/puppet/state/puppet_user_summary.yaml_uploaded c..... /var/lib/puppet/state/state.yaml c..... /var/post/patchnix_report.v03er9 v03er9:~ # But again. This is very specific to an environment where an automated configuration of many server is implemented. E.g. by SUSE-manager or similar. So I agree: everybody has to choose what fits him/her best. So the decision for the new default TIMELINE_CREATE="no", is OK for me. I would appreciate, finding such changes in the Changelog for the release. Thank you Best regards Urs Frey????????????????????????????????????????????? Post CH AG Informationstechnologie IT Betrieb Webergutstrasse 12 3030 Bern (Zollikofen) Telefon : ++41 (0)58 338 58 70 FAX???? : ++41 (0)58 667 30 07 E-Mail:?? urs.frey at post.ch -----Urspr?ngliche Nachricht----- Von: Alejandro Bonilla [mailto:abonilla at suse.com] Gesendet: Thursday, August 07, 2014 7:47 PM An: Frey Urs, IT222; kukuk at suse.de Cc: sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES 12 x86_64 RC1 snapper does not do snapshots as configured Hi Urs, I don't think managing hourly snapshots can scale very well. I would vote for Hourly being disabled. Again, you can enable it. Original Message From: Sent: Thursday, August 7, 2014 11:58 AM To: kukuk at suse.de Cc: sles-beta at lists.suse.com Subject: Re: [sles-beta] SLES 12 x86_64 RC1 snapper does not do snapshots as configured Hi Thanks for clarification. I see you optimized, and on my side I took the previous state as a standard. >Not for the root partition. Under default btrfs installation not only root is within the / snapshot. There are many subvolumes undergoing quite often changes v03er9:~ # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda3 20973568 1659992 17410152 9% / devtmpfs 949948 0 949948 0% /dev tmpfs 957800 0 957800 0% /dev/shm tmpfs 957800 9892 947908 2% /run tmpfs 957800 0 957800 0% /sys/fs/cgroup /dev/sda3 20973568 1659992 17410152 9% /var/tmp /dev/sda3 20973568 1659992 17410152 9% /var/spool /dev/sda3 20973568 1659992 17410152 9% /var/opt /dev/sda3 20973568 1659992 17410152 9% /var/log /dev/sda3 20973568 1659992 17410152 9% /var/lib/named /dev/sda3 20973568 1659992 17410152 9% /var/lib/pgqsl /dev/sda3 20973568 1659992 17410152 9% /srv /dev/sda3 20973568 1659992 17410152 9% /var/lib/mailman /dev/sda3 20973568 1659992 17410152 9% /var/crash /dev/sda3 20973568 1659992 17410152 9% /usr/local /dev/sda3 20973568 1659992 17410152 9% /.snapshots /dev/sda3 20973568 1659992 17410152 9% /opt /dev/sda3 20973568 1659992 17410152 9% /boot/grub2/x86_64-efi /dev/sda3 20973568 1659992 17410152 9% /@ /dev/sda3 20973568 1659992 17410152 9% /boot/grub2/i386-pc >> Without automated snapshots btrfs is not working for me. >? >If you make changes to the system with YaST or zypper, you >should still get a new snapshot. Only cron will not kill your >filesystem with a huge amount of empty snapshots. With the hourly snapshots there is an aspect which is very practical: For the first time one can see what changes from hour to hour on the so called "static" filesystems. It is a kind of security feature, when feeding the output from snapper detected changes into splunk, as example. I had it running for weeks now and it grew very moderately because of the well defined default cleanup rules. So I would encourage everybody to re-enable the hourly snapshots and get a free monitor of what had changed within the last hours on the server on the most valuable filesystems. It makes life in a production environment with operators a bit more transparent. 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 Thorsten Kukuk Gesendet: Thursday, August 07, 2014 5:43 PM An: sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES 12 x86_64 RC1 snapper does not do snapshots as configured On Thu, Aug 07, urs.frey at post.ch wrote: > Hi > When having SLES12 x86_64 RC1 installed using btrfs snapper should do hourly snapshots as configured under /etc/snapper/configs/root, right? Not for the root partition. > Why this? The root partition is normally not changed that often, so all this empty snapshots will fill up your harddisk and makes it pretty hard to find the right snapshot later/to not delete the only important snapshot during cleanup. We got a lot of complains about this, thus we changed the default. > There is nothing in the Changelog-Beta10-RC1. > > Without automated snapshots btrfs is not working for me. ? If you make changes to the system with YaST or zypper, you should still get a new snapshot. Only cron will not kill your filesystem with a huge amount of empty snapshots. Else you can still enable it again, nobody prevents you from doing so. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common CoGF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta From ronny.pretzsch at dfs.de Fri Aug 8 06:00:03 2014 From: ronny.pretzsch at dfs.de (Ronny Pretzsch) Date: Fri, 8 Aug 2014 14:00:03 +0200 Subject: [sles-beta] RC1 NRPE Package (nagios) In-Reply-To: <20140807125545.GA4404@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> Message-ID: <1407499203.25813.3.camel@ronnylinux.prod.bk.dfs> On Thu, 2014-08-07 at 14:55 +0200, Thorsten Kukuk wrote: > On Thu, Aug 07, Ronny Pretzsch wrote: > > > On Wed, 2014-08-06 at 13:14 +0200, Thorsten Kukuk wrote: > > > On Wed, Aug 06, Ronny Pretzsch wrote: > > > > > > > 1 source package to install. > > > > Overall download size: 438.1 KiB. Already cached: 0 B After the > > > > operation, additional 447.1 KiB will be used. > > > > Continue? [y/n/? shows all options] (y): > > > > Media source 'http://install.prod.bk.dfs/sles12-64' does not contain the > > > > desired medium > > > > > > The URL looks wrong. > > > You should have something like: > > > http://install.prod.bk.dfs/sles12-64/DVD1 > > > http://install.prod.bk.dfs/sles12-64/DVD2 > > > > > > > The URL is correct. Otherwise "zypper search" would not work at > > all and I could not install other packages. But I can. > > Your setup does not work as you see above: zypper cannot find your > source RPM. > > > Behind that URL is DVD1 only - I did not use DVD2 in any way. > > To my knowledge DVD2 contains only srpms and is not necessary for installation. > > Correct, byt you tried to install a source RPM: > "We tried to install the srcpackage". > > > If the nrpe srcpackage is on DVD2 (what I assume) then "zypper search" must not find nrpe srcpackage as the metadata of DVD1 should not contain any (src)packages from DVD2. Or am I getting anything wrong? > > The meta data on DVD1 contains all RPMs of that product, > regardless on which DVD it is. > [...] Thank you for cearification. I never had that use case as I never needed srpms be installed. See also follow-up mail. 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 From ronny.pretzsch at dfs.de Fri Aug 8 06:06:37 2014 From: ronny.pretzsch at dfs.de (Ronny Pretzsch) Date: Fri, 8 Aug 2014 14:06:37 +0200 Subject: [sles-beta] RC1 NRPE Package (nagios) In-Reply-To: <53E37AF0.8090705@ucs.cam.ac.uk> 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> Message-ID: <1407499597.25813.10.camel@ronnylinux.prod.bk.dfs> On Thu, 2014-08-07 at 14:11 +0100, Simon Flood wrote: > On 07/08/2014 13:55, Thorsten Kukuk wrote: > > > Correct, byt you tried to install a source RPM: > > "We tried to install the srcpackage". > > I think Ronny tried installing the srcpackage because they couldn't > install the nrpe package as per Absolutely correct. Thank you. > > There seems to be a srcpackage "nrpe". > > But there is no package "nrpe" - only the plugin. > > So where is nagios-nrpe or any other nagios packages in SLES12? They'res > not in SLES12 RC1 DVD1, mini, modules (legacy, adv. system mgmt, web > scripting) or Workstation Extension. Thus the question if the nrpe daemon (nrpe tcp-server) is going to be included in any SLE12 product. > There is a monitoring-plugins-nrpe package which I believe is the new > name for nagios-plugins-nrpe (as was in SLES11). This package seems to be built from that nrpe srpm. I wanted to check if the nrpe srpm does contain the actual nrpe daemon (tcp-server) or only the nrpe plugin (tcp-client). 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. 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 From mge at suse.com Fri Aug 8 06:36:16 2014 From: mge at suse.com (Matthias G. Eckermann) Date: Fri, 8 Aug 2014 14:36:16 +0200 Subject: [sles-beta] RC1 NRPE Package (nagios) In-Reply-To: <1407499597.25813.10.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> Message-ID: <20140808123616.GA24665@suse.com> Hello all, On 2014-08-08 T 14:06 +0200 Ronny Pretzsch wrote: > On Thu, 2014-08-07 at 14:11 +0100, Simon Flood wrote: > > > > So where is nagios-nrpe or any other nagios packages > > in SLES12? They'res not in SLES12 RC1 DVD1, mini, > > modules (legacy, adv. system mgmt, web scripting) or > > Workstation Extension. > > 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-*. > 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. HTH - So long - MgE -- Matthias G. Eckermann Senior Product Manager SUSE? Linux Enterprise Phone: +49 30 44315731 Mobile: +49 179 2949448 E-Mail: mge at suse.com SUSE LINUX Products GmbH Maxfeldstra?e 5 90409 N?rnberg Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) From S.M.Flood at ucs.cam.ac.uk Fri Aug 8 06:52:44 2014 From: S.M.Flood at ucs.cam.ac.uk (Simon Flood) Date: Fri, 08 Aug 2014 13:52:44 +0100 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: <53E4C81C.1080501@ucs.cam.ac.uk> On 08/08/2014 13:36, Matthias G. Eckermann wrote: > Similar to the nagios-plugins (which have been renamed to > monitoring-plugins), the nrpe stuff will be renamed to > monitoring*nrpe-*. > Unfortunately both nrpe packages where missing in SUSE > Linux Enterprise Server 12 RC1, they should become > available again in RC2. So where is Nagios (and associated packages) itself? It was in SLES11 SP3. All there are in SLES12 RC1 are various monitoring-plugins-* packages. Thanks, Simon -- Simon Flood Senior Systems Specialist University of Cambridge United Kingdom Novell/SUSE/NetIQ Knowledge Partner From pwieczorkiewicz at suse.de Fri Aug 8 07:28:48 2014 From: pwieczorkiewicz at suse.de (Pawel Wieczorkiewicz) Date: Fri, 8 Aug 2014 15:28:48 +0200 Subject: [sles-beta] SLES12 RC1 wicked configuration ETHTOOL_OPTIONS=autoneg on = NIC does not come up In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9C744C@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9C744C@HXMB12.pnet.ch> Message-ID: <20140808152848.44625b62@wioo.suse.de> On Fri, 8 Aug 2014 13:22:37 +0000 wrote: > Hi > > When having SLES12 RC1 x86_64 installed, the network does not start > YES I know, this will be fixed in RC2 using wicked update 0.6.1 > > BUT I do observe a strange behavior. Strange for me, as this worked > without problems with SLES12 Beta9. When I do have the option > ETHTOOL_OPTIONS='autoneg on' > defined , the wicked runs into a failure with nanny and the NIC keeps > being unconfigured > > h05cnh:~ # cat /etc/sysconfig/network/ifcfg-eth0 > BOOTPROTO='static' > STARTMODE='auto' > IPADDR='10.226.169.28/24' > BROADCAST='10.226.169.255' > ##ETHTOOL_OPTIONS='autoneg on' > PREFIXLEN='24' > h05cnh:~ # > > I do run already the updated rpm packages for wicked > h05cnh:~ # rpm -qa | grep wicked > libwicked-0-6-0.6.1-1.1.x86_64 > wicked-service-0.6.1-1.1.x86_64 > libwicked-0-5-0.5.38-1.1.x86_64 > wicked-0.6.1-1.1.x86_64 > h05cnh:~ # > > 2014-08-08T15:04:20.152001+02:00 h05cnh wickedd[675]: eth0: failed to > update ethernet device settings 2014-08-08T15:04:20.152402+02:00 > h05cnh wickedd-nanny[676]: dbus error reply = > org.freedesktop.DBus.Error.Failed (failed to set up ethernet device) > 2014-08-08T15:04:20.152747+02:00 h05cnh wickedd-nanny[676]: > ni_ifworker_error_handler(org.freedesktop.DBus.Error.Failed, failed > to set up ethernet device) 2014-08-08T15:04:20.153087+02:00 h05cnh > wickedd-nanny[676]: unable to map DBus error > org.freedesktop.DBus.Error.Failed, return GENERAL_FAILURE > 2014-08-08T15:04:20.153426+02:00 h05cnh wickedd-nanny[676]: device > eth0 failed: call to org.opensuse.Network.Ethernet.changeDevice() > failed: General failure 2014-08-08T15:04:20.153765+02:00 h05cnh > wickedd-nanny[676]: ni_managed_device_progress(eth0) > target(network-up [network-up..max]), transition(none => none) > 2014-08-08T15:04:20.154110+02:00 h05cnh wickedd-nanny[676]: sending > event "progressInfo" 2014-08-08T15:04:20.154451+02:00 h05cnh wicked: > received signal progressInfo; > object_path=/org/opensuse/Network/Nanny/Interface/2; > target_state=network-up, state_name=none > 2014-08-08T15:04:20.154578+02:00 h05cnh wickedd-nanny[676]: eth0: > failed to bring up device, still continuing > 2014-08-08T15:04:20.154916+02:00 h05cnh wickedd[675]: > __ni_dbus_object_message(path=/org/opensuse/Network/Interface, > interface=org.freedesktop.DBus.ObjectManager, method=GetManaged > Objects) called 2014-08-08T15:04:20.155275+02:00 h05cnh > wickedd-nanny[676]: waiting for 0 devices to become ready (0 > explicitly requested) 2014-08-08T15:04:20.155617+02:00 h05cnh > wickedd[675]: > __ni_dbus_object_manager_get_managed_objects(path=/org/opensuse/Network/Interface, > method=GetManagedObjects) 2014-08-08T15:04:20.155954+02:00 h05cnh > wicked: Exit with status: 0 > > QUESTION: > Are the ETHTOOL_OPTIONS no longer allowed in ifcfg-eth0 NIC > configuration? > > Thank you very much for your feedback > > Best regards Hmm... It looks like wickedd rejected (GENERAL_FAILURE) such an option. It would be good to see full wickedd log. Could you please provide one? Karol worked with this part recently, so maybe he could help here. -- Best Regards, Pawel Wieczorkiewicz , Linux System Developer SUSE LINUX Products GmbH GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) Maxfeldstr. 5 / D-90409 N?rnberg / Phone: +49-911-740 53 - 613 From urs.frey at post.ch Fri Aug 8 09:24:22 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Fri, 8 Aug 2014 15:24:22 +0000 Subject: [sles-beta] SLES12 RC1 wicked configuration ETHTOOL_OPTIONS=autoneg on = NIC does not come up In-Reply-To: <20140808160910.5a560a08@wioo.suse.de> References: <40637DBB36AF3941B243A286A432CA0B0F9C744C@HXMB12.pnet.ch> <20140808152848.44625b62@wioo.suse.de> <40637DBB36AF3941B243A286A432CA0B0F9C7495@HXMB12.pnet.ch> <20140808160910.5a560a08@wioo.suse.de> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9C74DF@HXMB12.pnet.ch> Hello Pawel I had a closer look at this issue: VMWare ESXi = the virtual interface does allow to use ETHTOOL_OPTIONS, wicked will start the NIC here, no problem ============ v03er9:~ # /usr/sbin/dmidecode | awk '/Product Name:/ {print $4$5}' VirtualPlatform DesktopReference v03er9:~ # lspci | grep Ether 02:00.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) (rev 01) v03er9:~ # ethtool -s eth0 autoneg on v03er9:~ # cat /etc/sysconfig/network/ifcfg-eth0 BOOTPROTO='static' STARTMODE='auto' IPADDR='10.1.100.167' NETMASK='255.255.254.0' NAME='82545EM Gigabit Ethernet Controller (Copper)' ETHTOOL_OPTIONS='autoneg on' PREFIXLEN='23' v03er9:~ # => Here wicked does start the network interface, no problem. KVM = the virtual interface does technically not allow to use ETHTOOL_OPTIONS, because it is a virtual interface. No settings possible ============== h05cnh:~ # /usr/sbin/dmidecode | awk '/Product Name:/ {print $4$5}' PC(i440FX h05cnh:~ # lspci | grep Ether 00:03.0 Ethernet controller: Red Hat, Inc Virtio network device h05cnh:~ # ethtool -s eth0 autoneg on Cannot get current device settings: Operation not supported not setting autoneg h05cnh:~ # h05cnh:~ # cat /etc/sysconfig/network/ifcfg-eth0 BOOTPROTO='static' STARTMODE='auto' IPADDR='10.226.169.28/24' BROADCAST='10.226.169.255' PREFIXLEN='24' h05cnh:~ # => Here Wicked runs into a General Failure, NIC will not be started ============== HP Proliant Blade Server with Converged Network Adapter = This interface does not allow to set ETHTOOL_OPTIONS, No settings possible. ======= h05cni:~ # /usr/sbin/dmidecode | awk '/Product Name:/ {print $4$5}' BL460cGen8 h05cni:~ # lspci | grep Ether 04:00.0 Ethernet controller: Emulex Corporation OneConnect 10Gb NIC (be3) (rev 01) 04:00.1 Ethernet controller: Emulex Corporation OneConnect 10Gb NIC (be3) (rev 01) h05cni:~ # ethtool -s eth0 autoneg on Cannot set new settings: Operation not supported not setting autoneg h05cni:~ # h05cni:~ # cat /etc/sysconfig/network/ifcfg-eth0 DEVICE=eth0 BOOTPROTO=none ETHTOOL_OPTIONS='' STARTMODE='hotplug' MASTER=bond0 SLAVE=yes h05cni:~ # => Here Wicked runs into a General Failure, NIC will not be started ======= BUT: HP Proliant DL380-G7, Broadcom Nextreme II BCM5709 Gigabit Ethernet = This interface does allow setting of ETHTOOL_OPTIONS h063uz:~ # /usr/sbin/dmidecode | awk '/Product Name:/ {print $4$5}' DL380G7 h063uz:~ # lspci | grep Ether 03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20) 03:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20) 04:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20) 04:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20) h063uz:~ # ethtool -s eth1 autoneg on h063uz:~ # h063uz:~ # cat /etc/sysconfig/network/ifcfg-eth0 BOOTPROTO='static' STARTMODE='auto' IPADDR='10.226.154.19/23' BROADCAST='10.226.155.255' ETHTOOL_OPTIONS='autoneg on' PREFIXLEN='23' h063uz:~ # => Here wicked does start the NIC, no problem CONCLUSION: =========== On all server installations, where ETHTOOL causes an error if trying to set autoneg on, wicked runs into an error. With the old network configuration, this error got ignored and the network interface got started anyway. Let us say focus on correct IP configuration. So I can imagine, that wicked now is more sensible to configuration errors, which somehow is correct and consequent 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: Pawel Wieczorkiewicz [mailto:pwieczorkiewicz at suse.de] Gesendet: Friday, August 08, 2014 4:09 PM An: Frey Urs, IT222; Karol Mroz Betreff: Re: [sles-beta] SLES12 RC1 wicked configuration ETHTOOL_OPTIONS=autoneg on = NIC does not come up On Fri, 8 Aug 2014 14:01:43 +0000 wrote: > Hello Pawel > > Please find in the attachment a tarball containing config.log, > status.log, wicked.log and messages > > I booted the KVM client with ETHTOO_OPTION='autoneg on' > Then I collected the logs > ? set DEBUG=all in /etc/sysconfig/network/config > ? systemctl restart wickedd > ? wicked ifstatus all > status.log > ? wicked show-config > configs.log > ? journalctl -b -o short-iso > wicked.log > Hello, Are you testing ETHTOOLs options only in KVM env or also on physical interfaces? From my experience KVM drivers for ethernet nics do not support ethtool options very well, and they are pretty unstable with them (sometimes they work, sometimes they lose the changes). We will look into the logs. Thank you for sending them. -- Best Regards, Pawel Wieczorkiewicz , Linux System Developer SUSE LINUX Products GmbH GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) Maxfeldstr. 5 / D-90409 N?rnberg / Phone: +49-911-740 53 - 613 From mge at suse.com Fri Aug 8 09:43:55 2014 From: mge at suse.com (Matthias G. Eckermann) Date: Fri, 8 Aug 2014 17:43:55 +0200 Subject: [sles-beta] RC1 NRPE Package (nagios) In-Reply-To: <53E4C81C.1080501@ucs.cam.ac.uk> 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> <53E4C81C.1080501@ucs.cam.ac.uk> Message-ID: <20140808154355.GB26925@suse.com> Hello Simon and all, On 2014-08-08 T 13:52 +0100 Simon Flood wrote: > On 08/08/2014 13:36, Matthias G. Eckermann wrote: > > > Similar to the nagios-plugins (which have been > > renamed to monitoring-plugins), the nrpe stuff will > > be renamed to monitoring*nrpe-*. > > > Unfortunately both nrpe packages where missing in > > SUSE Linux Enterprise Server 12 RC1, they should > > become available again in RC2. > > So where is Nagios (and associated packages) itself? > It was in SLES11 SP3. > > All there are in SLES12 RC1 are various > monitoring-plugins-* packages. That's on purpose. Let me put it this way: nagios in SUSE Linux Enterprise Server 11 is a package we did not put much focus on nor any "love" into. It is there, it is maintained, it's aging; it will remain in SUSE Linux Enterprise Server 11 as fully supported, but that's it. For SUSE Linux Enterprise Server 12 we thought how we could improve the situation for the monitoring framework, well, the server part of it. For example, we got requests for Icinga. Thus, starting with SUSE Linux Enterprise 12, we are replacing the Nagios server with Icinga. Support for Icinga will not be part of the SUSE Linux Enterprise Server 12 subscription, though. Instead fully supported Icinga packages for SUSE Linux Enterprise Server 12 will be available as part of a SUSE Manager subscription. In this context we will be able to deliver better integration into the monitoring frameworks supported by SUSE Manager, and more frequent updates on the monitoring server parts than it had been in the past. Hope this explains. So long - MgE -- Matthias G. Eckermann Senior Product Manager SUSE? Linux Enterprise Phone: +49 30 44315731 Mobile: +49 179 2949448 E-Mail: mge at suse.com SUSE LINUX Products GmbH Maxfeldstra?e 5 90409 N?rnberg Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) From S.M.Flood at ucs.cam.ac.uk Fri Aug 8 10:01:20 2014 From: S.M.Flood at ucs.cam.ac.uk (Simon Flood) Date: Fri, 08 Aug 2014 17:01:20 +0100 Subject: [sles-beta] RC1 NRPE Package (nagios) In-Reply-To: <20140808154355.GB26925@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> <53E4C81C.1080501@ucs.cam.ac.uk> <20140808154355.GB26925@suse.com> Message-ID: <53E4F450.9000508@ucs.cam.ac.uk> On 08/08/2014 16:43, Matthias G. Eckermann wrote: > That's on purpose. Okay ... > Let me put it this way: nagios in SUSE Linux Enterprise > Server 11 is a package we did not put much focus on nor > any "love" into. It is there, it is maintained, it's > aging; it will remain in SUSE Linux Enterprise Server 11 > as fully supported, but that's it. > > For SUSE Linux Enterprise Server 12 we thought how we > could improve the situation for the monitoring > framework, well, the server part of it. For example, we > got requests for Icinga. Whilst I've not played with Icinga I've at least heard of it so that's a start. By Icinga do you mean v1 or Icinga 2? > Thus, starting with SUSE Linux Enterprise 12, we are > replacing the Nagios server with Icinga. Support for > Icinga will not be part of the SUSE Linux Enterprise > Server 12 subscription, though. > > Instead fully supported Icinga packages for SUSE Linux > Enterprise Server 12 will be available as part of a > SUSE Manager subscription. In this context we will be > able to deliver better integration into the monitoring > frameworks supported by SUSE Manager, and more frequent > updates on the monitoring server parts than it had been > in the past. So the only way to get a supported monitoring solution with SLES12 is to buy a subscription for SUSE Manager? That seems a little naughty. Why does it feel like I'll have to use the openSUSE Build Service to plug more holes with SLES12 than SLES11 SP3? > Hope this explains. It does (even though I don't like it!). Thanks, Simon -- Simon Flood Senior Systems Specialist University of Cambridge United Kingdom Novell/SUSE/NetIQ Knowledge Partner From dvosburg at suse.com Fri Aug 8 13:32:21 2014 From: dvosburg at suse.com (Donald Vosburg) Date: Fri, 08 Aug 2014 13:32:21 -0600 Subject: [sles-beta] RC1 NRPE Package (nagios) In-Reply-To: <53E4F450.9000508@ucs.cam.ac.uk> 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> <53E4C81C.1080501@ucs.cam.ac.uk> <20140808154355.GB26925@suse.com> <53E4F450.9000508@ucs.cam.ac.uk> Message-ID: <53E4D440020000C200153C47@prv-mh.provo.novell.com> Ditto on the understand and don't agree. Sent from my iPhone > On Aug 8, 2014, at 12:01 PM, "Simon Flood" wrote: > >> On 08/08/2014 16:43, Matthias G. Eckermann wrote: >> >> That's on purpose. > > Okay ... > >> Let me put it this way: nagios in SUSE Linux Enterprise >> Server 11 is a package we did not put much focus on nor >> any "love" into. It is there, it is maintained, it's >> aging; it will remain in SUSE Linux Enterprise Server 11 >> as fully supported, but that's it. >> >> For SUSE Linux Enterprise Server 12 we thought how we >> could improve the situation for the monitoring >> framework, well, the server part of it. For example, we >> got requests for Icinga. > > Whilst I've not played with Icinga I've at least heard of it so that's a > start. By Icinga do you mean v1 or Icinga 2? > >> Thus, starting with SUSE Linux Enterprise 12, we are >> replacing the Nagios server with Icinga. Support for >> Icinga will not be part of the SUSE Linux Enterprise >> Server 12 subscription, though. >> >> Instead fully supported Icinga packages for SUSE Linux >> Enterprise Server 12 will be available as part of a >> SUSE Manager subscription. In this context we will be >> able to deliver better integration into the monitoring >> frameworks supported by SUSE Manager, and more frequent >> updates on the monitoring server parts than it had been >> in the past. > > So the only way to get a supported monitoring solution with SLES12 is to > buy a subscription for SUSE Manager? That seems a little naughty. > > Why does it feel like I'll have to use the openSUSE Build Service to > plug more holes with SLES12 than SLES11 SP3? > >> Hope this explains. > > It does (even though I don't like it!). > > Thanks, > Simon > -- > Simon Flood > Senior Systems Specialist > University of Cambridge > United Kingdom > > Novell/SUSE/NetIQ Knowledge Partner > _______________________________________________ > sles-beta mailing list > sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta >