From martin.wilck at ts.fujitsu.com Mon Apr 28 03:30:58 2014 From: martin.wilck at ts.fujitsu.com (Martin Wilck) Date: Mon, 28 Apr 2014 11:30:58 +0200 Subject: [sles-beta] Grantley platform dmesg error. In-Reply-To: <6B6D440AC88B9D4BA615C54243DD034759BD06B0@gbtmail03.gigabyte.intra> References: <6B6D440AC88B9D4BA615C54243DD034759BD06B0@gbtmail03.gigabyte.intra> Message-ID: <535E1FD2.9060102@ts.fujitsu.com> On 04/28/2014 08:47 AM, tom.su (???) wrote: > Dear All > > Does anyone see below dmesg log in intel Grantley platform? Thank you. This is pretty obiously a BIOS problem. Namespace lookup failures for various methods. Martin -- Dr. Martin Wilck PRIMERGY System Software Engineer x86 Server Engineering FUJITSU Fujitsu Technology Solutions GmbH Heinz-Nixdorf-Ring 1 33106 Paderborn, Germany Phone: ++49 5251 525 2796 Fax: ++49 5251 525 2820 Email: martin.wilck at ts.fujitsu.com Internet: http://ts.fujitsu.com Company Details: http://ts.fujitsu.com/imprint From Klaus.Gmeinwieser at oce.com Mon Apr 28 08:52:27 2014 From: Klaus.Gmeinwieser at oce.com (Klaus Gmeinwieser) Date: Mon, 28 Apr 2014 16:52:27 +0200 Subject: [sles-beta] Issues on Beta4 In-Reply-To: References: <534CC1E2.6080808@oce.com> <20140417093911.GA16665@linux-w520.guibland.com> Message-ID: <535E6B2B.8040104@oce.com> Hi, thanks for the clarifications. I just wanted to remove cups server and any related printerdriver packages et. al. Package cups libs could be installed to satisfy any software dependencies. But I will not use cups and we deliver software which conflicts with CUPS server so I would appreciate the possibility to uninstall cups so that "no printer (software) available" messages will come up. But this is not possible to "choose" using YaST...??? Rgds Klaus Am 24.04.2014 16:56, schrieb Johannes Meixner: > > Hello > > On Apr 17 11:39 Antoine Ginies wrote (excerpt): >> Klaus Gmeinwieser wrote (excerpt): >>> - I want to get rid of cups on my installations, but GNOME's >>> dependencies do not allow to remove cups. Is this correct behavior? >> >> Because gnome has the capabilitie to configure printer. > > I am not at all a Gnome expert but I wonder if the capability > to configure a printer justifies hard RPM requirements for > the software that provides that fuctionality. > > On my SLES12-beta5 system an analysis what actually requires cups > (the rpm output is shown condensed here by me): > ------------------------------------------------------------------------ > rpm -e --test cups-client > error: Failed dependencies: > cups-client is needed by cups-1.7.2-6.1.x86_64 > > # rpm -e --test cups > error: Failed dependencies: > cups needed by cups-pk-helper-0.2.5-3.61.x86_64 > cups needed by patterns-sles-print_server-12-28.1.x86_64 > cups needed by system-config-printer-1.4.4-1.3.x86_64 > > # rpm -e --test system-config-printer > [no output - i.e. nothing requires it] > > # rpm -e --test patterns-sles-print_server > [no output - i.e. nothing requires it] > > # rpm -e --test cups-pk-helper > error: Failed dependencies: > cups-pk-helper needed by cups-pk-helper-lang-0.2.5-3.61.noarch > cups-pk-helper needed by gnome-control-center-3.10.3-1.3.x86_64 > > # rpm -e --test cups-pk-helper-lang > [no output - i.e. nothing requires it] > ------------------------------------------------------------------------ > > When gnome-control-center has a hard RPM requirement for cups-pk-helper > it must mean that gnome-control-center cannot run without it > or that gnome-control-center does not make any sense without it. > > When gnome-control-center can run without cups-pk-helper > in a reasonable way, then gnome-control-center should > not have a hard RPM requirement for cups-pk-helper > but only a weak RPM "Recommends" for it. > > This way cups-pk-helper (and CUPS) would be usually installed > when gnome-control-center is installed (via zypper's "--recommends") > but when a user deliberately does not want to have CUPS installed, > the RPMs cups and cups-client could be removed without violating > hard RPM requirements. > > In contrast the cups-libs RPM is usually needed by many other > software packages that link with the CUPS libraries > ----------------------------------------------------------------------- > # rpm -e --test cups-libs 2>&1 \ > | grep -o 'needed by .*' | cut -d ' ' -f4 | sort -u > cups-1.7.2-6.1.x86_64 > cups-client-1.7.2-6.1.x86_64 > cups-filters-1.0.52-7.1.x86_64 > cups-filters-cups-browsed-1.0.52-7.1.x86_64 > cups-filters-ghostscript-1.0.52-7.1.x86_64 > cups-pk-helper-0.2.5-3.61.x86_64 > ghostscript-9.14-1.11.x86_64 > gnome-control-center-3.10.3-1.3.x86_64 > gnome-settings-daemon-3.10.2-7.2.x86_64 > hplip-hpijs-3.14.4-2.3.x86_64 > libgtk-2_0-0-2.24.23-1.23.x86_64 > libgtk-3-0-3.10.7-1.35.x86_64 > patterns-sles-base-12-28.1.x86_64 > python-cups-1.9.66-1.3.x86_64 > samba-libs-4.1.6-5.1.x86_64 > ----------------------------------------------------------------------- > so that without the cups-libs RPM the system becomes very minimal. > > > Kind Regards > Johannes Meixner -- Klaus Gmeinwieser T +49 (0)8121 72 4358 F +49 (0)8121 72 3173 E klaus.gmeinwieser at oce.com W www.oce.com Oc? Printing Systems GmbH & Co. KG ? A Canon Group Company P.O. Box 1260 ? 85581 Poing Siemensallee 2 ? 85586 Poing ? Germany Oc? enables its customers to manage their documents efficiently and effectively by offering innovative print and document management products and services for professional environments. Oc? Printing Systems GmbH & Co. KG The company is a limited partnership with its registered office in Poing ? Trade Register HRA 100955 (Amtsgericht M?nchen) ? WEEE-Reg.-No. DE 888 05 443 General Partner: Oc? Printing Systems Gesch?ftsf?hrungsgesellschaft mbH Registered Office: Poing ? Trade Register HRB 206480 (Amtsgericht M?nchen) Executive Officer: Andr? Mittelsteiner, Hans Manzer This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation. From gjn at gjn.priv.at Mon Apr 28 09:57:45 2014 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Mon, 28 Apr 2014 17:57:45 +0200 Subject: [sles-beta] Kernel: use_tempaddr = 0 and Forwarding Message-ID: <2149138.iFlvDEgr3B@gjn.priv.at> Hello, Question: Is it really a good idea to activate in SLES ipv6 ..._use_tempaddr = 1. I like to configure my server with "static" Addresses for IPv6 but it is nearly not Possible. I have set in /sysctl.d/@99-sysctl.conf net.ipv6.conf.all.use_tempaddr = 0 net.ipv6.conf.default.use_tempaddr = 0 but the most time, I have on my IPv6 bridge two IPv6 Addresses my static and a tmpaddr (global) ? Question2: Is in YaST2 Networkconfig the Forwarding Button functional? Is this a Firewall config or Kernel Config ? I have to set for a working IPv6 net.ipv6.conf.all.forwarding = 1 in the sysctl.conf than I can connect with IPv6 ? -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From jsmeix at suse.de Tue Apr 29 03:39:22 2014 From: jsmeix at suse.de (Johannes Meixner) Date: Tue, 29 Apr 2014 11:39:22 +0200 (CEST) Subject: [sles-beta] Issues on Beta4 In-Reply-To: <535E6B2B.8040104@oce.com> References: <534CC1E2.6080808@oce.com> <20140417093911.GA16665@linux-w520.guibland.com> <535E6B2B.8040104@oce.com> Message-ID: Hello, On Apr 28 16:52 Klaus Gmeinwieser wrote (excerpt): > I just wanted to remove cups server and > any related printerdriver packages et. al. Package cups libs could be > installed to satisfy any software dependencies. But I will not use cups > and we deliver software which conflicts with CUPS server so I would > appreciate the possibility to uninstall cups so that "no printer > (software) available" messages will come up. I submitted https://bugzilla.novell.com/show_bug.cgi?id=875606 so that the Gnome experts can have a look. Only out of my own personal curiosity: What conflict is it that your software cannot coexist with CUPS? I ask because CUPS is usually installed on any Linux system so that software that cannot coexist with CUPS looks a bit "antagonistic" from my current point of view. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer From Klaus.Gmeinwieser at oce.com Tue Apr 29 04:38:07 2014 From: Klaus.Gmeinwieser at oce.com (Klaus Gmeinwieser) Date: Tue, 29 Apr 2014 12:38:07 +0200 Subject: [sles-beta] Issues on Beta4 In-Reply-To: References: <534CC1E2.6080808@oce.com> <20140417093911.GA16665@linux-w520.guibland.com> <535E6B2B.8040104@oce.com> Message-ID: <535F810F.9030202@oce.com> Hi Johannes, our product is a complete printing solution supporting from input modules to driving multiple printers. For compatibility to older versions, we also have e.g. lpr, ipp modules. With SLE10 and SLE11 only cups-client and cups-libs was installed/required and this was fine with us.... Rgds Klaus Am 29.04.2014 11:39, schrieb Johannes Meixner: > > Hello, > > On Apr 28 16:52 Klaus Gmeinwieser wrote (excerpt): >> I just wanted to remove cups server and >> any related printerdriver packages et. al. Package cups libs could be >> installed to satisfy any software dependencies. But I will not use cups >> and we deliver software which conflicts with CUPS server so I would >> appreciate the possibility to uninstall cups so that "no printer >> (software) available" messages will come up. > > I submitted > https://bugzilla.novell.com/show_bug.cgi?id=875606 > so that the Gnome experts can have a look. > > > Only out of my own personal curiosity: > > What conflict is it that your software cannot coexist with CUPS? > > I ask because CUPS is usually installed on any Linux system > so that software that cannot coexist with CUPS looks > a bit "antagonistic" from my current point of view. > > > Kind Regards > Johannes Meixner -- Klaus Gmeinwieser T +49 (0)8121 72 4358 F +49 (0)8121 72 3173 E klaus.gmeinwieser at oce.com W www.oce.com Oc? Printing Systems GmbH & Co. KG ? A Canon Group Company P.O. Box 1260 ? 85581 Poing Siemensallee 2 ? 85586 Poing ? Germany Oc? enables its customers to manage their documents efficiently and effectively by offering innovative print and document management products and services for professional environments. Oc? Printing Systems GmbH & Co. KG The company is a limited partnership with its registered office in Poing ? Trade Register HRA 100955 (Amtsgericht M?nchen) ? WEEE-Reg.-No. DE 888 05 443 General Partner: Oc? Printing Systems Gesch?ftsf?hrungsgesellschaft mbH Registered Office: Poing ? Trade Register HRB 206480 (Amtsgericht M?nchen) Executive Officer: Andr? Mittelsteiner, Hans Manzer This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation. From Klaus.Gmeinwieser at oce.com Tue Apr 29 07:55:45 2014 From: Klaus.Gmeinwieser at oce.com (Klaus Gmeinwieser) Date: Tue, 29 Apr 2014 15:55:45 +0200 Subject: [sles-beta] Language Issues on Beta5 Message-ID: <535FAF61.2040105@oce.com> Hi all, I just adapt my minimal unattended installation to try and support new installation languages. First was to try Japanese. I replaced the "en_US" language setting to "ja_JP", but starting the Installation with default 'English" language - it will be changes later on according to the settings in the autoinst.xml file... This leads to many many "sqares" in the YaST setup screens and also while installation details of the installed packages are shown - however some Japanese "characters" are shown correct. Also GNOME does not appear in Japanese localization and the scim software is not installed automatically (which was done by YaST in SLE11 to support Japanese keyboards automatically)... Installing scim pus scim-bridge (32-Bit) leads to automatic installation of 141 additional 32-Bit packages (142MB!) to satisfy dependencies?????? Also I did not get the scim activated, as there is no system tray (like in KDE) and CTRL+Space does not activate it automatically... How is the status of Asian aka. Japanese, Chinese, Korean and Cyrillic based languages in Beta5? (Should I try the installation in Russian?) Should this work already or is the full localization scheduled for a later BETA? In order to make a screenshot from a different system I enabled vnc control with using the parameter line: autoyast=usb net.ifnames=o vnc:1 vncpassword: But this leads to a non DHCP enabled network (necessary!!) card, after manually enabling the NIC a portscan leads to an open port 6000, vncviewer connections fail... (also Xnest, Xephyr...) Also the VNC commandline parameters WITH THE PASSWORD was copied to the final grub2.cfg file! Is this intended to work in BETA5? I will open service requests on these issues... Thanks a lot in advance Rgds Klaus -- Klaus Gmeinwieser T +49 (0)8121 72 4358 F +49 (0)8121 72 3173 E klaus.gmeinwieser at oce.com W www.oce.com Oc? Printing Systems GmbH & Co. KG ? A Canon Group Company P.O. Box 1260 ? 85581 Poing Siemensallee 2 ? 85586 Poing ? Germany Oc? enables its customers to manage their documents efficiently and effectively by offering innovative print and document management products and services for professional environments. Oc? Printing Systems GmbH & Co. KG The company is a limited partnership with its registered office in Poing ? Trade Register HRA 100955 (Amtsgericht M?nchen) ? WEEE-Reg.-No. DE 888 05 443 General Partner: Oc? Printing Systems Gesch?ftsf?hrungsgesellschaft mbH Registered Office: Poing ? Trade Register HRB 206480 (Amtsgericht M?nchen) Executive Officer: Andr? Mittelsteiner, Hans Manzer This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation. From jsmeix at suse.de Tue Apr 29 08:04:42 2014 From: jsmeix at suse.de (Johannes Meixner) Date: Tue, 29 Apr 2014 16:04:42 +0200 (CEST) Subject: [sles-beta] Issues on Beta4 In-Reply-To: <535F810F.9030202@oce.com> References: <534CC1E2.6080808@oce.com> <20140417093911.GA16665@linux-w520.guibland.com> <535E6B2B.8040104@oce.com> <535F810F.9030202@oce.com> Message-ID: Hello Klaus, the issue may become off-topic on this mailing list. Personally I don't mind but perhaps other do? If you like we can continue via personal mail. On the other hand, the issue could be of general interest because it could be an example how other software could coexist with SLE12 standard software. On Apr 29 12:38 Klaus Gmeinwieser wrote (excerpt): > our product is a complete printing solution supporting from input > modules to driving multiple printers. For compatibility to older > versions, we also have e.g. lpr, ipp modules. > With SLE10 and SLE11 only cups-client and cups-libs was > installed/required and this was fine with us.... I still cannot imagine what real conflict there could be between your software and CUPS. Currently I could only imagine file conflicts. I.e. when your software provides same files as CUPS. In particular when your software provides binaries like /usr/bin/lp that are also provided by the cups-client RPM. But as you wrote an installed cups-client RPM did not cause a conflict with your software, I do not understand what in the cups RPM causes a real conflict with your software. For example - as far as I see - the cupsd in the cups RPM does not cause a real conflict with any other IPP server when that other IPP server is not installed as /usr/sbin/cupsd. Of course a running cupsd conflicts with with any other running IPP server (i.e. any other listener on port 631) but that is not a conflict with the /usr/sbin/cupsd file in the cups RPM. >From my current point of view I have the gut feeling that what looks like a hard conflict between your software and CUPS is perhaps basically "false alarm" and actually your software could coexist with an installed CUPS regardless whether or not having CUPS installed without running cupsd makes much sense. As far as I currently see: If your software and CUPS do not have same files, your software could be "just installed" on a standard SLE12 system. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer From fcrozat at suse.com Tue Apr 29 08:10:07 2014 From: fcrozat at suse.com (Frederic Crozat) Date: Tue, 29 Apr 2014 16:10:07 +0200 Subject: [sles-beta] Language Issues on Beta5 In-Reply-To: <535FAF61.2040105@oce.com> References: <535FAF61.2040105@oce.com> Message-ID: <1398780607.2036.78.camel@par-r81vxc7.par.novell.com> Le mardi 29 avril 2014 ? 15:55 +0200, Klaus Gmeinwieser a ?crit : > Hi all, > > I just adapt my minimal unattended installation to try and support new > installation languages. > > First was to try Japanese. I replaced the "en_US" language setting to > "ja_JP", but starting the Installation with default 'English" language - > it will be changes later on according to the settings in the > autoinst.xml file... > > This leads to many many "sqares" in the YaST setup screens and also > while installation details of the installed packages are shown - however > some Japanese "characters" are shown correct. This is a known issue in the installer, under investigation. > Also GNOME does not appear in Japanese localization and the scim > software is not installed automatically (which was done by YaST in SLE11 > to support Japanese keyboards automatically)... > Installing scim pus scim-bridge (32-Bit) leads to automatic installation > of 141 additional 32-Bit packages (142MB!) to satisfy dependencies?????? > Also I did not get the scim activated, as there is no system tray (like > in KDE) and CTRL+Space does not activate it automatically... SCIM is being deprecated, in favor of ibus (for Chinese, fcitx will also be available in SLED and SLED Extension). > How is the status of Asian aka. Japanese, Chinese, Korean and Cyrillic > based languages in Beta5? (Should I try the installation in Russian?) > Should this work already or is the full localization scheduled for a > later BETA? Translations have not been integrated yet, but the rest of localisation framework is already in place, so please test already. > In order to make a screenshot from a different system I enabled vnc > control with using the parameter line: > > autoyast=usb net.ifnames=o vnc:1 vncpassword: > > But this leads to a non DHCP enabled network (necessary!!) card, after > manually enabling the NIC a portscan leads to an open port 6000, > vncviewer connections fail... (also Xnest, Xephyr...) Also the VNC > commandline parameters WITH THE PASSWORD was copied to the final > grub2.cfg file! > > Is this intended to work in BETA5? > I will open service requests on these issues... Please do ! -- Frederic Crozat Project Manager Enterprise Desktop SUSE From Klaus.Gmeinwieser at oce.com Tue Apr 29 09:22:39 2014 From: Klaus.Gmeinwieser at oce.com (Klaus Gmeinwieser) Date: Tue, 29 Apr 2014 17:22:39 +0200 Subject: [sles-beta] Issues on Beta4 In-Reply-To: References: <534CC1E2.6080808@oce.com> <20140417093911.GA16665@linux-w520.guibland.com> <535E6B2B.8040104@oce.com> <535F810F.9030202@oce.com> Message-ID: <535FC3BF.3050407@oce.com> Hello Johannes, thanks for your quick answer. I see I need to go in more detail. @ALL: this is not intended to annoy the list, but an important question to me. If this should be off topic -> please tell me The coexistence with SLES standard software is not the problem at all. As we install a production printing suite on the SLES it is required from our side, that any misconfiguration is prevented on best effort (what is not installed cannot be started or used accidentally). Having both software packages installed is just one part of the conflict (a started cups server will block the TCP/IP ports for our software as first problem). As we are shipping to customers worldwide, the existence of the cups software (especially the server) will conflict with our policies not to use the SLES for any other purpose. This is also true for the apache server not to be allowed on our installations for use of ports 80/443. We had several severe issues on (so called) "experts" using/trying cups/apache in parallel with our software (not going into details). This is also an issue of better supportability for our service people. In my opinion, the best way is not to install any unwanted service or to be urged to do so. As an example I would point to the rsh/rexec which is also not installed (I know for security) or the apache server - if I want to use it I have to install it. I cannot see the difference between a print server being a fixed part of the SLES and any other service being not? (Anyway I cannot see any requirement for cups server on an enterprise machine except a print server) Please advise what we can do... Thanks in advance & Rgds Klaus Am 29.04.2014 16:04, schrieb Johannes Meixner: > > Hello Klaus, > > the issue may become off-topic on this mailing list. > Personally I don't mind but perhaps other do? > If you like we can continue via personal mail. > On the other hand, the issue could be of general interest > because it could be an example how other software could > coexist with SLE12 standard software. > > On Apr 29 12:38 Klaus Gmeinwieser wrote (excerpt): >> our product is a complete printing solution supporting from input >> modules to driving multiple printers. For compatibility to older >> versions, we also have e.g. lpr, ipp modules. >> With SLE10 and SLE11 only cups-client and cups-libs was >> installed/required and this was fine with us.... > > I still cannot imagine what real conflict there could be > between your software and CUPS. > > Currently I could only imagine file conflicts. > I.e. when your software provides same files as CUPS. > In particular when your software provides binaries like > /usr/bin/lp that are also provided by the cups-client RPM. > > But as you wrote an installed cups-client RPM did not cause > a conflict with your software, I do not understand what in > the cups RPM causes a real conflict with your software. > > For example - as far as I see - the cupsd in the cups RPM > does not cause a real conflict with any other IPP server > when that other IPP server is not installed as /usr/sbin/cupsd. > > Of course a running cupsd conflicts with with any other running > IPP server (i.e. any other listener on port 631) but that is > not a conflict with the /usr/sbin/cupsd file in the cups RPM. > > From my current point of view I have the gut feeling that what > looks like a hard conflict between your software and CUPS > is perhaps basically "false alarm" and actually your software > could coexist with an installed CUPS regardless whether or not > having CUPS installed without running cupsd makes much sense. > > As far as I currently see: If your software and CUPS do not have > same files, your software could be "just installed" on a standard > SLE12 system. > > > Kind Regards > Johannes Meixner -- Klaus Gmeinwieser T +49 (0)8121 72 4358 F +49 (0)8121 72 3173 E klaus.gmeinwieser at oce.com W www.oce.com Oc? Printing Systems GmbH & Co. KG ? A Canon Group Company P.O. Box 1260 ? 85581 Poing Siemensallee 2 ? 85586 Poing ? Germany Oc? enables its customers to manage their documents efficiently and effectively by offering innovative print and document management products and services for professional environments. Oc? Printing Systems GmbH & Co. KG The company is a limited partnership with its registered office in Poing ? Trade Register HRA 100955 (Amtsgericht M?nchen) ? WEEE-Reg.-No. DE 888 05 443 General Partner: Oc? Printing Systems Gesch?ftsf?hrungsgesellschaft mbH Registered Office: Poing ? Trade Register HRB 206480 (Amtsgericht M?nchen) Executive Officer: Andr? Mittelsteiner, Hans Manzer This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation. From rbrown at suse.de Tue Apr 29 09:31:30 2014 From: rbrown at suse.de (Richard Brown) Date: Tue, 29 Apr 2014 17:31:30 +0200 Subject: [sles-beta] Issues on Beta4 In-Reply-To: <535FC3BF.3050407@oce.com> References: <534CC1E2.6080808@oce.com> <20140417093911.GA16665@linux-w520.guibland.com> <535E6B2B.8040104@oce.com> <535F810F.9030202@oce.com> <535FC3BF.3050407@oce.com> Message-ID: <30a8a8f8-870f-4ae2-98c2-3c4e86d2c683@email.android.com> My advice would be using systemd's mask feature to make it next to impossible for the CUPS service to be started http://0pointer.de/blog/projects/three-levels-of-off http://www.freedesktop.org/software/systemd/man/systemctl.html Apologies for my brevity, written while boarding a flight - Richard Brown QA Engineer, SUSE On 29 April 2014 17:22:39 CEST, Klaus Gmeinwieser wrote: >Hello Johannes, > >thanks for your quick answer. I see I need to go in more detail. > >@ALL: this is not intended to annoy the list, but an important question >to me. If this should be off topic -> please tell me > >The coexistence with SLES standard software is not the problem at all. >As we install a production printing suite on the SLES it is required >from our side, that any misconfiguration is prevented on best effort >(what is not installed cannot be started or used accidentally). > >Having both software packages installed is just one part of the >conflict >(a started cups server will block the TCP/IP ports for our software as >first problem). As we are shipping to customers worldwide, the >existence >of the cups software (especially the server) will conflict with our >policies not to use the SLES for any other purpose. This is also true >for the apache server not to be allowed on our installations for use of >ports 80/443. > >We had several severe issues on (so called) "experts" using/trying >cups/apache in parallel with our software (not going into details). >This is also an issue of better supportability for our service people. > >In my opinion, the best way is not to install any unwanted service or >to >be urged to do so. As an example I would point to the rsh/rexec which >is >also not installed (I know for security) or the apache server - if I >want to use it I have to install it. I cannot see the difference >between >a print server being a fixed part of the SLES and any other service >being not? (Anyway I cannot see any requirement for cups server on an >enterprise machine except a print server) > >Please advise what we can do... > >Thanks in advance & Rgds >Klaus > >Am 29.04.2014 16:04, schrieb Johannes Meixner: >> >> Hello Klaus, >> >> the issue may become off-topic on this mailing list. >> Personally I don't mind but perhaps other do? >> If you like we can continue via personal mail. >> On the other hand, the issue could be of general interest >> because it could be an example how other software could >> coexist with SLE12 standard software. >> >> On Apr 29 12:38 Klaus Gmeinwieser wrote (excerpt): >>> our product is a complete printing solution supporting from input >>> modules to driving multiple printers. For compatibility to older >>> versions, we also have e.g. lpr, ipp modules. >>> With SLE10 and SLE11 only cups-client and cups-libs was >>> installed/required and this was fine with us.... >> >> I still cannot imagine what real conflict there could be >> between your software and CUPS. >> >> Currently I could only imagine file conflicts. >> I.e. when your software provides same files as CUPS. >> In particular when your software provides binaries like >> /usr/bin/lp that are also provided by the cups-client RPM. >> >> But as you wrote an installed cups-client RPM did not cause >> a conflict with your software, I do not understand what in >> the cups RPM causes a real conflict with your software. >> >> For example - as far as I see - the cupsd in the cups RPM >> does not cause a real conflict with any other IPP server >> when that other IPP server is not installed as /usr/sbin/cupsd. >> >> Of course a running cupsd conflicts with with any other running >> IPP server (i.e. any other listener on port 631) but that is >> not a conflict with the /usr/sbin/cupsd file in the cups RPM. >> >> From my current point of view I have the gut feeling that what >> looks like a hard conflict between your software and CUPS >> is perhaps basically "false alarm" and actually your software >> could coexist with an installed CUPS regardless whether or not >> having CUPS installed without running cupsd makes much sense. >> >> As far as I currently see: If your software and CUPS do not have >> same files, your software could be "just installed" on a standard >> SLE12 system. >> >> >> Kind Regards >> Johannes Meixner > >-- >Klaus Gmeinwieser >T +49 (0)8121 72 4358 F +49 (0)8121 72 3173 >E klaus.gmeinwieser at oce.com W www.oce.com > >Oc? Printing Systems GmbH & Co. KG ? A Canon Group Company >P.O. Box 1260 ? 85581 Poing >Siemensallee 2 ? 85586 Poing ? Germany > >Oc? enables its customers to manage their documents efficiently and >effectively by offering >innovative print and document management products and services for >professional >environments. > >Oc? Printing Systems GmbH & Co. KG >The company is a limited partnership with its registered office in >Poing >? Trade Register HRA 100955 (Amtsgericht M?nchen) ? WEEE-Reg.-No. DE >888 >05 443 > >General Partner: Oc? Printing Systems Gesch?ftsf?hrungsgesellschaft mbH >Registered Office: Poing ? Trade Register HRB 206480 (Amtsgericht >M?nchen) >Executive Officer: Andr? Mittelsteiner, Hans Manzer >This message and attachment(s) are intended solely for use by the >addressee and may contain information that is privileged, confidential >or otherwise exempt from disclosure under applicable law. If you are >not the intended recipient or agent thereof responsible for delivering >this message to the intended recipient, you are hereby notified that >any dissemination, distribution or copying of this communication is >strictly prohibited. If you have received this communication in error, >please notify the sender immediately by telephone and with a 'reply' >message. Thank you for your co-operation. >_______________________________________________ >sles-beta mailing list >sles-beta at lists.suse.com >http://lists.suse.com/mailman/listinfo/sles-beta -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.baensch at dfs.de Tue Apr 29 22:56:54 2014 From: michael.baensch at dfs.de (Michael Baensch) Date: Wed, 30 Apr 2014 04:56:54 +0000 Subject: [sles-beta] autoyast Issue on Beta4 Message-ID: <9f542e3a27a943a7aa68808e63cac368@LGNMSXB02.prod.bk.dfs> Installing SLES12 beta4 with an autoyast.xml file raises an error during partitioning: Failure occurred during the following action: Formatting logical volume /dev/system/root (3.00 GiB) with ext3 System error code was: -3306 The same with other ext3 lvm based partitions What is Error -3306 ? The system seems to install anyway when clicking ?Continue? Regards Michael 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gjn at gjn.priv.at Tue Apr 29 23:56:34 2014 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Wed, 30 Apr 2014 07:56:34 +0200 Subject: [sles-beta] Network "Wicked" Message-ID: <10521763.XR7fWcfgph@gjn.priv.at> Hello, I mean I have a problem with wicked on my System? I am test the Network "openvswitch &" with KVM and ....sometime I lost my Intel dual NIC Card, this Card are not initialize on Start. I have also two Nic on Board, this are initialized. The Card is OK. I the Moment I can only make a new Install and all is working again. My Question is, I can't found the config file for wicked and no logs from this Program and Doc's (?). This is a hard test for me ;). -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From pwieczorkiewicz at suse.de Wed Apr 30 00:52:43 2014 From: pwieczorkiewicz at suse.de (Pawel Wieczorkiewicz) Date: Wed, 30 Apr 2014 08:52:43 +0200 Subject: [sles-beta] Network "Wicked" In-Reply-To: <10521763.XR7fWcfgph@gjn.priv.at> References: <10521763.XR7fWcfgph@gjn.priv.at> Message-ID: <20140430085243.6be99eeb@hammer76.arch.suse.de> On Wed, 30 Apr 2014 07:56:34 +0200 G?nther J. Niederwimmer wrote: > Hello, > > I mean I have a problem with wicked on my System? > > I am test the Network "openvswitch &" with KVM and ....sometime I > lost my Intel dual NIC Card, this Card are not initialize on Start. I > have also two Nic on Board, this are initialized. > This seems to be hardly wicked related problem (wicked only applies existing configuration to existing or hotplugging devices). Do you mean that NIC interface is not present in your system? Is driver loaded? You could also check what is happening in dracut. To do so, you could specify "rd.debug" parameter on the kernel command line to get dracut logs. > The Card is OK. > > I the Moment I can only make a new Install and all is working again. > > My Question is, I can't found the config file for wicked and no logs > from this Program and Doc's (?). Here is in short what we recommend to do, to get all wicked logs: 1) set DEBUG=all in /etc/sysconfig/network/config 2) systemctl restart wickedd 3) wicked --debug all ifup all # systemctl restart wicked 4) wicked ifstatus all > status.log 5) wicked show-config > configs.log 6) journalctl -b -o short-iso > wicked.log 7) ip addr show > ip_addr.log 8) ip route show > routes.log 9) ip -6 route show >> routes.log In general wicked debugging options are: 1) Command line - wicked --debug Enables debug level and sets filters by wicked facilities, e.g.: "all,-events,-socket,-objectmodel,-xpath,-xml,-dbus" - wicked --log-level - wicked --log-target 2) Global - /etc/sysconfig/network/config - WICKED_DEBUG=most same to ?debug option, applied to all services - WICKED_LOG_LEVEL=?debug2? same to ?log-level, applied to all services - DEBUG= Compatibility fallback for WICKED_DEBUG, maps ?yes? to ?most? Useful hints for logging: - journalctl: journalctl -b -o short-iso > wicked.log - rsyslog: # /etc/rsyslog.d/wicked.conf if ($programname startswith 'wicked') \ then -/var/log/wicked.log & ~ > > This is a hard test for 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 ohering at suse.de Wed Apr 30 00:55:14 2014 From: ohering at suse.de (Olaf Hering) Date: Wed, 30 Apr 2014 08:55:14 +0200 Subject: [sles-beta] Network "Wicked" In-Reply-To: <10521763.XR7fWcfgph@gjn.priv.at> References: <10521763.XR7fWcfgph@gjn.priv.at> Message-ID: <20140430065514.GA22316@suse.de> On Wed, Apr 30, G?nther J. Niederwimmer wrote: > My Question is, I can't found the config file for wicked and no logs from this > Program and Doc's (?). Docs are outdated. The logs for wicked can be found by 'journalctl -b | less -S'. To make wicked verbose append WICKED_DEBUG="all" to /etc/sysconfig/network/config: echo WICKED_DEBUG=all >> /etc/sysconfig/network/config The config files did not change, wicked continues to use the ifcfg-* files in /etc/sysconfig/network/ Please make the change to /etc/sysconfig/network/config, reboot and open a SR with output from 'journalctl -b' and all the ifcfg-* files from /etc/sysconfig/network/. Thanks. Olaf From jreidinger at suse.cz Wed Apr 30 02:05:52 2014 From: jreidinger at suse.cz (Josef Reidinger) Date: Wed, 30 Apr 2014 10:05:52 +0200 Subject: [sles-beta] autoyast Issue on Beta4 In-Reply-To: <9f542e3a27a943a7aa68808e63cac368@LGNMSXB02.prod.bk.dfs> References: <9f542e3a27a943a7aa68808e63cac368@LGNMSXB02.prod.bk.dfs> Message-ID: <20140430100552.3b6b2b9f@linux-5mqx.site> On Wed, 30 Apr 2014 04:56:54 +0000 "Michael Baensch" wrote: > > Installing SLES12 beta4 with an autoyast.xml file raises an error > during partitioning: > > Failure occurred during the following action: > Formatting logical volume /dev/system/root (3.00 GiB) with ext3 > System error code was: -3306 > > The same with other ext3 lvm based partitions > What is Error -3306 ? > > The system seems to install anyway when clicking ?Continue? > It is bug and it should be fixed in beta6. Just error code was 3006 and not 3306. Is it typo or different bug? (but symptoms ext3 + LVM is same ). Josef From jsmeix at suse.de Wed Apr 30 04:21:59 2014 From: jsmeix at suse.de (Johannes Meixner) Date: Wed, 30 Apr 2014 12:21:59 +0200 (CEST) Subject: [sles-beta] Issues on Beta4 In-Reply-To: <535FC3BF.3050407@oce.com> References: <534CC1E2.6080808@oce.com> <20140417093911.GA16665@linux-w520.guibland.com> <535E6B2B.8040104@oce.com> <535F810F.9030202@oce.com> <535FC3BF.3050407@oce.com> Message-ID: Hello Klaus, On Apr 29 17:22 Klaus Gmeinwieser wrote (excerpt): > The coexistence with SLES standard software is not the problem at all. > As we install a production printing suite on the SLES it is required > from our side, that any misconfiguration is prevented on best effort > (what is not installed cannot be started or used accidentally). > > Having both software packages installed is just one part of the conflict > (a started cups server will block the TCP/IP ports for our software as > first problem). As we are shipping to customers worldwide, the existence > of the cups software (especially the server) will conflict with our > policies not to use the SLES for any other purpose. This is also true > for the apache server not to be allowed on our installations for use of > ports 80/443. > > We had several severe issues on (so called) "experts" using/trying > cups/apache in parallel with our software (not going into details). > This is also an issue of better supportability for our service people. Now I understand and https://bugzilla.novell.com/show_bug.cgi?id=875606 (Gnome has a hard RPM requirement for the whole CUPS) makes even more sense now. I wonder to what extent nowadays desktop systems and application programs "just assume" that CUPS is available as base printing system? I mean to what extent nowadays desktops and applications that are linked with CUPS libraries can work in a usable way when only the CUPS libraries are installed (so that the programs are able to run technically) but when the rest of CUPS is not available to what extent those programs are still able to provide actually useful printing functionality to the user (e.g. to print something or choose a printer and so on)? > In my opinion, the best way is not to install any unwanted service or to > be urged to do so. As an example I would point to the rsh/rexec which is > also not installed (I know for security) or the apache server - if I > want to use it I have to install it. I cannot see the difference between > a print server being a fixed part of the SLES and any other service > being not? (Anyway I cannot see any requirement for cups server on an > enterprise machine except a print server) A running cupsd is needed for "usual" printing on client systems. I.e. CUPS is usually needed. Therefore CUPS is installed by default. In contrast a HTTP server is usually not needed. But since SLE12 the cupsd is no longer started by default, see https://bugzilla.novell.com/show_bug.cgi?id=870425 (systemd-presets-branding-SLE: have cups disabled by default) i.e. there is no "cups" in /usr/lib/systemd/system-preset/90-default-SLE.preset Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer From michael.baensch at dfs.de Wed Apr 30 05:02:09 2014 From: michael.baensch at dfs.de (Michael Baensch) Date: Wed, 30 Apr 2014 11:02:09 +0000 Subject: [sles-beta] autoyast Issue on Beta4 In-Reply-To: <20140430100552.3b6b2b9f@linux-5mqx.site> References: <9f542e3a27a943a7aa68808e63cac368@LGNMSXB02.prod.bk.dfs> <20140430100552.3b6b2b9f@linux-5mqx.site> Message-ID: Yes, it was a typo. Thank you, Michael -----Urspr?ngliche Nachricht----- Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Josef Reidinger Gesendet: Mittwoch, 30. April 2014 10:06 An: sles-beta at lists.suse.com Betreff: Re: [sles-beta] autoyast Issue on Beta4 On Wed, 30 Apr 2014 04:56:54 +0000 "Michael Baensch" wrote: > > Installing SLES12 beta4 with an autoyast.xml file raises an error > during partitioning: > > Failure occurred during the following action: > Formatting logical volume /dev/system/root (3.00 GiB) with ext3 System > error code was: -3306 > > The same with other ext3 lvm based partitions What is Error -3306 ? > > The system seems to install anyway when clicking ?Continue? > It is bug and it should be fixed in beta6. Just error code was 3006 and not 3306. Is it typo or different bug? (but symptoms ext3 + LVM is same ). Josef _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta DFS Deutsche Flugsicherung GmbH Am DFS-Campus D - 63225 Langen Tel.: +49-(0)6103-707-0 Sitz der Gesellschaft: Langen/Hessen Zust?ndiges Registergericht: AG Offenbach am Main, HRB 34977 Vorsitzender des Aufsichtsrates: Michael Odenwald Gesch?ftsf?hrer: Prof. Klaus-Dieter Scheurle (Vors.), Robert Schickling, Dr. Michael Hann Internet: http://www.dfs.de Public-Key der DFS: http://www.dfs.de/dfs/public_key.asc From stephan.mueller at atsec.com Wed Apr 30 06:45:15 2014 From: stephan.mueller at atsec.com (Stephan Mueller) Date: Wed, 30 Apr 2014 14:45:15 +0200 Subject: [sles-beta] Yast auto install features Message-ID: <2880600.5y59KBpX6k@tauon> Hi, as Yast is rewritten I am wondering whether the auto install features survived and where they are documented (or are they still identical to SLES11?)? Thanks a lot Stephan From jreidinger at suse.com Wed Apr 30 07:01:16 2014 From: jreidinger at suse.com (Josef Reidinger) Date: Wed, 30 Apr 2014 15:01:16 +0200 Subject: [sles-beta] Yast auto install features In-Reply-To: <2880600.5y59KBpX6k@tauon> References: <2880600.5y59KBpX6k@tauon> Message-ID: <20140430150116.3308fbf3@linux-5mqx.site> On Wed, 30 Apr 2014 14:45:15 +0200 "Stephan Mueller" wrote: > Hi, > > as Yast is rewritten I am wondering whether the auto install features > survived and where they are documented (or are they still identical > to SLES11?)? > Hi, autoyast feature survived. To make it clear YaST was transpiled to ruby, not rewritten, so all code survived unless we changed it later based on feature requests. In general a lot of parts of SLE11 documentation is still valid. I know only about runlevel -> services change that is related to different way how initd and systemd works. And about bootloader as grub2 is now only supported bootloader, so if you have old config for grub1 or similar for other archs, it won't work ( I do not try what will be exact behavior if it will be silently reproposed or ends up in error ). I do not know about any recent SLE12 autoyast documentation. Josef From aginies at suse.com Wed Apr 30 07:03:58 2014 From: aginies at suse.com (Antoine Ginies) Date: Wed, 30 Apr 2014 15:03:58 +0200 Subject: [sles-beta] Yast auto install features In-Reply-To: <2880600.5y59KBpX6k@tauon> References: <2880600.5y59KBpX6k@tauon> Message-ID: <20140430130358.GH18712@linux-w520.guibland.com> Stephan Mueller: > Hi, > as Yast is rewritten I am wondering whether the auto install features > survived and where they are documented (or are they still identical to > SLES11?)? doc is available at: http://docserv.suse.de/documents/SLES12/SLES-autoyast/ according to changelog, there is not a lot of diff with previous autoyast available in SLE11. -- Antoine Ginies Project Manager SUSE France From aginies at suse.com Wed Apr 30 07:11:44 2014 From: aginies at suse.com (Antoine Ginies) Date: Wed, 30 Apr 2014 15:11:44 +0200 Subject: [sles-beta] Yast auto install features In-Reply-To: <20140430130358.GH18712@linux-w520.guibland.com> References: <2880600.5y59KBpX6k@tauon> <20140430130358.GH18712@linux-w520.guibland.com> Message-ID: <20140430131144.GI18712@linux-w520.guibland.com> Ginies: > Stephan Mueller: > > Hi, > > as Yast is rewritten I am wondering whether the auto install features > > survived and where they are documented (or are they still identical to > > SLES11?)? > > doc is available at: > http://docserv.suse.de/documents/SLES12/SLES-autoyast/ > > according to changelog, there is not a lot of diff with previous > autoyast available in SLE11. Sorry, i point you to our internal documentation devel server... There is no online doc for SLE12 yet. But you can find the update documentation on the DVD: package name is: sles-autoyast_en-pdf regards. -- Antoine Ginies Project Manager SUSE France From stephan.mueller at atsec.com Wed Apr 30 07:14:11 2014 From: stephan.mueller at atsec.com (Stephan Mueller) Date: Wed, 30 Apr 2014 15:14:11 +0200 Subject: [sles-beta] Yast auto install features In-Reply-To: <20140430131144.GI18712@linux-w520.guibland.com> References: <2880600.5y59KBpX6k@tauon> <20140430130358.GH18712@linux-w520.guibland.com> <20140430131144.GI18712@linux-w520.guibland.com> Message-ID: <4728174.VqCejbjjnN@tauon> Am Mittwoch, 30. April 2014, 15:11:44 schrieb Antoine Ginies: Hi Antoine, >Ginies: >> Stephan Mueller: >> > Hi, >> > as Yast is rewritten I am wondering whether the auto install >> > features >> > survived and where they are documented (or are they still identical >> > to >> > SLES11?)? >> >> doc is available at: >> http://docserv.suse.de/documents/SLES12/SLES-autoyast/ >> >> according to changelog, there is not a lot of diff with previous >> autoyast available in SLE11. > >Sorry, >i point you to our internal documentation devel server... >There is no online doc for SLE12 yet. >But you can find the update documentation on the DVD: >package name is: sles-autoyast_en-pdf Thanks a lot for the pointers. > > >regards. Ciao Stephan From stephan.mueller at atsec.com Wed Apr 30 07:41:37 2014 From: stephan.mueller at atsec.com (Stephan Mueller) Date: Wed, 30 Apr 2014 15:41:37 +0200 Subject: [sles-beta] Yast auto install features In-Reply-To: <20140430150116.3308fbf3@linux-5mqx.site> References: <2880600.5y59KBpX6k@tauon> <20140430150116.3308fbf3@linux-5mqx.site> Message-ID: <2050403.q17T1QIQgQ@tauon> Am Mittwoch, 30. April 2014, 15:01:16 schrieb Josef Reidinger: Hi Josef, >On Wed, 30 Apr 2014 14:45:15 +0200 > >"Stephan Mueller" wrote: >> Hi, >> >> as Yast is rewritten I am wondering whether the auto install features >> survived and where they are documented (or are they still identical >> to SLES11?)? > >Hi, >autoyast feature survived. To make it clear YaST was transpiled to >ruby, not rewritten, so all code survived unless we changed it later >based on feature requests. >In general a lot of parts of SLE11 documentation is still valid. I know >only about runlevel -> services change that is related to different >way how initd and systemd works. And about bootloader as grub2 is now >only supported bootloader, so if you have old config for grub1 or >similar for other archs, it won't work ( I do not try what will be >exact behavior if it will be silently reproposed or ends up in error >). I do not know about any recent SLE12 autoyast documentation. Thanks a lot for the clarification. Ciao Stephan From urs.frey at post.ch Thu May 1 01:42:38 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Thu, 1 May 2014 07:42:38 +0000 Subject: [sles-beta] Beta 5 and VMware-tools In-Reply-To: <589429196.9770799.1398312303741.JavaMail.root@vmware.com> References: <53555B96.3060606@netlab1.net> <53569F99.30702@netlab1.net> <5356B3C9.1020809@netlab1.net> <40637DBB36AF3941B243A286A432CA0B0EFAFCBA@HXMB12.pnet.ch> <5357C35D.60701@netlab1.net> <5357D093.8030104@suse.com> <5357E647.1070603@netlab1.net> <589429196.9770799.1398312303741.JavaMail.root@vmware.com> Message-ID: <40637DBB36AF3941B243A286A432CA0B0EFB27FE@HXMB12.pnet.ch> Hi Bo Thank you very much for your concern and explanations. See you only mention open-vm-tools. But there are the VMwareTools coming with the ESXi release itself. So there are two branches of VMwareTools obviously having different states at VMware itself in being supported, propagated and displayed in vSphere. Here in my place we do have an architecture board which carefully observes all points concerning supportability, certification matrices and also functionality itself. So it is not me, deciding what is allowed to use for production. As long as open-vm-tools are not stated green in vSphere display and do obviously not have the same state with VMware support itself, I will have to use the professional VMwareTools coming with ESXi release. This is strict and I can not help it. So the point is, that VMware internal there is a problem with the handling of the two branches on VMwareTools. This should be resolved preventing an oncoming support ping-pong on the back of the end-user. 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: Bo Dang [mailto:bdang at vmware.com] Gesendet: Thursday, April 24, 2014 6:05 AM An: Joe Doupnik; Frey Urs, IT222; Kai Dupke; allen at ua.edu; mge at suse.com; kukuk at suse.de; uwedr at suse.com Cc: sles-beta at lists.suse.com; John Savanyo Betreff: Re: [sles-beta] Beta 5 and VMware-tools Hi Kai,Joe,urs, allen, mge, Thorsten, uwe and all, Thanks a lot for your comments and concerns for open-vm-tools. I am copying John who might have more info in this list. We are working closely with SUSE with related items. Such as, you might know that toolsd service from open-vm-tools in current build will not be started automatically and you need to execute "sudo systemctl enable vmtoolsd" and "sudo systemctl start vmtoolsd" to start its service manually. Legacy tools service doesn't work well in current build , you will be suggested to remove some packages for "open-vm-tools" first for its legacy tools installation. Such as packages "open-vm-tools","open-vm-desktop" and "libvmtools0" Don't hesitate to let us know for any related issues :) Thanks again for all your supports and suggestions! Best Regards, Bo Dang bdang at vmware.com Level 8 South Wing of Tower C Raycom InfoTech Park No. 2 Kexueyuan South Road Haidian District Beijing, 100190, People's Republic of China +86-10-5993-4242 Office +86-10-5993-4205 Fax From: "Joe Doupnik" > To: sles-beta at lists.suse.com Sent: Thursday, April 24, 2014 12:11:51 AM Subject: Re: [sles-beta] Beta 5 and VMware-tools Kai, Thanks for taking the time to write up this situation. The story appears to be better than I had thought. Joe D. On 23/04/2014 15:39, Kai Dupke wrote: VMware already made a statement on this list before, but I asked them to clarify again. The open-vm-tools are maintained by VMware but organized as an open source project. SLES 12 include the tools because VMware as partner asked us to include them, which is a good fit to our guest story. The today situation is an interim situation as with chicken-egg, because VMware can't drop the tools from the ESX product as SLES 11 for example does not contain the open-vm-tools at the moment. At the same time VMware can't just change the wording as the open-vm-tools are, open available for each to rebuild and grab, which could lead to false positive display. My understanding is that VMware will change the message to something like 'guest provided' in the display of the client, without any 3rd party or other confusion statement. We also work with VMware to get the support finalized in a way that these package will be tagged as fully supported. greetings kai On 04/23/2014 03:42 PM, Joe Doupnik wrote: The key word is "if". We don't know that. There are various versions of VMware hypervisor in use, little is known about how the open-vmware tools fit into that puzzle and what it does/does not support in the way of features. Let's look at this geometrically, for welcomed relief. There is VMware, there are SUSE virtual machines, and sandwiched between is a set of tools. There are two interfaces involved. At the moment VMware-tools matches the hypervisor version of choice. The third party open-vmware offering hopefully (that ambiguous word) works with both sides today (not necessarily true in the recent past), yet it is a third party to be coordinated with the other two by means still unknown. The SUSE part of things changed so that the VMware tools will not build with our v12 beta 5 material; again the reasons are unknown. How this situation will evolve during our beta is also unknown. Which of these approaches offers least risk and broad version coverage? Risk includes what the vendors involved will accept as a proper systems component when fingers are pointed. That's a description of what is concerning us about this situation. Joe D. On 23/04/2014 14:27, Beddingfield, Allen wrote: I'm having a hard time understanding why there is such concern here. VMware supporting the open-vm-tools is preferable to me. I can then use SUSE Manager to also manage my vm tools, instead of having to rely on VMware for such things. I actually have a script that currently does this, instead of using VMware's interface, but if the functionality is the same, installing/updating is easier, and VMware doesn't care/supports it, I don't see a problem. -- Allen Beddingfield Systems Engineer The University of Alabama ________________________________ From: sles-beta-bounces at lists.suse.com [sles-beta-bounces at lists.suse.com] on behalf of urs.frey at post.ch [urs.frey at post.ch] Sent: Wednesday, April 23, 2014 2:04 AM To: jrd at netlab1.net; sles-beta at lists.suse.com Subject: Re: [sles-beta] Beta 5 and VMware-tools Hi I fully agree with Joe I mean I use VMwareTools coming together with the specific ESXi release for good reasons for years now on different Linux distributions. Now with SLES12 beta I am kind of ?urged? to use open-vm-tools which obviously do not match the VMware environment I have here. Wouldn?t it be a solution to leave the final decision about which VMware Tools to use to the end user? So I may choose to install what comes with SLES or I can also use what gets delivered from ESXi. Therefore no automated installations anymore together with SLES12. We do not know what the plans on VMware are. For the moment, the statements of VMware about open-vm-tools do not really convince me. http://kb.vmware.com/kb/2073803 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: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Joe Doupnik Gesendet: Tuesday, April 22, 2014 8:24 PM An: sles-beta at lists.suse.com Betreff: Re: [sles-beta] Beta 5 and VMware-tools Keeping a perspective on this. There is now a gulf between SLES v12 beta 5 and the VMware tools (o/s kind other 64-bit) provided with ESXi v5. The VMware software stalls while making kmods. That's all observational evidence. What we don't know is what changed. I will presume that the SLES (including kernel) part has, for probably good reasons, and that sooner or later VMware will issue tools for the v12 level of SLES. But that is only my guessing. What remains unconvincing is saying VMware recommends the open-vmware tools. Lots of room to interpret what is said by whom and in what context. The evidence says VMware ships their own tools rather than the open-vmware ones. Folks with contractual details may well be concerned, but we give the betas a chance to develop further before jumping to firm conclusions. Joe D. On 22/04/2014 17:58, Joe Doupnik wrote: vCenter is a high priced separate management product. I do not have it. ESXi servers have their own set of VMware tools. We click on the vSphere client to request they be installed in a VM. They match the particular version of ESXi. They don't work with beta 5, which means there are two branches of tools and the vendor's branch has been made inoperable. The open-vmware-tools item has had a rather chequered history. I have no good reason to trust that item very far (at this time). Now the branches are really separated. Not a comfortable situation. Joe D. On 22/04/2014 17:49, Kai Dupke wrote: On 04/22/2014 02:42 PM, Joe Doupnik wrote: Returning to this particular VMware-tools item today. Two points. [...] The open-vm-tools on SLES are the tools VMware recommends for the use. With "3rd party" you refer to the display in the Virtual Center I assume. Bo Dang form VMware commented on this earlier: Thanks for this info and keep contacting us! As john metnioned in another thread "The intent of the message was to communicate that end users do not need to worry about installing/updating VMware tools centrally from vCenter. Instead users are expected to use OS package manager to maintain vmware tools or open-vm-tools. We published the following KB article to clarify that open-vm-tools are "supported" and there is a FAQ at the bottom about this message at http://kb.vmware.com/kb/2073803 " and we are planning to change message in the future to remove "3rd Party" and instead say something like "Guest Managed" to reduce user concerns. greetings Kai Dupke Senior Product Manager Server Product Line _______________________________________________ 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 _______________________________________________ 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 Kai Dupke Senior Product Manager Server Product Line _______________________________________________ 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 https://urldefense.proofpoint.com/v1/url?u=http://lists.suse.com/mailman/listinfo/sles-beta&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=UKSbxMIYAkSEPzTbqdSR3w%3D%3D%0A&m=Goy90RdVnDoah1DqAcU%2FY4wIeNaUOekKlMW5tzzxFbM%3D%0A&s=7b6d5b27e8ec4744ae0d5b34b6e6b428ea8ee75bda2b98e2402e59d6fe304c66 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.baensch at dfs.de Fri May 2 00:28:13 2014 From: michael.baensch at dfs.de (Michael Baensch) Date: Fri, 2 May 2014 06:28:13 +0000 Subject: [sles-beta] autoyast firewall Beta4 Message-ID: <77fec41464db4681b7de3a12fdb1cf78@LGNMSXB02.prod.bk.dfs> Hi, we have an autoyast.xml file containing firewall settings for the SuSEfirewall2. The settings (syntax) are taken from a sles11 autoyast file. After installing sles12 beta4 the firewall is disabled, also the file /etc/sysconfig/SuSEfirewall2 does not contain any settings from autoyast.xml any ssh 1556 5666 no true true It's a bug ? Thanks Michael 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 michael.baensch at dfs.de Fri May 2 00:30:20 2014 From: michael.baensch at dfs.de (Michael Baensch) Date: Fri, 2 May 2014 06:30:20 +0000 Subject: [sles-beta] autoyast bootloader on Beta4 Message-ID: Hi, we have a bug concerning autoyast.xml with lvm and bootloader. The stage one works fine but the system does not boot into stage two. "No Operating System found" We are using a generic mbr, a seperate /boot partition and LVM for all other partitons. We are using ext2 (due ext3 bug 3006) Investigation shows that the /boot partition (/dev/vda1) is not flagged active. If setting /dev/vda1 manually active booting stage two succeeds. It's a bug ? Extracts from autoyast-xml: ?xml version="1.0"?> true true false true 8 false .... true true false ext2 true false /boot label 131 1 false 200M true false system 142 2 max CT_DISK all /dev/system true true false ext2 true false root / acl device 131 false 3G true false ext2 .... Thanks Michael 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 jreidinger at suse.com Fri May 2 00:55:57 2014 From: jreidinger at suse.com (Josef Reidinger) Date: Fri, 2 May 2014 08:55:57 +0200 Subject: [sles-beta] autoyast firewall Beta4 In-Reply-To: <77fec41464db4681b7de3a12fdb1cf78@LGNMSXB02.prod.bk.dfs> References: <77fec41464db4681b7de3a12fdb1cf78@LGNMSXB02.prod.bk.dfs> Message-ID: <20140502085557.0c943e48@dhcp150.suse.cz> On Fri, 2 May 2014 06:28:13 +0000 "Michael Baensch" wrote: > Hi, > > we have an autoyast.xml file containing firewall settings for the > SuSEfirewall2. The settings (syntax) are taken from a sles11 autoyast > file. > > After installing sles12 beta4 the firewall is disabled, also the > file /etc/sysconfig/SuSEfirewall2 does not contain any settings from > autoyast.xml > > > any > ssh 1556 5666 > no > true > true > > > It's a bug ? > Yes, it looks like bug as there is almost no changes to firewall packages regarding autoyast support. So if you can report it and attach logs, we can look at it and investigate issue. Thanks Josef > Thanks > Michael > > 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 > _______________________________________________ > sles-beta mailing list > sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta From jreidinger at suse.com Fri May 2 00:58:05 2014 From: jreidinger at suse.com (Josef Reidinger) Date: Fri, 2 May 2014 08:58:05 +0200 Subject: [sles-beta] autoyast bootloader on Beta4 In-Reply-To: References: Message-ID: <20140502085805.76d017b9@dhcp150.suse.cz> On Fri, 2 May 2014 06:30:20 +0000 "Michael Baensch" wrote: > Hi, > > we have a bug concerning autoyast.xml with lvm and bootloader. > The stage one works fine but the system does not boot into stage two. > "No Operating System found" > We are using a generic mbr, a seperate /boot partition and LVM for > all other partitons. We are using ext2 (due ext3 bug 3006) > > Investigation shows that the /boot partition (/dev/vda1) is not > flagged active. If setting /dev/vda1 manually active booting stage > two succeeds. > > It's a bug ? Yes, this looks like bug as we do some changes in bootloader and some parts changed due to switch for grub2, but you have explicit flag, so it should activate boot partition. If you can report and it and attach logs, we can look why it is is not activated. Thanks Josef > > Extracts from autoyast-xml: > > ?xml version="1.0"?> > xmlns:config="http://www.suse.com/1.0/configns"> > > true > true > false > true > 8 > > > > config:type="boolean">false > .... > > > true > > > true > false > ext2 > true > false > /boot > label > > 131 > 1 > false > 200M > > > true > false > system > 142 > 2 > max > > > > CT_DISK > all > > > /dev/system > true > > > true > false > ext2 > > true > false > root > / > acl > device > 131 > false > 3G > > > true > false > ext2 > .... > > Thanks > Michael > > 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 > _______________________________________________ > sles-beta mailing list > sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta From michael.baensch at dfs.de Fri May 2 05:06:07 2014 From: michael.baensch at dfs.de (Michael Baensch) Date: Fri, 2 May 2014 11:06:07 +0000 Subject: [sles-beta] autoyast init-script on Beta4 Message-ID: <6077e4e0fe92493bae33f75f788d746b@LGNMSXB02.prod.bk.dfs> Hello again, We are using an init-script in the autoyast.xml script section. The init-script configures the system using puppet et al and runs for a long time (about 3-4 minutes). Before that script finishes the login promp (tty1 getty) appeares. We consider this a bug since the system is not ready configured and we do not want users to log in. Also the init-script shoud be finished before sshd is started if possible. Because the we can't see all bugs and so many mails, maybe this ist not new ? Regards Michael 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