From uwedr at suse.com Mon Mar 17 10:48:09 2014 From: uwedr at suse.com (Uwe Drechsel) Date: Mon, 17 Mar 2014 17:48:09 +0100 Subject: [sles-beta] Conference call next week - Beta 3 In-Reply-To: <20140317162756.GA6134@suse.de> References: <20140317162756.GA6134@suse.de> Message-ID: <20140317164809.GO6054@suse.de> On Mon, Mar 17, Uwe Drechsel wrote: > next week we are going to have our next conference call. This time we > are going to focus on Filesystems: > Sorry, topic is Network and systemd. Uwe Drechsel > Monday, March 24 > > 17:00 CET (no daylight saving time in Europe yet!) > 12:00 am EDT > 09:00 am PDT > 04:00 pm UTC/GMT > > Duration: 1 hour > > > The web presentation is done using Huddle (also for audio): > http://www.novell.com/huddle/event/index.php?event_id=6464b3ec1fdfacead70c3a9bd77d8243 > Password is: mysusebeta > > There is also a number of phone lines available, see attached file for > dial in information. > From allen at ua.edu Mon Mar 17 13:44:59 2014 From: allen at ua.edu (Beddingfield, Allen) Date: Mon, 17 Mar 2014 19:44:59 +0000 Subject: [sles-beta] First round of testing with SLES12 Beta2 Message-ID: Hi all, I have been away for about a week, so I'm just now getting into my heavy testing of SLE 12 Beta 2. I will admit that with the backlog of e-mail that I have, I have not had the time to read all the messages related to this group in detail. Please forgive if I point out issues that have already been uncovered or discussed. >From my initial round of testing an experimentation with SLES 12 Beta 2, here is what I've uncovered so far. Issue #1: Can't set default to runlevel 3/"multi-user": On the installation settings screen during installation, if I select "Default systemd target" and change it from "graphical" to "multi-user", the setting will not "stick". When I select "ok" and return back to the main screen, "graphical" is again selected. Once the OS is installed, going into Yast and to the "services manager" module yields the following as selections for "default system target" ctrl-alt-del, graphical interface, halt, kexec, poweroff, reboot, remote file systems, rescue mode, runlevel0, runlevel1, runlevel6 There is no "multiuser" or "runlevel3" Issue #2: Can't switch to another runlevel: "init 3", "telinit 3", and "systemctl isolate multi-user.target" all lock up the system. Issue #3: Something is not quite right with the DNS portion of the network configuration. If I configure it with two DNS servers (inside of yast), verify that those servers are accessible by the network, and verify that they are listed under "NETCONFIG_DNS_STATIC_SERVERS=" in "/etc/sysconfig/network/config", I'm not able to do "nslookup domain" and have it work. If I run nslookup and manually look up against those servers it works (so there is not question that the system can connect to the DNS server). I initially configured this in the tui version of yast. I went into the gui version, and I have noticed that I can't switch between the tabs (global options, overview, hostname/dns, routing). It just sort of greys out the whole screen when I try. I CAN switch between them in the tui version of yast, but no change that I seem to make helps. Deleting/re-adding the adapter did not help. I'm already starting the miss the old /etc/resolv.conf, etc... Issue #4 It is possible that this is related to #3 above: nscd is yielding this error upon restart, and in /var/log/messages: Mar 12 19:52:28 ualinux-test02 systemd[1]: Started Name Service Cache Daemon. Mar 12 19:52:28 ualinux-test02 nscd[544]: 544 cannot create /var/run/nscd/passwd; no persistent database used Mar 12 19:52:28 ualinux-test02 nscd[544]: 544 cannot create /var/run/nscd/group; no persistent database used Mar 12 19:52:28 ualinux-test02 nscd[544]: 544 cannot create /var/run/nscd/services; no persistent database used Mar 12 19:52:28 ualinux-test02 nscd[544]: 544 cannot create /var/run/nscd/netgroup; no persistent database used General question: At what point will network setup be added to the installation process? (Instead of having to change the hostname from "linux" and manually configure post-install?). Thanks. Allen B. -- Allen Beddingfield Systems Engineer The University of Alabama From fcrozat at suse.com Tue Mar 18 02:52:19 2014 From: fcrozat at suse.com (Frederic Crozat) Date: Tue, 18 Mar 2014 09:52:19 +0100 Subject: [sles-beta] First round of testing with SLES12 Beta2 In-Reply-To: References: Message-ID: <1395132739.28828.91.camel@par-r81vxc7.par.novell.com> Le lundi 17 mars 2014 ? 19:44 +0000, Beddingfield, Allen a ?crit : > Hi all, > I have been away for about a week, so I'm just now getting into my heavy testing of SLE 12 Beta 2. I will admit that with the backlog of e-mail that I have, I have not had the time to read all the messages related to this group in detail. Please forgive if I point out issues that have already been uncovered or discussed. > > From my initial round of testing an experimentation with SLES 12 Beta 2, here is what I've uncovered so far. > > Issue #1: Can't set default to runlevel 3/"multi-user": > On the installation settings screen during installation, if I select "Default systemd target" and change it from "graphical" to "multi-user", the setting will not "stick". When I select "ok" and return back to the main screen, "graphical" is again selected. > Once the OS is installed, going into Yast and to the "services manager" module yields the following as selections for "default system target" > ctrl-alt-del, graphical interface, halt, kexec, poweroff, reboot, remote file systems, rescue mode, runlevel0, runlevel1, runlevel6 > There is no "multiuser" or "runlevel3" This issue is fixed internally and will be fixed for you in beta3 > Issue #2: Can't switch to another runlevel: > "init 3", "telinit 3", and "systemctl isolate multi-user.target" all lock up the system. This issue is not fixed yet, but it was listed in the know issue from beta2 announcement ;) > Issue #3: Something is not quite right with the DNS portion of the network configuration. If I configure it with two DNS servers (inside of yast), verify that those servers are accessible by the network, and verify that they are listed under "NETCONFIG_DNS_STATIC_SERVERS=" in "/etc/sysconfig/network/config", I'm not able to do "nslookup domain" and have it work. If I run nslookup and manually look up against those servers it works (so there is not question that the system can connect to the DNS server). > I initially configured this in the tui version of yast. I went into the gui version, and I have noticed that I can't switch between the tabs (global options, overview, hostname/dns, routing). It just sort of greys out the whole screen when I try. I CAN switch between them in the tui version of yast, but no change that I seem to make helps. Deleting/re-adding the adapter did not help. I'm already starting the miss the old /etc/resolv.conf, etc... Tab switching is fixed internally and will be fixed for you in Beta3. once you configure the DNS withing yast, does running "netconfig update" (or "netconfig update -f") properly creates /etc/resolv.conf ? > Issue #4 It is possible that this is related to #3 above: nscd is yielding this error upon restart, and in /var/log/messages: > Mar 12 19:52:28 ualinux-test02 systemd[1]: Started Name Service Cache Daemon. > Mar 12 19:52:28 ualinux-test02 nscd[544]: 544 cannot create /var/run/nscd/passwd; no persistent database used > Mar 12 19:52:28 ualinux-test02 nscd[544]: 544 cannot create /var/run/nscd/group; no persistent database used > Mar 12 19:52:28 ualinux-test02 nscd[544]: 544 cannot create /var/run/nscd/services; no persistent database used > Mar 12 19:52:28 ualinux-test02 nscd[544]: 544 cannot create /var/run/nscd/netgroup; no persistent database used This bug was already reported on the mailing list and we have a bug report internally for it. Not yet fixed. > General question: At what point will network setup be added to the installation process? (Instead of having to change the hostname from "linux" and manually configure post-install?). I think network setup in the installer should be back in beta3 but I can't confirm it yet. -- Frederic Crozat SUSE From allen at ua.edu Tue Mar 18 07:54:07 2014 From: allen at ua.edu (Beddingfield, Allen) Date: Tue, 18 Mar 2014 13:54:07 +0000 Subject: [sles-beta] First round of testing with SLES12 Beta2 In-Reply-To: <1395132739.28828.91.camel@par-r81vxc7.par.novell.com> References: , <1395132739.28828.91.camel@par-r81vxc7.par.novell.com> Message-ID: No, that does not cause it to write a new resolv.conf. I'm going to load up a few more test systems and try to duplicate this. Here is the result from "netconfig update -f": ualinux-test02:~ # netconfig update -f -v debug: lockfile created (/var/run/netconfig.pid) for PID 6141 debug: lockfile created debug: Module order: dns-resolver dns-bind dns-dnsmasq nis ntp-runtime debug: dns-resolver module called debug: dns-bind Module called debug: dns-dnsmasq Module called debug: nis Module called debug: Keep Static debug: format_static[-1] called debug: Other: * debug: exec manage_interfaceconfig: /var/run/netconfig/ens32 debug: exec get_nis_settings: /var/run/netconfig/ens32/netconfig0 debug: exit get_nis_settings: /var/run/netconfig/ens32/netconfig0 debug: exit manage_interfaceconfig: /var/run/netconfig/ens32 debug: exec manage_interfaceconfig: /var/run/netconfig/lo debug: exec get_nis_settings: /var/run/netconfig/lo/netconfig1 debug: exit get_nis_settings: /var/run/netconfig/lo/netconfig1 debug: exec get_nis_settings: /var/run/netconfig/lo/netconfig0 debug: exit get_nis_settings: /var/run/netconfig/lo/netconfig0 debug: exit manage_interfaceconfig: /var/run/netconfig/lo debug: Installing new /etc/yp.conf debug: nis domainname '' is up to date debug: ntp-runtime Module called debug: Keep Static debug: Other: * debug: exec manage_interfaceconfig: /var/run/netconfig/ens32 debug: exec get_ntp_settings: /var/run/netconfig/ens32/netconfig0 debug: get_ntp_settings: NTP_SERVER_LIST='' debug: exit get_ntp_settings: /var/run/netconfig/ens32/netconfig0 debug: exit manage_interfaceconfig: /var/run/netconfig/ens32 debug: exec manage_interfaceconfig: /var/run/netconfig/lo debug: exec get_ntp_settings: /var/run/netconfig/lo/netconfig1 debug: get_ntp_settings: NTP_SERVER_LIST='' debug: exit get_ntp_settings: /var/run/netconfig/lo/netconfig1 debug: exec get_ntp_settings: /var/run/netconfig/lo/netconfig0 debug: get_ntp_settings: NTP_SERVER_LIST='' debug: exit get_ntp_settings: /var/run/netconfig/lo/netconfig0 debug: exit manage_interfaceconfig: /var/run/netconfig/lo ualinux-test02:~ # contents of /etc/resolv.conf ### /etc/resolv.conf file autogenerated by netconfig! # # Before you change this file manually, consider to define the # static DNS configuration using the following variables in the # /etc/sysconfig/network/config file: # NETCONFIG_DNS_STATIC_SEARCHLIST # NETCONFIG_DNS_STATIC_SERVERS # NETCONFIG_DNS_FORWARDER # or disable DNS configuration updates via netconfig by setting: # NETCONFIG_DNS_POLICY='' # # See also the netconfig(8) manual page and other documentation. # # Note: Manual change of this file disables netconfig too, but # may get lost when this file contains comments or empty lines # only, the netconfig settings are same with settings in this # file and in case of a "netconfig update -f" call. # ### Please remove (at least) this line when you modify the file! Relevant sections from /etc/sysconfig/network/config: ## Type: string ## Default: "" # # List of DNS domain names used for host-name lookup. # It is written as search list into the /etc/resolv.conf file. # NETCONFIG_DNS_STATIC_SEARCHLIST="oit.ua.edu ua.edu" ## Type: string ## Default: "" # # List of DNS nameserver IP addresses to use for host-name lookup. # When the NETCONFIG_DNS_FORWARDER variable is set to "resolver", # the name servers are written directly to /etc/resolv.conf. # Otherwise, the nameserver are written into a forwarder specific # configuration file and the /etc/resolv.conf does not contain any # nameservers causing the glibc to use the name server on the local # machine (the forwarder). See also netconfig(8) manual page. # NETCONFIG_DNS_STATIC_SERVERS="130.160.4.4 130.160.4.114" -- Allen Beddingfield Systems Engineer The University of Alabama > Issue #3: Something is not quite right with the DNS portion of the network configuration. If I configure it with two DNS servers (inside of yast), verify that those servers are accessible by the network, and verify that they are listed under "NETCONFIG_DNS_STATIC_SERVERS=" in "/etc/sysconfig/network/config", I'm not able to do "nslookup domain" and have it work. If I run nslookup and manually look up against those servers it works (so there is not question that the system can connect to the DNS server). > I initially configured this in the tui version of yast. I went into the gui version, and I have noticed that I can't switch between the tabs (global options, overview, hostname/dns, routing). It just sort of greys out the whole screen when I try. I CAN switch between them in the tui version of yast, but no change that I seem to make helps. Deleting/re-adding the adapter did not help. I'm already starting the miss the old /etc/resolv.conf, etc... Tab switching is fixed internally and will be fixed for you in Beta3. once you configure the DNS withing yast, does running "netconfig update" (or "netconfig update -f") properly creates /etc/resolv.conf ? -- Frederic Crozat SUSE _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta From allen at ua.edu Tue Mar 18 14:37:31 2014 From: allen at ua.edu (Beddingfield, Allen) Date: Tue, 18 Mar 2014 20:37:31 +0000 Subject: [sles-beta] after.local scripts works - before.local does not Message-ID: /etc/init.d/after.local works, but /etc/init.d/before.local does not seem to be processed on beta 2 Allen B. -- Allen Beddingfield Systems Engineer The University of Alabama From fcrozat at suse.com Wed Mar 19 02:29:01 2014 From: fcrozat at suse.com (Frederic Crozat) Date: Wed, 19 Mar 2014 09:29:01 +0100 Subject: [sles-beta] after.local scripts works - before.local does not In-Reply-To: References: Message-ID: <1395217741.22129.5.camel@par-r81vxc7.par.novell.com> Le mercredi 19 mars 2014 ? 08:33 +1100, Darren Thompson a ?crit : > @Beddingfield > > > Odd, what makes you so sure it's not running? > > > The reason I ask is I had to add "modprobe softdog" to my before.local > to get the cluster SBD working and it's certaily executing correctly > for me. to do such "modprobe", I suggest you use a drop-in file in /etc/modules-load.d (see man modules-load.d for a complete documentation). This will ensure modules are loaded very early in the system. -- Frederic Crozat SUSE From fcrozat at suse.com Wed Mar 19 02:30:54 2014 From: fcrozat at suse.com (Frederic Crozat) Date: Wed, 19 Mar 2014 09:30:54 +0100 Subject: [sles-beta] after.local scripts works - before.local does not In-Reply-To: References: , Message-ID: <1395217854.22129.7.camel@par-r81vxc7.par.novell.com> Le mardi 18 mars 2014 ? 21:37 +0000, Beddingfield, Allen a ?crit : > I just put in something simple to create a directory, touch a file, etc.. the same works fine on SLES 11 SP3, but not SLES 12 beta 2. I've got a couple of fresh beta 2 installs going now to test some networking issues, and I will verify that it is reproducible on them and report back... Currently, systemd doesn't support /etc/init.d/before.local, mostlyu because of to the extreme parallelisation of the boot. I'd suggest you use a systemd unit file to do this, this will be much more flexible, so you can ensure it is run exactly when you want it to be run. -- Frederic Crozat SUSE From mt at suse.de Tue Mar 18 13:16:17 2014 From: mt at suse.de (Marius Tomaschewski) Date: Tue, 18 Mar 2014 20:16:17 +0100 Subject: [sles-beta] First round of testing with SLES12 Beta2 In-Reply-To: References: , Message-ID: <53289B81.5040309@suse.de> Am 18.03.2014 14:54, schrieb Allen Beddingfield: > No, that does not cause it to write a new resolv.conf. [...] > debug: dns-resolver module called > debug: dns-bind Module called > debug: dns-dnsmasq Module called [...] > NETCONFIG_DNS_STATIC_SEARCHLIST="oit.ua.edu ua.edu" > NETCONFIG_DNS_STATIC_SERVERS="130.160.4.4 130.160.4.114" This looks like dns has been disabled by setting NETCONFIG_DNS_POLICY="". Can you call: bash -x /etc/netconfig.d/dns-resolver &> /tmp/netconfig-dns.out And provide the output to me? Gruesse / Regards, Marius Tomaschewski , -- SUSE LINUX Products GmbH, HRB 16746 (AG N?rnberg), GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, Maxfeldstra?e 5, 90409 N?rnberg, Germany From mt at suse.de Tue Mar 18 13:18:46 2014 From: mt at suse.de (Marius Tomaschewski) Date: Tue, 18 Mar 2014 20:18:46 +0100 Subject: [sles-beta] First round of testing with SLES12 Beta2 In-Reply-To: <53289B81.5040309@suse.de> References: , <53289B81.5040309@suse.de> Message-ID: <53289C16.9020806@suse.de> Am 18.03.2014 20:16, schrieb Marius Tomaschewski: > Am 18.03.2014 14:54, schrieb Allen Beddingfield: >> No, that does not cause it to write a new resolv.conf. > [...] > > debug: dns-resolver module called > > debug: dns-bind Module called > > debug: dns-dnsmasq Module called > [...] > > NETCONFIG_DNS_STATIC_SEARCHLIST="oit.ua.edu ua.edu" > > NETCONFIG_DNS_STATIC_SERVERS="130.160.4.4 130.160.4.114" > > This looks like dns has been disabled by setting NETCONFIG_DNS_POLICY="". > > Can you call: > > bash -x /etc/netconfig.d/dns-resolver &> /tmp/netconfig-dns.out > > And provide the output to me? ^^^^^^ I mean the /tmp/netconfig-dns.out file of course :-) Gruesse / Regards, Marius Tomaschewski , -- SUSE LINUX Products GmbH, HRB 16746 (AG N?rnberg), GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, Maxfeldstra?e 5, 90409 N?rnberg, Germany From fcrozat at suse.com Wed Mar 19 03:19:38 2014 From: fcrozat at suse.com (Frederic Crozat) Date: Wed, 19 Mar 2014 10:19:38 +0100 Subject: [sles-beta] after.local scripts works - before.local does not In-Reply-To: <1395217854.22129.7.camel@par-r81vxc7.par.novell.com> References: , <1395217854.22129.7.camel@par-r81vxc7.par.novell.com> Message-ID: <1395220778.22129.12.camel@par-r81vxc7.par.novell.com> Le mercredi 19 mars 2014 ? 09:30 +0100, Frederic Crozat a ?crit : > Le mardi 18 mars 2014 ? 21:37 +0000, Beddingfield, Allen a ?crit : > > I just put in something simple to create a directory, touch a file, etc.. the same works fine on SLES 11 SP3, but not SLES 12 beta 2. I've got a couple of fresh beta 2 installs going now to test some networking issues, and I will verify that it is reproducible on them and report back... > > Currently, systemd doesn't support /etc/init.d/before.local, mostlyu > because of to the extreme parallelisation of the boot. > > I'd suggest you use a systemd unit file to do this, this will be much > more flexible, so you can ensure it is run exactly when you want it to > be run. And I forgot to mention, for creating files and directories, the easier way is to rely on tmpfiles.d (see manpage tmpfiles.d for the syntax) with a drop-in file in /etc/tmpfiles.d/, you should be able to do basic file/directory creation / ownership changes / cleanup -- Frederic Crozat SUSE From allen at ua.edu Wed Mar 19 07:44:05 2014 From: allen at ua.edu (Beddingfield, Allen) Date: Wed, 19 Mar 2014 13:44:05 +0000 Subject: [sles-beta] after.local scripts works - before.local does not In-Reply-To: <1395217854.22129.7.camel@par-r81vxc7.par.novell.com> References: , , <1395217854.22129.7.camel@par-r81vxc7.par.novell.com> Message-ID: Will this be supported at some point? It just seems strange that a blank template for before.local exists, when it did not on previous versions, but is unsupported here :) I assume that after.local is expected to continue to function as before? I actually don't have anything in production using before.local, so that won't be a problem for us, although I do have after.local in use in some places. I'm sure there are people out there who will be inconvenienced by before.local not working, though. I was just testing it out as a matter of curiosity, and to see if it worked the same in the systemd-based 12.x as 11.x Thanks. Allen B. -- 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 Frederic Crozat [fcrozat at suse.com] Sent: Wednesday, March 19, 2014 3:30 AM To: sles-beta at lists.suse.com Subject: Re: [sles-beta] after.local scripts works - before.local does not Le mardi 18 mars 2014 ? 21:37 +0000, Beddingfield, Allen a ?crit : > I just put in something simple to create a directory, touch a file, etc.. the same works fine on SLES 11 SP3, but not SLES 12 beta 2. I've got a couple of fresh beta 2 installs going now to test some networking issues, and I will verify that it is reproducible on them and report back... Currently, systemd doesn't support /etc/init.d/before.local, mostlyu because of to the extreme parallelisation of the boot. I'd suggest you use a systemd unit file to do this, this will be much more flexible, so you can ensure it is run exactly when you want it to be run. -- Frederic Crozat SUSE _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta From allen at ua.edu Wed Mar 19 08:01:37 2014 From: allen at ua.edu (Beddingfield, Allen) Date: Wed, 19 Mar 2014 14:01:37 +0000 Subject: [sles-beta] First round of testing with SLES12 Beta2 In-Reply-To: <53289C16.9020806@suse.de> References: , <53289B81.5040309@suse.de>,<53289C16.9020806@suse.de> Message-ID: So, where is the "NETCONFIG_DNS_POLICY" being set? Is that the "modify dns configuration" option on the "hostname/dns" configuration tab in yast? It looks like the options there are "only manually", "use default policy", and "use custom policy". I have never had to modify that setting before. Modifying that settings seems to make no difference - in fact, it just changes back to "only manually" and does not save the change. Here is the output you asked for: ualinux-test02:~ # cat /tmp/netconfig-dns.out + unset POSIXLY_CORRECT + set +o posix + test 0 '!=' 0 -a root '!=' root -a -z '' + r= + . /etc/sysconfig/network/scripts/functions.netconfig ++ r= ++ NETCONFIG_DNS_RANKING_DEFAULT='+/vpn/ -/auto/ +strongswan +openswan +racoon -avahi' ++ test -z '' ++ MD5DIR=/var/adm/netconfig/md5 + PROGNAME=dns-resolver + STATEDIR=/var/run/netconfig + debug 'dns-resolver module called' + test '' = yes + return + . /etc/sysconfig/network/config ++ GLOBAL_POST_UP_EXEC=yes ++ GLOBAL_PRE_DOWN_EXEC=yes ++ CHECK_DUPLICATE_IP=no ++ SEND_GRATUITOUS_ARP=no ++ DEBUG=no ++ USE_SYSLOG=yes ++ CONNECTION_SHOW_WHEN_IFSTATUS=no ++ CONNECTION_CHECK_BEFORE_IFDOWN=no ++ CONNECTION_CLOSE_BEFORE_IFDOWN=no ++ CONNECTION_UMOUNT_NFS_BEFORE_IFDOWN=no ++ CONNECTION_SEND_KILL_SIGNAL=no ++ MANDATORY_DEVICES= ++ WAIT_FOR_INTERFACES=30 ++ FIREWALL=yes ++ NM_ONLINE_TIMEOUT=0 ++ NETCONFIG_MODULES_ORDER='dns-resolver dns-bind dns-dnsmasq nis ntp-runtime' ++ NETCONFIG_DNS_POLICY= ++ NETCONFIG_DNS_FORWARDER=resolver ++ NETCONFIG_DNS_FORWARDER_FALLBACK=yes ++ NETCONFIG_DNS_STATIC_SEARCHLIST='oit.ua.edu ua.edu' ++ NETCONFIG_DNS_STATIC_SERVERS='130.160.4.4 130.160.4.114' ++ NETCONFIG_DNS_RANKING=auto ++ NETCONFIG_DNS_RESOLVER_OPTIONS= ++ NETCONFIG_DNS_RESOLVER_SORTLIST= ++ NETCONFIG_NTP_POLICY=auto ++ NETCONFIG_NTP_STATIC_SERVERS= ++ NETCONFIG_NIS_POLICY=auto ++ NETCONFIG_NIS_SETDOMAINNAME=yes ++ NETCONFIG_NIS_STATIC_DOMAIN= ++ NETCONFIG_NIS_STATIC_SERVERS= ++ WIRELESS_REGULATORY_DOMAIN= + unset DNS_SEARCHLIST + unset DNS_SERVERS + DESTFILE=/etc/resolv.conf + TMP_FILE= + _NETCONFIG_DNS_RANKING=auto + case "$_NETCONFIG_DNS_RANKING" in + _NETCONFIG_DNS_RANKING='+/vpn/ -/auto/ +strongswan +openswan +racoon -avahi' ++ netconfig_policy '' ++ local policy= +++ systemctl --no-pager -p Id show network.service ++ local Id=Id=wicked.service ++ case ${Id#Id=} in ++ test x = xauto ++ echo '' + _NETCONFIG_DNS_POLICY= + '[' x = x ']' + exit 0 -- 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 Marius Tomaschewski [mt at suse.de] Sent: Tuesday, March 18, 2014 2:18 PM To: sles-beta at lists.suse.com Subject: Re: [sles-beta] First round of testing with SLES12 Beta2 Am 18.03.2014 20:16, schrieb Marius Tomaschewski: > Am 18.03.2014 14:54, schrieb Allen Beddingfield: >> No, that does not cause it to write a new resolv.conf. > [...] > > debug: dns-resolver module called > > debug: dns-bind Module called > > debug: dns-dnsmasq Module called > [...] > > NETCONFIG_DNS_STATIC_SEARCHLIST="oit.ua.edu ua.edu" > > NETCONFIG_DNS_STATIC_SERVERS="130.160.4.4 130.160.4.114" > > This looks like dns has been disabled by setting NETCONFIG_DNS_POLICY="". > > Can you call: > > bash -x /etc/netconfig.d/dns-resolver &> /tmp/netconfig-dns.out > > And provide the output to me? ^^^^^^ I mean the /tmp/netconfig-dns.out file of course :-) Gruesse / Regards, Marius Tomaschewski , -- SUSE LINUX Products GmbH, HRB 16746 (AG N?rnberg), GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, Maxfeldstra?e 5, 90409 N?rnberg, Germany _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta From fcrozat at suse.com Wed Mar 19 08:11:36 2014 From: fcrozat at suse.com (Frederic Crozat) Date: Wed, 19 Mar 2014 15:11:36 +0100 Subject: [sles-beta] after.local scripts works - before.local does not In-Reply-To: References: , ,<1395217854.22129.7.camel@par-r81vxc7.par.novell.com> Message-ID: <1395238296.12790.11.camel@par-r81vxc7.par.novell.com> Le mercredi 19 mars 2014 ? 13:44 +0000, Beddingfield, Allen a ?crit : > Will this be supported at some point? It just seems strange that a blank template for before.local exists, when it did not on previous versions, but is unsupported here :) Hmm, that's a bug, it shouldn't be there.. I'll open a bug report for this. > I assume that after.local is expected to continue to function as before? Yes, it is still supported, as well as /etc/init.d/halt.local. However, I'd suggest to move from after.local to systemd service, which are more fine grained and will allow you to be more precise in "when" you want your scripts to be run during the boot process. -- Frederic Crozat SUSE From mt at suse.de Wed Mar 19 08:59:28 2014 From: mt at suse.de (Marius Tomaschewski) Date: Wed, 19 Mar 2014 15:59:28 +0100 Subject: [sles-beta] First round of testing with SLES12 Beta2 In-Reply-To: References: , Message-ID: <5329B0D0.3030007@suse.de> Am 19.03.2014 15:01, schrieb Allen Beddingfield: > So, where is the "NETCONFIG_DNS_POLICY" being set? [...] > ++ NETCONFIG_DNS_POLICY= Seems YaST2 or something else trashes it. Start "yast2 lan", then: Network Settings ?Global Options??Overview??Hostname/DNS??Routing?????? ^^^^^^^^^^^^ Select "Use Default Policy" -- this should set it to "auto" again. Gruesse / Regards, Marius Tomaschewski , -- SUSE LINUX Products GmbH, HRB 16746 (AG N?rnberg), GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, Maxfeldstra?e 5, 90409 N?rnberg, Germany From mt at suse.de Wed Mar 19 09:00:58 2014 From: mt at suse.de (Marius Tomaschewski) Date: Wed, 19 Mar 2014 16:00:58 +0100 Subject: [sles-beta] First round of testing with SLES12 Beta2 In-Reply-To: <5329B0D0.3030007@suse.de> References: , <5329B0D0.3030007@suse.de> Message-ID: <5329B12A.1030303@suse.de> Am 19.03.2014 15:59, schrieb Marius Tomaschewski: > Am 19.03.2014 15:01, schrieb Allen Beddingfield: >> So, where is the "NETCONFIG_DNS_POLICY" being set? > [...] > > ++ NETCONFIG_DNS_POLICY= > > Seems YaST2 or something else trashes it. > > Start "yast2 lan", then: > > Network Settings > ?Global Options??Overview??Hostname/DNS??Routing?????? > ^^^^^^^^^^^^ > > Select "Use Default Policy" -- this should set it to "auto" again. Under "Modify DNS configuration" ... Gruesse / Regards, Marius Tomaschewski , -- SUSE LINUX Products GmbH, HRB 16746 (AG N?rnberg), GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, Maxfeldstra?e 5, 90409 N?rnberg, Germany From mt at suse.de Wed Mar 19 09:08:00 2014 From: mt at suse.de (Marius Tomaschewski) Date: Wed, 19 Mar 2014 16:08:00 +0100 Subject: [sles-beta] First round of testing with SLES12 Beta2 In-Reply-To: <5329B12A.1030303@suse.de> References: , <5329B12A.1030303@suse.de> Message-ID: <5329B2D0.4010804@suse.de> Am 19.03.2014 16:00, schrieb Marius Tomaschewski: > Am 19.03.2014 15:59, schrieb Marius Tomaschewski: >> Am 19.03.2014 15:01, schrieb Allen Beddingfield: >>> So, where is the "NETCONFIG_DNS_POLICY" being set? >> [...] >> > ++ NETCONFIG_DNS_POLICY= >> >> Seems YaST2 or something else trashes it. >> >> Start "yast2 lan", then: >> >> Network Settings >> ?Global Options??Overview??Hostname/DNS??Routing?????? >> ^^^^^^^^^^^^ >> >> Select "Use Default Policy" -- this should set it to "auto" again. > > Under "Modify DNS configuration" ... yast2-network-3.1.32 and 3.1.35 sets it to "" :-( Gruesse / Regards, Marius Tomaschewski , -- SUSE LINUX Products GmbH, HRB 16746 (AG N?rnberg), GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, Maxfeldstra?e 5, 90409 N?rnberg, Germany From allen at ua.edu Wed Mar 19 09:08:37 2014 From: allen at ua.edu (Beddingfield, Allen) Date: Wed, 19 Mar 2014 15:08:37 +0000 Subject: [sles-beta] First round of testing with SLES12 Beta2 In-Reply-To: <5329B0D0.3030007@suse.de> References: , , <5329B0D0.3030007@suse.de> Message-ID: The setting still does not persist. If i open "yast2 lan" and change it or navigate through the yast menu to get to the network settings, it still goes back to "only manually" It instantly exits, so it is like it is not even attempting to write any change. -- 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 Marius Tomaschewski [mt at suse.de] Sent: Wednesday, March 19, 2014 9:59 AM To: sles-beta at lists.suse.com Cc: mfilka at suse.de Subject: Re: [sles-beta] First round of testing with SLES12 Beta2 Am 19.03.2014 15:01, schrieb Allen Beddingfield: > So, where is the "NETCONFIG_DNS_POLICY" being set? [...] > ++ NETCONFIG_DNS_POLICY= Seems YaST2 or something else trashes it. Start "yast2 lan", then: Network Settings ?Global Options??Overview??Hostname/DNS??Routing?????? ^^^^^^^^^^^^ Select "Use Default Policy" -- this should set it to "auto" again. Gruesse / Regards, Marius Tomaschewski , -- SUSE LINUX Products GmbH, HRB 16746 (AG N?rnberg), GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, Maxfeldstra?e 5, 90409 N?rnberg, Germany _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta From allen at ua.edu Wed Mar 19 09:11:00 2014 From: allen at ua.edu (Beddingfield, Allen) Date: Wed, 19 Mar 2014 15:11:00 +0000 Subject: [sles-beta] First round of testing with SLES12 Beta2 In-Reply-To: <5329B2D0.4010804@suse.de> References: , <5329B12A.1030303@suse.de>,<5329B2D0.4010804@suse.de> Message-ID: This is the version on my test system: yast2-network-3.1.31-1.6.x86_64 -- Allen Beddingfield Systems Engineer The University of Alabama yast2-network-3.1.32 and 3.1.35 sets it to "" :-( Gruesse / Regards, Marius Tomaschewski , -- SUSE LINUX Products GmbH, HRB 16746 (AG N?rnberg), GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, Maxfeldstra?e 5, 90409 N?rnberg, Germany _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta From mt at suse.de Wed Mar 19 09:14:01 2014 From: mt at suse.de (Marius Tomaschewski) Date: Wed, 19 Mar 2014 16:14:01 +0100 Subject: [sles-beta] First round of testing with SLES12 Beta2 In-Reply-To: References: , Message-ID: <5329B439.2040500@suse.de> Am 19.03.2014 16:08, schrieb Allen Beddingfield: > The setting still does not persist. If i open "yast2 lan" and change it or navigate through the yast menu to get to the network settings, it still goes back to "only manually" > It instantly exits, so it is like it is not even attempting to write any change. It basically "crashes" there: 2014-03-19 16:01:10 <1> trinity(585) [Ruby] services/dns.rb:373 hn_settings[ "PLAIN_POLICY"] changes 'auto' -> 'auto' 2014-03-19 16:01:10 <2> trinity(585) [Ruby] (eval):2 Cannot convert FalseClass from 'any' to 'string' 2014-03-19 16:01:10 <2> trinity(585) [Ruby] (eval):2 ------------- Backtrace begin ------------- Gruesse / Regards, Marius Tomaschewski , -- SUSE LINUX Products GmbH, HRB 16746 (AG N?rnberg), GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, Maxfeldstra?e 5, 90409 N?rnberg, Germany From mt at suse.de Wed Mar 19 09:55:56 2014 From: mt at suse.de (Marius Tomaschewski) Date: Wed, 19 Mar 2014 16:55:56 +0100 Subject: [sles-beta] First round of testing with SLES12 Beta2 In-Reply-To: References: , Message-ID: <5329BE0C.50109@suse.de> Am 19.03.2014 16:11, schrieb Allen Beddingfield: > This is the version on my test system: > yast2-network-3.1.31-1.6.x86_64 I've opened a new bug report for this: Bug 869199 - yast2-network-3.1.31 ... 3.1.35 disable resolv.conf updates YaST2 network maintainers were able to reproduce it too. Workaround: sed -e 's/^\(NETCONFIG_DNS_POLICY=\).*/\1"auto"/g' \ -i /etc/sysconfig/network/config Gruesse / Regards, Marius Tomaschewski , -- SUSE LINUX Products GmbH, HRB 16746 (AG N?rnberg), GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, Maxfeldstra?e 5, 90409 N?rnberg, Germany From allen at ua.edu Wed Mar 19 10:05:30 2014 From: allen at ua.edu (Beddingfield, Allen) Date: Wed, 19 Mar 2014 16:05:30 +0000 Subject: [sles-beta] First round of testing with SLES12 Beta2 In-Reply-To: <5329BE0C.50109@suse.de> References: , , <5329BE0C.50109@suse.de> Message-ID: Thanks!. I can readily reproduce this problem every time. In fact, I'm wondering how anyone has managed to configure this and get it working on beta 2, without hand editting files? Here are the steps that I follow immediately after install, and the results: Steps to set IP address/do network config "yast lan" edit controller select "statically assigned ip address" enter correct IP address/subnet mask/hostname select next select "hostname/dns" tab Enter correct info for: hostname/domain name/name servers/domain search (At this point, "modify dns configuration" is set to "use default policy" switch to "routing" tab Enter correct IPV4 route reboot At this point, there are no DNS servers in resolv.conf, the policy is set back to "only manually", and the policy can't be changed. I'm curious if there is any set of steps that one can follow to not have this situation occur, and why others have not encountered/reported it? It seems that everyone doing an installation of beta 2 would have encountered this. -- 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 Marius Tomaschewski [mt at suse.de] Sent: Wednesday, March 19, 2014 10:55 AM To: sles-beta at lists.suse.com Subject: Re: [sles-beta] First round of testing with SLES12 Beta2 Am 19.03.2014 16:11, schrieb Allen Beddingfield: > This is the version on my test system: > yast2-network-3.1.31-1.6.x86_64 I've opened a new bug report for this: Bug 869199 - yast2-network-3.1.31 ... 3.1.35 disable resolv.conf updates YaST2 network maintainers were able to reproduce it too. Workaround: sed -e 's/^\(NETCONFIG_DNS_POLICY=\).*/\1"auto"/g' \ -i /etc/sysconfig/network/config Gruesse / Regards, Marius Tomaschewski , -- SUSE LINUX Products GmbH, HRB 16746 (AG N?rnberg), GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, Maxfeldstra?e 5, 90409 N?rnberg, Germany _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta From jrd at netlab1.net Wed Mar 19 11:37:31 2014 From: jrd at netlab1.net (Joe Doupnik) Date: Wed, 19 Mar 2014 17:37:31 +0000 Subject: [sles-beta] Changing lan adapter names, get stuck rebooting Message-ID: <5329D5DB.9090208@netlab1.net> Likely probably many other people, I have no use for the current opaquely generated lan adapter names. There is no obvious tie to the hardware such as MAC address, in a readily visible fashion. Thus I used YaST (text mode) to modify the name to eth0. Yes, it can be done. The result was a conventional (at last) 70-persistent-net.rules item in /etc/udev/rules.d. My IPtables filter thanked me for that. However, there is a dark side. Restarting the machine from power off causes the boot process to get stuck in a wait loop for wicked, saying "A start job is running for wicked managed network". Seven and a half minutes later... the system went beyond that point and finished booting. There is no wireless or similar arrangement here. No Network Manager. Just one Ethernet adapter in this ESXi virtual machine. Problem two is to re-ask a question. Where are the systemd lan adapter names defined? Those ems32 style things. I have not been able to locate them. If found then perhaps reason could be brought to bear to return to usable eth0 etc. Having ifcfg-eth0 with real values would be a definite plus. The points at hand are clarity, easily located configurations, flexibility in operations, but so far in my learning process the systemd approach lacks each of these. Thanks, Joe D. From brown.chris at sap.com Wed Mar 19 11:45:26 2014 From: brown.chris at sap.com (Chris, Brown) Date: Wed, 19 Mar 2014 17:45:26 +0000 Subject: [sles-beta] Changing lan adapter names, get stuck rebooting In-Reply-To: <5329D5DB.9090208@netlab1.net> References: <5329D5DB.9090208@netlab1.net> Message-ID: <1395251010.16570.36.camel@localhost> I had THOUGHT that you could pass "biosdevname=0" at the boot prompt to get the "old style" names back, but apparently this doesn't work anymore. to the SuSE Developers, any ideas why this "workaround" was removed? On a side note I don't understand why the kernel devs felt the need to change something like this, but I know that's a discussion over many many many bottles of beer. -Chris -----Original Message----- From: Joe Doupnik > To: sles-beta at lists.suse.com > Subject: [sles-beta] Changing lan adapter names, get stuck rebooting Date: Wed, 19 Mar 2014 17:37:31 +0000 Likely probably many other people, I have no use for the current opaquely generated lan adapter names. There is no obvious tie to the hardware such as MAC address, in a readily visible fashion. Thus I used YaST (text mode) to modify the name to eth0. Yes, it can be done. The result was a conventional (at last) 70-persistent-net.rules item in /etc/udev/rules.d. My IPtables filter thanked me for that. However, there is a dark side. Restarting the machine from power off causes the boot process to get stuck in a wait loop for wicked, saying "A start job is running for wicked managed network". Seven and a half minutes later... the system went beyond that point and finished booting. There is no wireless or similar arrangement here. No Network Manager. Just one Ethernet adapter in this ESXi virtual machine. Problem two is to re-ask a question. Where are the systemd lan adapter names defined? Those ems32 style things. I have not been able to locate them. If found then perhaps reason could be brought to bear to return to usable eth0 etc. Having ifcfg-eth0 with real values would be a definite plus. The points at hand are clarity, easily located configurations, flexibility in operations, but so far in my learning process the systemd approach lacks each of these. Thanks, Joe D. _______________________________________________ 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: From fcrozat at suse.com Wed Mar 19 11:46:21 2014 From: fcrozat at suse.com (Frederic Crozat) Date: Wed, 19 Mar 2014 18:46:21 +0100 Subject: [sles-beta] Changing lan adapter names, get stuck rebooting In-Reply-To: <5329D5DB.9090208@netlab1.net> References: <5329D5DB.9090208@netlab1.net> Message-ID: <1395251181.12790.31.camel@par-r81vxc7.par.novell.com> Le mercredi 19 mars 2014 ? 17:37 +0000, Joe Doupnik a ?crit : > Likely probably many other people, I have no use for the current > opaquely generated lan adapter names. There is no obvious tie to the > hardware such as MAC address, in a readily visible fashion. Thus I used > YaST (text mode) to modify the name to eth0. Yes, it can be done. The > result was a conventional (at last) 70-persistent-net.rules item in > /etc/udev/rules.d. My IPtables filter thanked me for that. > However, there is a dark side. Restarting the machine from power > off causes the boot process to get stuck in a wait loop for wicked, > saying "A start job is running for wicked managed network". > Seven and a half minutes later... the system went beyond that point > and finished booting. > There is no wireless or similar arrangement here. No Network > Manager. Just one Ethernet adapter in this ESXi virtual machine. > > Problem two is to re-ask a question. Where are the systemd lan > adapter names defined? Those ems32 style things. I have not been able to > locate them. If found then perhaps reason could be brought to bear to > return to usable eth0 etc. Having ifcfg-eth0 with real values would be a > definite plus. The points at hand are clarity, easily located > configurations, flexibility in operations, but so far in my learning > process the systemd approach lacks each of these. Network renaming (allowing you to have eth0 instead of en0s3..) was broken in Beta2, this might explains why you were stuked. This will be fixed in Beta3 and for Beta4, we will probably ship a script to ease the creation of 70-persistent-net.rules based on MAC address or bus address of the adapter. For the documentation on the network precitable names, you can have a look at http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ as a initial step. -- Frederic Crozat SUSE From mbrookhuis at suse.com Wed Mar 19 11:59:42 2014 From: mbrookhuis at suse.com (Michael Brookhuis) Date: Wed, 19 Mar 2014 17:59:42 +0000 Subject: [sles-beta] Autoyast Message-ID: <5329E91E020000A8000A7362@nat28.tlf.novell.com> Hi, Should autoyast already work with Beta2? And booting the install CD with a IP address, Gateway, DNS should that work? Thanks Michael From allen at ua.edu Wed Mar 19 12:07:37 2014 From: allen at ua.edu (Beddingfield, Allen) Date: Wed, 19 Mar 2014 18:07:37 +0000 Subject: [sles-beta] Changing lan adapter names, get stuck rebooting In-Reply-To: <1395251181.12790.31.camel@par-r81vxc7.par.novell.com> References: <5329D5DB.9090208@netlab1.net>, <1395251181.12790.31.camel@par-r81vxc7.par.novell.com> Message-ID: So, to clarify - with the next beta, the expectation is that we should be able to go in and rename our interfaces in yast, without additional mucking around with the config files? That would be great. The new scheme is horrible... in my testing, loading multiple VMs (identical virtual hardware - the MAC address should be all that is different), I get different interface names on different machines. With the 70-persistent-net.rules, I don't see what was so broken with the eth* scheme. One could always match a name to a MAC address. -- 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 Frederic Crozat [fcrozat at suse.com] Sent: Wednesday, March 19, 2014 12:46 PM To: sles-beta at lists.suse.com Subject: Re: [sles-beta] Changing lan adapter names, get stuck rebooting Le mercredi 19 mars 2014 ? 17:37 +0000, Joe Doupnik a ?crit : > Likely probably many other people, I have no use for the current > opaquely generated lan adapter names. There is no obvious tie to the > hardware such as MAC address, in a readily visible fashion. Thus I used > YaST (text mode) to modify the name to eth0. Yes, it can be done. The > result was a conventional (at last) 70-persistent-net.rules item in > /etc/udev/rules.d. My IPtables filter thanked me for that. > However, there is a dark side. Restarting the machine from power > off causes the boot process to get stuck in a wait loop for wicked, > saying "A start job is running for wicked managed network". > Seven and a half minutes later... the system went beyond that point > and finished booting. > There is no wireless or similar arrangement here. No Network > Manager. Just one Ethernet adapter in this ESXi virtual machine. > > Problem two is to re-ask a question. Where are the systemd lan > adapter names defined? Those ems32 style things. I have not been able to > locate them. If found then perhaps reason could be brought to bear to > return to usable eth0 etc. Having ifcfg-eth0 with real values would be a > definite plus. The points at hand are clarity, easily located > configurations, flexibility in operations, but so far in my learning > process the systemd approach lacks each of these. Network renaming (allowing you to have eth0 instead of en0s3..) was broken in Beta2, this might explains why you were stuked. This will be fixed in Beta3 and for Beta4, we will probably ship a script to ease the creation of 70-persistent-net.rules based on MAC address or bus address of the adapter. For the documentation on the network precitable names, you can have a look at http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ as a initial step. -- Frederic Crozat SUSE _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta From jrd at netlab1.net Wed Mar 19 12:49:09 2014 From: jrd at netlab1.net (Joe Doupnik) Date: Wed, 19 Mar 2014 18:49:09 +0000 Subject: [sles-beta] Changing lan adapter names, get stuck rebooting In-Reply-To: <1395251181.12790.31.camel@par-r81vxc7.par.novell.com> References: <5329D5DB.9090208@netlab1.net> <1395251181.12790.31.camel@par-r81vxc7.par.novell.com> Message-ID: <5329E6A5.80908@netlab1.net> Fredric, Good, let's see how matters develop in beta 3. Btw, I have read that citation you mentioned, and even repeated a clipping on this list as evidence of how wacko the new scheme has become. I cut through the excessive and defensive verbage of the systemd docs to get a solution done here, using YaST. Thus kudos once again to the YAST developers; none to the s-d folks. Throughout the systemd learning experience my goal has been to seek the clear and quickly used methods. The situation often is a server is ill, it must be fixed right now, services need to be restarted or revised by hand right now, and we need the big picture fully in mind to do this effectively, again right now. Similarly, building a server ought not be a half day or more exercise (without autoyast). There may be new ways of expressing things, but if we have to seriously fight the system to survive (which is the case at present) one suspects those systems will be replaced by more compliant ones, simply as a matter of site survival. Thus assistance from SUSE on decoding and domesticating what seems to be a real muddle in important places would be most appreciated. In its way this rough beginning has its benefits because we identify and clarify the nasty spots early enough for them to be smoothed out. Thanks and we do look forward to beta 3. Joe D. On 19/03/2014 17:46, Frederic Crozat wrote: > Le mercredi 19 mars 2014 ? 17:37 +0000, Joe Doupnik a ?crit : >> Likely probably many other people, I have no use for the current >> opaquely generated lan adapter names. There is no obvious tie to the >> hardware such as MAC address, in a readily visible fashion. Thus I used >> YaST (text mode) to modify the name to eth0. Yes, it can be done. The >> result was a conventional (at last) 70-persistent-net.rules item in >> /etc/udev/rules.d. My IPtables filter thanked me for that. >> However, there is a dark side. Restarting the machine from power >> off causes the boot process to get stuck in a wait loop for wicked, >> saying "A start job is running for wicked managed network". >> Seven and a half minutes later... the system went beyond that point >> and finished booting. >> There is no wireless or similar arrangement here. No Network >> Manager. Just one Ethernet adapter in this ESXi virtual machine. >> >> Problem two is to re-ask a question. Where are the systemd lan >> adapter names defined? Those ems32 style things. I have not been able to >> locate them. If found then perhaps reason could be brought to bear to >> return to usable eth0 etc. Having ifcfg-eth0 with real values would be a >> definite plus. The points at hand are clarity, easily located >> configurations, flexibility in operations, but so far in my learning >> process the systemd approach lacks each of these. > Network renaming (allowing you to have eth0 instead of en0s3..) was > broken in Beta2, this might explains why you were stuked. > > This will be fixed in Beta3 and for Beta4, we will probably ship a > script to ease the creation of 70-persistent-net.rules based on MAC > address or bus address of the adapter. > > For the documentation on the network precitable names, you can have a > look at > http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ as a initial step. > From Joel.Barbieri at merge.com Wed Mar 19 13:01:25 2014 From: Joel.Barbieri at merge.com (Joel Barbieri) Date: Wed, 19 Mar 2014 19:01:25 +0000 Subject: [sles-beta] Changing lan adapter names, get stuck rebooting In-Reply-To: References: <5329D5DB.9090208@netlab1.net>, <1395251181.12790.31.camel@par-r81vxc7.par.novell.com> Message-ID: <1E287A5DDB506E478DE9CAE3C8492D015A8ADAFE@BRDC-MBX-1.network.internal> Some history on NIC naming and why the [mostly random and irritating] new interface names were originally created, or so my failing memory says from kernel posts... People were unhappy with various network side effects... Assume a physical box with 4 onboard NICS labeled on the back as: 1 2 3 4 The kernel might give you eth numbers... 0 1 2 3 [yay! we like this] or [on some Dell systems] 3 2 1 0 [this made people unhappy] or, weirder yet 0 2 3 1 [that's just mean; SLES10 era, NOT consistent either; some builds were clean, and some were not] So the kernel developers switched [AFAIK] to "BIOS names," which gave us... em1 em2 em3 em4 [meh, I miss my eth; time to code] All of the above properly filled the udev persistent net [name changed a little between 10/11] file and stuck you whatever they came up with. Since we MFG product on each SLES version, we had to write something to work through whichever silliness... ## pseudocode; my keyboard and MS Outbreak do bad things to my typing ## my PIPE and BACKSLASH have gone AWOL; time to open the laptop and reset the KB connector # parse for NIC drivers and store in var; good to process into a sorted, uniq list a la sort -u DRV=$(hwinfo --netcard PIPE awk -vIGNORECASE=1 '/driver activation cmd/{gsub("BACKSLASH"","",$NF);print $NF}' PIPE sort -u) # shutdown network rcnetwork stop # clear any real entries from udev persistent net rules file grep -v UDEVPERSISTNETFILE > UDEVPERSISTNETFILE.$$;mv -f UDEVPERSISTNETFILE.$$ UDEVPERSISTNETFILE # loop through $var and remove all drivers for aa in $DRV do modprobe -r ${aa} done # re-add the things in some standardized order; e.g. sort -u list; and udev should re-populate for aa in $DRV do modprobe ${aa}; sleep 1 done # udev persistent net rules should be populated rcnetwork start # and consider stuffing our values into "MODULES_LOADED_ON_BOOT" in /etc/sysconfig/kernel; though that should be overkill if udev and the persistent net rules are working as advertised # and consider whether or not you want "MANDATORY INTERFACES", what you want them to be, or to just have them cleared. Of course, I do not yet know how SLES12 handles this as I have been stuck on other projects at work, but I thought I would share how I overcame this. -Joel -----Original Message----- From: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] On Behalf Of Beddingfield, Allen Sent: Wednesday, March 19, 2014 1:08 PM To: sles-beta at lists.suse.com Subject: Re: [sles-beta] Changing lan adapter names, get stuck rebooting So, to clarify - with the next beta, the expectation is that we should be able to go in and rename our interfaces in yast, without additional mucking around with the config files? That would be great. The new scheme is horrible... in my testing, loading multiple VMs (identical virtual hardware - the MAC address should be all that is different), I get different interface names on different machines. With the 70-persistent-net.rules, I don't see what was so broken with the eth* scheme. One could always match a name to a MAC address. -- 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 Frederic Crozat [fcrozat at suse.com] Sent: Wednesday, March 19, 2014 12:46 PM To: sles-beta at lists.suse.com Subject: Re: [sles-beta] Changing lan adapter names, get stuck rebooting Le mercredi 19 mars 2014 ? 17:37 +0000, Joe Doupnik a ?crit : > Likely probably many other people, I have no use for the current > opaquely generated lan adapter names. There is no obvious tie to the > hardware such as MAC address, in a readily visible fashion. Thus I used > YaST (text mode) to modify the name to eth0. Yes, it can be done. The > result was a conventional (at last) 70-persistent-net.rules item in > /etc/udev/rules.d. My IPtables filter thanked me for that. > However, there is a dark side. Restarting the machine from power > off causes the boot process to get stuck in a wait loop for wicked, > saying "A start job is running for wicked managed network". > Seven and a half minutes later... the system went beyond that point > and finished booting. > There is no wireless or similar arrangement here. No Network > Manager. Just one Ethernet adapter in this ESXi virtual machine. > > Problem two is to re-ask a question. Where are the systemd lan > adapter names defined? Those ems32 style things. I have not been able to > locate them. If found then perhaps reason could be brought to bear to > return to usable eth0 etc. Having ifcfg-eth0 with real values would be a > definite plus. The points at hand are clarity, easily located > configurations, flexibility in operations, but so far in my learning > process the systemd approach lacks each of these. Network renaming (allowing you to have eth0 instead of en0s3..) was broken in Beta2, this might explains why you were stuked. This will be fixed in Beta3 and for Beta4, we will probably ship a script to ease the creation of 70-persistent-net.rules based on MAC address or bus address of the adapter. For the documentation on the network precitable names, you can have a look at http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ as a initial step. -- Frederic Crozat SUSE _______________________________________________ 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 mpost at suse.com Wed Mar 19 15:56:41 2014 From: mpost at suse.com (Mark Post) Date: Wed, 19 Mar 2014 15:56:41 -0600 Subject: [sles-beta] Changing lan adapter names, get stuck rebooting In-Reply-To: <1395251010.16570.36.camel@localhost> References: <5329D5DB.9090208@netlab1.net> <1395251010.16570.36.camel@localhost> Message-ID: <5329DA590200006D00158E0A@prv-mh.provo.novell.com> >>> On 3/19/2014 at 01:45 PM, "Chris, Brown" wrote: > On a side note I don't understand why the kernel devs felt the need to change > something like this, but I know that's a discussion over many many many > bottles of beer. Don't blame this on the kernel developers. They had nothing to do with it, other than to tell the udev developers that whatever device naming breakage they had introduced previously was up to them to also fix. I don't think Linus put it that politely, however. :) Mark Post From mt at suse.de Wed Mar 19 19:03:03 2014 From: mt at suse.de (Marius Tomaschewski) Date: Thu, 20 Mar 2014 02:03:03 +0100 Subject: [sles-beta] Changing lan adapter names, get stuck rebooting In-Reply-To: References: <5329D5DB.9090208@netlab1.net>, Message-ID: <532A3E47.9010701@suse.de> Am 19.03.2014 19:07, schrieb Allen Beddingfield: > So, to clarify - with the next beta, the expectation is that we should be able > to go in and rename our interfaces in yast, without additional mucking around > with the config files? That would be great. When you want to rename, use an udev rule and just rename all nics to something like nic0, nic1, nic2... or lanX, dmzX. Important is basically to not use the "eth" scheme as exactly this is causing problems: the kernel is assigning to them in random (detection) order. You find eth0 which has to be to eth1, but before you've renamed kernel detects eth1 which has to be eth0 [more interfaces, more fun]. When the interface is up already, the rename fails, ... IMO the systemd scheme is better than biosdevname, but not much. Gruesse / Regards, Marius Tomaschewski , -- SUSE LINUX Products GmbH, HRB 16746 (AG N?rnberg), GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, Maxfeldstra?e 5, 90409 N?rnberg, Germany From mbrookhuis at suse.com Thu Mar 20 02:36:02 2014 From: mbrookhuis at suse.com (Michael Brookhuis) Date: Thu, 20 Mar 2014 08:36:02 +0000 Subject: [sles-beta] Changing lan adapter names, get stuck rebooting In-Reply-To: <1395251181.12790.31.camel@par-r81vxc7.par.novell.com> References: <5329D5DB.9090208@netlab1.net> <1395251181.12790.31.camel@par-r81vxc7.par.novell.com> Message-ID: <532AB682020000A8000A742F@nat28.tlf.novell.com> Hi Frederic, Will it also be possible to set ETH0 via autoyast? Most customer install server using autoyast and define their there network. Michael >>> On Wed, Mar 19, 2014 at 18:46, Frederic Crozat wrote: > Le mercredi 19 mars 2014 ? 17:37 +0000, Joe Doupnik a ?crit : > > Likely probably many other people, I have no use for the current > > opaquely generated lan adapter names. There is no obvious tie to the > > hardware such as MAC address, in a readily visible fashion. Thus I used > > YaST (text mode) to modify the name to eth0. Yes, it can be done. The > > result was a conventional (at last) 70-persistent-net.rules item in > > /etc/udev/rules.d. My IPtables filter thanked me for that. > > However, there is a dark side. Restarting the machine from power > > off causes the boot process to get stuck in a wait loop for wicked, > > saying "A start job is running for wicked managed network". > > Seven and a half minutes later... the system went beyond that point > > and finished booting. > > There is no wireless or similar arrangement here. No Network > > Manager. Just one Ethernet adapter in this ESXi virtual machine. > > > > Problem two is to re-ask a question. Where are the systemd lan > > adapter names defined? Those ems32 style things. I have not been able to > > locate them. If found then perhaps reason could be brought to bear to > > return to usable eth0 etc. Having ifcfg-eth0 with real values would be a > > definite plus. The points at hand are clarity, easily located > > configurations, flexibility in operations, but so far in my learning > > process the systemd approach lacks each of these. > > Network renaming (allowing you to have eth0 instead of en0s3..) was > broken in Beta2, this might explains why you were stuked. > > This will be fixed in Beta3 and for Beta4, we will probably ship a > script to ease the creation of 70-persistent-net.rules based on MAC > address or bus address of the adapter. > > For the documentation on the network precitable names, you can have a > look at > http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterface > Names/ as a initial step. > > -- > Frederic Crozat > SUSE > > _______________________________________________ > sles-beta mailing list > sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta > From mge at suse.com Thu Mar 20 06:07:15 2014 From: mge at suse.com (Matthias G. Eckermann) Date: Thu, 20 Mar 2014 13:07:15 +0100 Subject: [sles-beta] missing /usr/bin/xsltproc in beta2 In-Reply-To: References: <5329D5DB.9090208@netlab1.net> <1395251181.12790.31.camel@par-r81vxc7.par.novell.com> <532AB682020000A8000A742F@nat28.tlf.novell.com> Message-ID: <20140320120715.GD7072@suse.com> On 2014-03-20 T 13:03 +0100 michael.baensch at dfs.de wrote: > It seems like the tool xsltproc is no longer available. > During beta1 it was there, now (in beta2) its missing - > maybe - i hope - a bug... ? In the upcoming SLE 12 Beta3 it will be in the package "libxslt-tools-1.1.28-6.44.x86_64.rpm". Probably, well, did you expect it in the library package? Those have been split according to the package guidelines. 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 fcrozat at suse.com Thu Mar 20 07:14:35 2014 From: fcrozat at suse.com (Frederic Crozat) Date: Thu, 20 Mar 2014 14:14:35 +0100 Subject: [sles-beta] Antwort: Re: missing /usr/bin/xsltproc in beta2 In-Reply-To: References: <5329D5DB.9090208@netlab1.net> <1395251181.12790.31.camel@par-r81vxc7.par.novell.com> <532AB682020000A8000A742F@nat28.tlf.novell.com> <20140320120715.GD7072@suse.com> Message-ID: <1395321275.2158.5.camel@par-r81vxc7.par.novell.com> Le jeudi 20 mars 2014 ? 13:39 +0100, michael.baensch at dfs.de a ?crit : > ok, so xsltproc is than available during the pre-script moment ? What do you call the "pre-script" moment, exactly ? -- Frederic Crozat SUSE From behlert at suse.com Fri Mar 21 03:45:43 2014 From: behlert at suse.com (Stefan Behlert) Date: Fri, 21 Mar 2014 10:45:43 +0100 Subject: [sles-beta] [ANNOUNCE] SLES 12 Beta3 is available Message-ID: <20140321094543.GG5461@suse.de> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !! SUSE CONFIDENTIAL !! SUSE CONFIDENTIAL !! SUSE CONFIDENTIAL !! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Dear Beta participants, we are happy to announce the third Beta of SUSE Linux Enterprise Server 12. ISO images are now available for download now. Please go to http://www.novell.com/beta and select "View my beta page". Here you should see all Beta's you are part of. Note that the directory contains the images for the SDK as well as for SLED. We offer 3 DVD ISOs: DVD1 contains the binaries, the second DVD the sources and the third DVD the debuginfo packages. The final product will not contain the debuginfo packages on the media. For installation purposes you just need Media 1 for your architecture. Please verify the md5sum of the ISO using the MD5SUMS file, which can be found in the same directory on the download servers. Known issues: xxxxxx - installing with ext3 pops up an error If you select ext3 filesystem in the expert partitioner, you get an error popup. You can savely click "continue" there, the installation will succeed. In the installed system, you should change in /etc/fstab the entry for the partition from ext2 to ext3, if you want to use ext3-specific features. 869089 - After registration with SCC, "nu.novell.com" requires additional credentials during installation Workaround: Register the system in the installed system, the credentials are present there. You will then receive Pool and Update channels for the product. 868942 - use add-ons from media" checkbox does not work properly 869424 - No Progress Shown when Adding Repositories after Successful Registration 866051 - keyboard mapping not applied anymore 866055 - gdm doesn't terminate Xorg properly 869127 - Cannot login (graphically), if there is no mouse configured (keyboard focus lost in gdm, workaround is to press "Ctrl-Alt-Tab" until you have focus again) With this Beta3 snapshot we have reached several milestones: o Milestone: All SLE12 features have been functionally tested. o Milestone: All new/updated device drivers have been tested. o Start update tests. o Start system test. For the next Beta-Release we are targetting these actions and milestones: o Milestone: All updated device drivers are verified and proven to be stable o Continue system test. o Fix problems found during update, performance or certification tests. Thanks in advance for all your testing Your SUSE Linux Enterprise Team -- Stefan Behlert, SUSE LINUX Project Manager Enterprise Server Maxfeldstr. 5, D-90409 Nuernberg, Germany Phone +49-911-74053-173 SUSE LINUX Products GmbH, Nuernberg; GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer, HRB 16746 (AG Nuernberg) From kdupke at suse.com Fri Mar 21 04:45:50 2014 From: kdupke at suse.com (Kai Dupke) Date: Fri, 21 Mar 2014 11:45:50 +0100 Subject: [sles-beta] VMware integration - was: SLES12 Beta Question concerning systemd /etc/init.d/boot.local In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0E5B8999@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0E5B88B0@HXMB12.pnet.ch> <1394794249.28828.9.camel@par-r81vxc7.par.novell.com> <40637DBB36AF3941B243A286A432CA0B0E5B88E5@HXMB12.pnet.ch> <532326BF.8030800@suse.com> <40637DBB36AF3941B243A286A432CA0B0E5B8999@HXMB12.pnet.ch> Message-ID: <532C185E.3070309@suse.com> On 03/14/2014 05:02 PM, urs.frey at post.ch wrote: > Really hope that there is something which does work out-of-the box with the VMwareTools delivered by VMware on the ESXi releases > Maybe SLES12 has already VMware certified modules in- Kernel, or there is a Partner package one can select from the SLES bundle o Added open-vm-tools (feature) [x86_64] It isn't marked supported yet. We're are working with VMware to be able to mark it fully supported to deliver a one stop support. Same way you should find the VMware drivers. greetings Kai Dupke Senior Product Manager Server Product Line -- Phone: +49-(0)5102-9310828 Mail: kai.dupke at suse.com Mobile: +49-(0)173-5876766 WWW: www.suse.com SUSE Linux Products GmbH - Maxfeldstr. 5 - 90409 Nuernberg (Germany) GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG Nurnberg) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 263 bytes Desc: OpenPGP digital signature URL: From S.M.Flood at ucs.cam.ac.uk Fri Mar 21 05:16:14 2014 From: S.M.Flood at ucs.cam.ac.uk (Simon Flood) Date: Fri, 21 Mar 2014 11:16:14 +0000 Subject: [sles-beta] [ANNOUNCE] SLES 12 Beta3 is available In-Reply-To: <20140321094543.GG5461@suse.de> References: <20140321094543.GG5461@suse.de> Message-ID: <532C1F7E.2000607@ucs.cam.ac.uk> On 21/03/2014 09:45, Stefan Behlert wrote: > Please verify the md5sum of the ISO using the MD5SUMS file, which can > be found in the same directory on the download servers. As with Beta 2, the MD5SUMS posted has not been updated for the next beta plus this time SHA1SUMS also lists checksums for previous beta (beta 2). Fortunately MD5 checksums are listed on download page. Perhaps someone can make a note to make sure both of these files are updated when releasing the next beta. Thanks. -- Simon Flood Novell/SUSE/NetIQ Knowledge Partner From S.M.Flood at ucs.cam.ac.uk Fri Mar 21 05:49:58 2014 From: S.M.Flood at ucs.cam.ac.uk (Simon Flood) Date: Fri, 21 Mar 2014 11:49:58 +0000 Subject: [sles-beta] [ANNOUNCE] SLES 12 Beta3 is available In-Reply-To: <20140321113026.GZ6054@suse.de> References: <20140321094543.GG5461@suse.de> <532C1F7E.2000607@ucs.cam.ac.uk> <20140321113026.GZ6054@suse.de> Message-ID: <532C2766.2010808@ucs.cam.ac.uk> On 21/03/2014 11:30, Uwe Drechsel wrote: > I just downloaded them (attached) and both refer to Beta 3. I can only > guess that either Edgecast didn't update the files in your region yet, > or some other proxy is in the way. Odd given that the larger DVD ISOs are available in my region (UK, sort of part of Europe). I just tried again and still both refer to Beta 2. I'm using wget so no browser cache getting in the way. Interestingly though the MD5 checksums listed on the Beta 3 download page for both MD5SUMS and SHA1SUMS don't match the files I'm getting. Trying again for a third time gives me a "We're sorry, we are unable to complete the download at this time" so perhaps all is not okay somewhere. Thanks. -- Novell/SUSE/NetIQ Knowledge Partner From uwedr at suse.com Fri Mar 21 05:57:43 2014 From: uwedr at suse.com (Uwe Drechsel) Date: Fri, 21 Mar 2014 12:57:43 +0100 Subject: [sles-beta] [ANNOUNCE] SLES 12 Beta3 is available In-Reply-To: <532C2766.2010808@ucs.cam.ac.uk> References: <20140321094543.GG5461@suse.de> <532C1F7E.2000607@ucs.cam.ac.uk> <20140321113026.GZ6054@suse.de> <532C2766.2010808@ucs.cam.ac.uk> Message-ID: <20140321115743.GB6054@suse.de> On Fri, Mar 21, Simon Flood wrote: > > I just tried again and still both refer to Beta 2. I'm using wget so > no browser cache getting in the way. > > Interestingly though the MD5 checksums listed on the Beta 3 download > page for both MD5SUMS and SHA1SUMS don't match the files I'm > getting. > > Trying again for a third time gives me a "We're sorry, we are unable > to complete the download at this time" so perhaps all is not okay > somewhere. > Sorry for the trouble. We recently switched from Akami to Edgecast to improve the overall download experience. The main server is still with Novell in the US, Edgecast spreads from there. The last files have been uploaded a few hours ago, we'll keep an eye on this. Thanks Uwe -- Uwe Drechsel Project Manager SUSE Linux Products GmbH GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) From S.M.Flood at ucs.cam.ac.uk Fri Mar 21 08:18:57 2014 From: S.M.Flood at ucs.cam.ac.uk (Simon Flood) Date: Fri, 21 Mar 2014 14:18:57 +0000 Subject: [sles-beta] [ANNOUNCE] SLES 12 Beta3 is available In-Reply-To: <20140321115743.GB6054@suse.de> References: <20140321094543.GG5461@suse.de> <532C1F7E.2000607@ucs.cam.ac.uk> <20140321113026.GZ6054@suse.de> <532C2766.2010808@ucs.cam.ac.uk> <20140321115743.GB6054@suse.de> Message-ID: <532C4A51.7090006@ucs.cam.ac.uk> On 21/03/2014 11:57, Uwe Drechsel wrote: > Sorry for the trouble. > > We recently switched from Akami to Edgecast to improve the overall > download experience. The main server is still with Novell in the US, > Edgecast spreads from there. > > The last files have been uploaded a few hours ago, we'll keep an eye on > this. Hmm I'm still getting the Beta2 versions of both the MD5SUMS and SHA1SUMS files. I did wonder about your reference to Edgecast given all the file download URLs still include "&mirror=AkamaiHost". Fortunately it's only the *SUMS files so I can at least be installing Beta 3 whilst occasionally retrying downloads. Note the HA *SUMS files were correct at first attempt. Note also that the HA *SUMS files have dates/times of 20 March 20:36 (as kept by using wget) whereas the SLES12 ones are 7 Mar 16:08, the latter date being when Beta 2 was released for testing ... Unless others are seeing the same perhaps we should take this off-list. Please feel free to contact me directly. Thanks. -- Simon Flood Novell/SUSE/NetIQ Knowledge Partner From jrd at netlab1.net Fri Mar 21 08:49:00 2014 From: jrd at netlab1.net (Joe Doupnik) Date: Fri, 21 Mar 2014 14:49:00 +0000 Subject: [sles-beta] Beta 3, FTP again Message-ID: <532C515C.2070808@netlab1.net> SLES 12 Beta 3. Alas, our recently discussed friend lftp seems to have taken a holiday from this beta. It is not installed with the usual patterns. However, a zypper in lftp brought it in. Once in, it still needs improvement. First, let's please use name ftp, not a whimsical thingy. Second, the username prompt is still absent. Third, it puts up a gibberish string with its prompt; said gibberish is not useful nor pleasant to see. Beta 3 installed nicely as an ESXi guest. Partitioning now works. Yeah. (not using autoyast here) Lan adapter name change to sane eth0 via YaST works. Lots of yet to be done areas are apparent, but you probably know about that(!). Overall, progress. Thanks, Joe D. From mge at suse.com Fri Mar 21 08:55:03 2014 From: mge at suse.com (Matthias G. Eckermann) Date: Fri, 21 Mar 2014 15:55:03 +0100 Subject: [sles-beta] SLES12 x86_64 Beta3 Installation In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0EFA7772@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0EFA7772@HXMB12.pnet.ch> Message-ID: <20140321145503.GC29461@suse.com> On 2014-03-21 T 14:47 +0000 urs.frey at post.ch wrote: > When trying to install SLES12 Beta3 on HP Proliant > DL380-G7 after starting udev I can see only a progress > bar, instead oft ext saying what is going on. > > I am not installing Windows, so why this progress bar? > How can I get rid of this ugly thing? I did not find > anything in the Installer help yet. Doesn't "ESC" work for you? (It does for me) > I would like to know which drivers are getting > detected and if the installer starts up correctly Or doesn't it show enough? 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 mge at suse.com Fri Mar 21 08:57:46 2014 From: mge at suse.com (Matthias G. Eckermann) Date: Fri, 21 Mar 2014 15:57:46 +0100 Subject: [sles-beta] Beta 3, FTP again In-Reply-To: <532C515C.2070808@netlab1.net> References: <532C515C.2070808@netlab1.net> Message-ID: <20140321145746.GD29461@suse.com> Hello Joe and all, On 2014-03-21 T 14:49 +0000 Joe Doupnik wrote: > Lots of yet to be done areas are apparent, but you > probably know about that(!). Yes, we do. And some of the already existing patches just did not make it into Beta3 anymore: unfortunately you have to "cut off" at one point in time. > Overall, progress. Thanks for checking so quickly. 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 urs.frey at post.ch Fri Mar 21 09:00:25 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Fri, 21 Mar 2014 15:00:25 +0000 Subject: [sles-beta] SLES12 x86_64 Beta3 Installation In-Reply-To: <20140321145503.GC29461@suse.com> References: <40637DBB36AF3941B243A286A432CA0B0EFA7772@HXMB12.pnet.ch> <20140321145503.GC29461@suse.com> Message-ID: <40637DBB36AF3941B243A286A432CA0B0EFA7799@HXMB12.pnet.ch> Thanks for the hint >Doesn't "ESC" work for you? (It does for me) >> I would like to know which drivers are getting >> detected and if the installer starts up correctly >Or doesn't it show enough? ESC key at this time within linuxRC is one input too much. I am thinking about autoyast, there I need verbose output at once no ESC key possible 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: Matthias G. Eckermann [mailto:mge at suse.com] Gesendet: Friday, March 21, 2014 3:55 PM An: Frey Urs, IT222; sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES12 x86_64 Beta3 Installation On 2014-03-21 T 14:47 +0000 urs.frey at post.ch wrote: > When trying to install SLES12 Beta3 on HP Proliant > DL380-G7 after starting udev I can see only a progress > bar, instead oft ext saying what is going on. > > I am not installing Windows, so why this progress bar? > How can I get rid of this ugly thing? I did not find > anything in the Installer help yet. Doesn't "ESC" work for you? (It does for me) > I would like to know which drivers are getting > detected and if the installer starts up correctly Or doesn't it show enough? 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 mge at suse.com Fri Mar 21 09:20:39 2014 From: mge at suse.com (Matthias G. Eckermann) Date: Fri, 21 Mar 2014 16:20:39 +0100 Subject: [sles-beta] SLES12 x86_64 Beta3 Installation In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0EFA7799@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0EFA7772@HXMB12.pnet.ch> <20140321145503.GC29461@suse.com> <40637DBB36AF3941B243A286A432CA0B0EFA7799@HXMB12.pnet.ch> Message-ID: <20140321152039.GC31005@suse.com> On 2014-03-21 T 15:00 +0000 urs.frey at post.ch wrote: > Thanks for the hint > > >Doesn't "ESC" work for you? (It does for me) > > >> I would like to know which drivers are getting > >> detected and if the installer starts up correctly > > >Or doesn't it show enough? > > ESC key at this time within linuxRC is one input too > much. I am thinking about autoyast, there I need > verbose output at once no ESC key possible That's a valid point. Please open an SR, requesting that AutoYaST should switch off the "splash". I cannot promise this, though (have to check feasibility first). Thanks in advance! so long - MgE > 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: Matthias G. Eckermann [mailto:mge at suse.com] > Gesendet: Friday, March 21, 2014 3:55 PM > An: Frey Urs, IT222; sles-beta at lists.suse.com > Betreff: Re: [sles-beta] SLES12 x86_64 Beta3 Installation > > On 2014-03-21 T 14:47 +0000 urs.frey at post.ch wrote: > > > When trying to install SLES12 Beta3 on HP Proliant > > DL380-G7 after starting udev I can see only a progress > > bar, instead oft ext saying what is going on. > > > > I am not installing Windows, so why this progress bar? > > How can I get rid of this ugly thing? I did not find > > anything in the Installer help yet. > > Doesn't "ESC" work for you? (It does for me) > > > I would like to know which drivers are getting > > detected and if the installer starts up correctly > > Or doesn't it show enough? > > 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) -- 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 jrd at netlab1.net Fri Mar 21 09:45:58 2014 From: jrd at netlab1.net (Joe Doupnik) Date: Fri, 21 Mar 2014 15:45:58 +0000 Subject: [sles-beta] Beta 3, /etc/resolv.conf Message-ID: <532C5EB6.1010609@netlab1.net> When first installing beta 3 I left the lan adapter in DHCP mode. After a clean reboot I changed the adapter to a static IP with details. When I looked at /etc/resolv.conf it had "search lan", the first two IP's of nameservers picked up from DHCP, and only one of the two name servers which I typed into YaST. Basically a muddle, and not quite what I told YaST about things. I simply recreated resolv.conf in proper form by hand and DNS lookups worked. Joe D. From fcrozat at suse.com Fri Mar 21 10:40:50 2014 From: fcrozat at suse.com (Frederic Crozat) Date: Fri, 21 Mar 2014 17:40:50 +0100 Subject: [sles-beta] SLES12 Beta3 x86_64 shutdown ? In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0EFA7852@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0EFA7852@HXMB12.pnet.ch> Message-ID: <1395420050.6754.60.camel@par-r81vxc7.par.novell.com> Le vendredi 21 mars 2014 ? 16:22 +0000, urs.frey at post.ch a ?crit : > Hi > > When doing a shutdown with SLES12 Beta3 on x86_64 the server seems to > get kind of crashed. > Network is cut off at once and on the ILO3 console of my ProLiant, the > screen gets black instantly. > > When remembering the SystemV way, when I could follow each service > getting stopped and disk drive sync at the end. > SLES12 Beta3 today nada, is this normal? try removing "quiet" and "splash=..." on the kernel command line. > Am I missing something? Pressing esc at shutdown should enable verbose output. > I also miss a shutdown log or something similar. Everything is pushed to rsyslog. -- Frederic Crozat SUSE From mge at suse.com Fri Mar 21 16:34:21 2014 From: mge at suse.com (Matthias G. Eckermann) Date: Fri, 21 Mar 2014 23:34:21 +0100 Subject: [sles-beta] Beta 3, "startx" as non-root fails In-Reply-To: <532C8D96.7000107@netlab1.net> References: <532C8D96.7000107@netlab1.net> Message-ID: Hello Joe and all, I remember a discussion ~1year ago, but not the details (will check on monday), and it might be a security feature (the screenshots support this idea: see the last two lines!). I know, I know, ...:-( However, if it really is a security feature, I will have to prepare the battle carefully: it will be a battle against myself, wearing the security hat -- and usually security wins. Enjoy the weekend - MgE On 21. M?rz 2014 20:05:58 MEZ, Joe Doupnik wrote: > As an ordinary user on SLES, login to the console and give command >startx. After a significant pause the command fails. Attached is a >screen capture of it. > Root, by contrast, does get the Gnome GUI. > As a test I did chmod a+w /var/log as root, returned to being a >normal user and tried again. Still failure, as shown in the second >screen capture. > Running as a VMware ESXi guest. > Joe D. > > > >------------------------------------------------------------------------ > >_______________________________________________ >sles-beta mailing list >sles-beta at lists.suse.com >http://lists.suse.com/mailman/listinfo/sles-beta -- Sent from mobile. Please excuse my brevity. From jrd at netlab1.net Sat Mar 22 03:24:19 2014 From: jrd at netlab1.net (Joe Doupnik) Date: Sat, 22 Mar 2014 09:24:19 +0000 Subject: [sles-beta] Beta 3, "startx" as non-root fails In-Reply-To: References: <532C8D96.7000107@netlab1.net> Message-ID: <532D56C3.6010603@netlab1.net> Matthias, Yes, a security feature is a prime suspect. I had ascribed the situation to just another partly completed development effort and all would be fine when it is fully written and tested. After all, this did work in Beta 2. Good luck with sorting the security aspect. Thanks, Joe D. On 21/03/2014 22:34, Matthias G. Eckermann wrote: > Hello Joe and all, > > I remember a discussion ~1year ago, > but not the details (will check on monday), > and it might be a security feature > (the screenshots support this idea: see the last two lines!). > > I know, I know, ...:-( > > However, if it really is a security feature, > I will have to prepare the battle carefully: > it will be a battle against myself, > wearing the security hat -- > and usually security wins. > > Enjoy the weekend - > MgE > > > On 21. M?rz 2014 20:05:58 MEZ, Joe Doupnik wrote: >> As an ordinary user on SLES, login to the console and give command >> startx. After a significant pause the command fails. Attached is a >> screen capture of it. >> Root, by contrast, does get the Gnome GUI. >> As a test I did chmod a+w /var/log as root, returned to being a >> normal user and tried again. Still failure, as shown in the second >> screen capture. >> Running as a VMware ESXi guest. >> Joe D. >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> sles-beta mailing list >> sles-beta at lists.suse.com >> http://lists.suse.com/mailman/listinfo/sles-beta From jrd at netlab1.net Sat Mar 22 06:39:54 2014 From: jrd at netlab1.net (Joe Doupnik) Date: Sat, 22 Mar 2014 12:39:54 +0000 Subject: [sles-beta] Beta 3, "startx" as non-root fails In-Reply-To: References: <532C8D96.7000107@netlab1.net> Message-ID: <532D849A.8010108@netlab1.net> Permissions on /usr/bin/Xorg: need to be suid root (-rws--x--x). Compare with SLES 11 et al. Now it startx works for a regular user. Joe D. On 21/03/2014 22:34, Matthias G. Eckermann wrote: > Hello Joe and all, > > I remember a discussion ~1year ago, > but not the details (will check on monday), > and it might be a security feature > (the screenshots support this idea: see the last two lines!). > > I know, I know, ...:-( > > However, if it really is a security feature, > I will have to prepare the battle carefully: > it will be a battle against myself, > wearing the security hat -- > and usually security wins. > > Enjoy the weekend - > MgE > > > On 21. M?rz 2014 20:05:58 MEZ, Joe Doupnik wrote: >> As an ordinary user on SLES, login to the console and give command >> startx. After a significant pause the command fails. Attached is a >> screen capture of it. >> Root, by contrast, does get the Gnome GUI. >> As a test I did chmod a+w /var/log as root, returned to being a >> normal user and tried again. Still failure, as shown in the second >> screen capture. >> Running as a VMware ESXi guest. >> Joe D. >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> sles-beta mailing list >> sles-beta at lists.suse.com >> http://lists.suse.com/mailman/listinfo/sles-beta From jrd at netlab1.net Sat Mar 22 11:10:53 2014 From: jrd at netlab1.net (Joe Doupnik) Date: Sat, 22 Mar 2014 17:10:53 +0000 Subject: [sles-beta] Beta 3, FTP again In-Reply-To: <532C515C.2070808@netlab1.net> References: <532C515C.2070808@netlab1.net> Message-ID: <532DC41D.6040800@netlab1.net> A follow up on this message as I again try using lftp. Golly, what a muddle this thing is. It gets worse as one tries to do something with it. At this point my recommendation is restore lukemftp as the main ftp client, put lftp into the also-available category for those who wish to use it. At some time in the future lftp may grow up to be a proper ftp client for people to use, but it is not even close to that today, despite the kitchen sink list of things it tries do. Thanks, Joe D. On 21/03/2014 14:49, Joe Doupnik wrote: > SLES 12 Beta 3. Alas, our recently discussed friend lftp seems to have > taken a holiday from this beta. It is not installed with the usual > patterns. However, a zypper in lftp brought it in. > Once in, it still needs improvement. First, let's please use name > ftp, not a whimsical thingy. Second, the username prompt is still > absent. Third, it puts up a gibberish string with its prompt; said > gibberish is not useful nor pleasant to see. > > Beta 3 installed nicely as an ESXi guest. > Partitioning now works. Yeah. (not using autoyast here) > Lan adapter name change to sane eth0 via YaST works. > Lots of yet to be done areas are apparent, but you probably know > about that(!). > Overall, progress. > Thanks, > Joe D. > _______________________________________________ > sles-beta mailing list > sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta From jrd at netlab1.net Sat Mar 22 12:52:03 2014 From: jrd at netlab1.net (Joe Doupnik) Date: Sat, 22 Mar 2014 18:52:03 +0000 Subject: [sles-beta] Beta 3, FTP again In-Reply-To: <532DC41D.6040800@netlab1.net> References: <532C515C.2070808@netlab1.net> <532DC41D.6040800@netlab1.net> Message-ID: <532DDBD3.7030500@netlab1.net> More on the ftp theme. Two items here, referencing SLES 12 beta 3. First, for unknown reasons the vsftpd server is unable to connect to a caller on port 21. The error response from "telnet localhost 21" is "500 OOPS: could not bind listening IPv4 socket. Connection closed by foreign host." The identical message appears when using the Win 7 ftp client to that machine. Netstat -nltp shows port 21 listened to xinetd, and the vsftpd section of /etc/xinetd.d has vsftpd enabled. The vsftpd binary is present as /usr/sbin/vsftpd which xinetd.d/vsftpd states. Telnet localhost does connect to the telnet server via xinetd (I enabled telnet there). /var/log/messages simply says "EXIT: ftp status=2." I find the failure to be strange as this is a very standard and long used arrangement. Double checking things. I stopped xinetd (rcxinetd stop) and then started vsftpd as a daemon (rcvsftpd start). Telnet localhost 21 now opens the connection (with no local echo of course) and I can log in etc. Second, for general information, I went and built lukemftp (now known as tnftp) ftp client from source and it works just fine. I substituted it for lftp by editing the yet another indirection symlink ftp in /etc/alternatives. I was going to give HA components a trial run, with DRBD et al, but with communications and many other things being problematic I think that should wait for beta 4 or 5. Joe D. On 22/03/2014 17:10, Joe Doupnik wrote: > A follow up on this message as I again try using lftp. Golly, what a > muddle this thing is. It gets worse as one tries to do something with it. > At this point my recommendation is restore lukemftp as the main > ftp client, put lftp into the also-available category for those who > wish to use it. At some time in the future lftp may grow up to be a > proper ftp client for people to use, but it is not even close to that > today, despite the kitchen sink list of things it tries do. > Thanks, > Joe D. > > On 21/03/2014 14:49, Joe Doupnik wrote: >> SLES 12 Beta 3. Alas, our recently discussed friend lftp seems to >> have taken a holiday from this beta. It is not installed with the >> usual patterns. However, a zypper in lftp brought it in. >> Once in, it still needs improvement. First, let's please use name >> ftp, not a whimsical thingy. Second, the username prompt is still >> absent. Third, it puts up a gibberish string with its prompt; said >> gibberish is not useful nor pleasant to see. >> >> Beta 3 installed nicely as an ESXi guest. >> Partitioning now works. Yeah. (not using autoyast here) >> Lan adapter name change to sane eth0 via YaST works. >> Lots of yet to be done areas are apparent, but you probably know >> about that(!). >> Overall, progress. >> Thanks, >> Joe D. >> _______________________________________________ >> sles-beta mailing list >> sles-beta at lists.suse.com >> http://lists.suse.com/mailman/listinfo/sles-beta > From Dick.Waite at softwareag.com Sun Mar 23 04:54:21 2014 From: Dick.Waite at softwareag.com (Waite, Dick) Date: Sun, 23 Mar 2014 10:54:21 +0000 Subject: [sles-beta] Upgrade from 11-3 to 12-0 -- s390x iso's Message-ID: <46AC8C81C10B8C48820201DF2AE1D76D5377CCBB@hqmbx6.eur.ad.sag> Grand New Sunday, Uwe would it be possible to include a session on migration from the grand KDE environment to the other desktop (GNOME). I have spent my whole Linux life on KDE and now having to migrate my desktops from SLE 11-3 to 12-0 and GNOME is giving me issues. I expect there is a white paper, or many papers written on how to do this, but having one which also took into consideration the migration from 11-3 to 12-0 would be, for me and other's in the grey hair group very helpful. I have spent the past couple of nights trying to get some 11-3's onto 12-0 but with little to no success. Network is one item that throws a spanner into the works. Before migrating I always remove the network device, 12-0 beta3 does not like this. I have tried converting a 11-3 KDE to GNOME before running the 11-3 to 12-0 upgrade, that does not work for me. If you try to upgrade a 11-3 KDE to 12-0 the good environment get very hot under collar, so it seems you have to convert to GNOME before running an upgrade, true or false ? By a very strange coincidence, the "other people" (Redhat) are also running a Beta for RHEL v7 at the same time SUSE are running SLE 12 and SAG like I expect many others are part of it. KDE is alive and very well over there, which is odd as I always that SUSE and KDE went together and RHEL and Gnome were the other people. I'm now building a new install of SLE 11-3 with *only* GNOME and will try to upgrade that to 12-0, but having some good words from the *source* on how to do this "in-flight" from 11-3 to 12-0 would be *VERY* welcome. Your forcing us to do this, I think a little help to make the task "comfortable" would be a good idea, better would have been a lot more notice your going to do this so companies could have a little time to take corporate decisions. As I see no s390x iso's on your sites this is still on hold until beta4? __R Software AG ? Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany ? Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com From Dick.Waite at softwareag.com Sun Mar 23 07:07:28 2014 From: Dick.Waite at softwareag.com (Waite, Dick) Date: Sun, 23 Mar 2014 13:07:28 +0000 Subject: [sles-beta] Upgrade fromSLE 11-3 to 12-0 on x86_64 Message-ID: <46AC8C81C10B8C48820201DF2AE1D76D5377CD49@hqmbx6.eur.ad.sag> Grand Sunday Afternoon, The words I have seen too often, "The installed product is not compatible with the product on the installation media. If you try to update using the current installation media, the system may not start or some applications may not run properly." This was a new install of SLE 11-3 on new disks using only defaults. I did load the system a couple of times after the install to check it ran and looked Okay. I then switched the environment to point at SLE 12-0 Beta3 iso's. So it looks like from what I see a SLE 11-3 with GNOME can not be upgraded to 12-0 beta3 with Gnome. The release notes 12.0.8 which say they can also be found at "http://www.suse.com/documentation/sles12", which gives a 404, and has a small font in green on the black background which is not very friendly to the eyes, section 4.4 Upgrade-related Notes, in a grand white font, 4.4.1 it does say: "SLES 11 GA -> SLES 11 SP1 -> SLES SP2 -> SLES SP3 -> SLES 12 GA". True this is only Beta3 but I did understand Upgrade with beta3 is supported. Time to call it a day I think. Looking forward to tomorrow evenings meeting, could be quite lively and I'm sure productive. We all want v12 to be a grand release, much better then, "the other red one v7". ;o) __R Software AG ? Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany ? Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com -------------- next part -------------- An HTML attachment was scrubbed... URL: