openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842022-07-18T11:16:56ZopenSUSE Project Management Tool
Redmine openQA Infrastructure - action #113716 (Resolved): [qe-core] proxy-scc is downhttps://progress.opensuse.org/issues/1137162022-07-18T11:16:56Zmaritawernermawerner@suse.com
<p>On Friday, July 15, at 10.45 the proxy-scc stopped working. A Jira SD ticket for eng infra was raised by QE: <a href="https://sd.suse.com/servicedesk/customer/portal/1/SD-92678" class="external">https://sd.suse.com/servicedesk/customer/portal/1/SD-92678</a></p>
<p>In the slack channel help-scc Jiri Novak and Thomas Schmidt from the SCC team discussed the technical details:<br>
<a href="https://suse.slack.com/archives/C02AYV7UJSD/p1657792209257829" class="external">https://suse.slack.com/archives/C02AYV7UJSD/p1657792209257829</a></p>
<p>In short: the very old caasp cluster will be replaced by a Kubernetes instance.</p>
openQA Tests - action #13750 (Resolved): HPC Module https://progress.opensuse.org/issues/137502016-09-16T07:28:15Zmaritawernermawerner@suse.com
<p>For details see HPC Tracker feature</p>
<p><a href="https://fate.suse.com/320596" class="external">https://fate.suse.com/320596</a></p>
<ul>
<li>Install the HPC module</li>
<li>Look into the features listed in the tracker feature</li>
<li>Check with Egbert Eich: more details needed, no Testcases available</li>
</ul>
openQA Tests - action #12910 (Resolved): Feature 320418: Proper placement of "encrypt filesystem"...https://progress.opensuse.org/issues/129102016-07-28T09:21:25Zmaritawernermawerner@suse.com
<p>Check<br>
<a href="https://fate.suse.com/320418" class="external">https://fate.suse.com/320418</a></p>
openQA Tests - action #11804 (Resolved): Feature 320678: GCC 4.8 on SDK for AArch64https://progress.opensuse.org/issues/118042016-05-04T11:41:01Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/320678" class="external">https://fate.suse.com/320678</a><br>
Feature status is "done".</p>
<p>Description:<br>
For the toolchain, we decided to do the following<br>
Build distro with GCC 4.8.<br>
ship the compiler as a package with no support for user builds (add it to SDK).<br>
As on all other architectures: Have gcc package in version 4.8 that links gcc to gcc-4.8 and have it in the SDK as well.<br>
Enable toolchain module directly during registration (see separate fate entry).<br>
Note this uses GCC 4.8 for the Kernel. If we need to switch for the kernel to a newer compiler, we can discuss later again.<br>
Following packages will be migrated from aarch64 SLES media to SDK: <br>
gcc48<br>
gcc48-c++<br>
gcc48-fortran<br>
gcc48-info<br>
gcc48-locale<br>
gcc48-objc<br>
gcc48-obj-c++<br>
libstdc++48-devel</p>
openQA Tests - action #11800 (Resolved): Feature 320292: ALPN support for opensslhttps://progress.opensuse.org/issues/118002016-05-04T11:35:26Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/320292" class="external">https://fate.suse.com/320292</a></p>
<p>Feature is set to done.</p>
<p>Testcase:</p>
<p>setup apache2 host with ALPN support, (basically configure SSL and also follow<br>
<a href="https://httpd.apache.org/docs/trunk/mod/mod_http2.html" class="external">https://httpd.apache.org/docs/trunk/mod/mod_http2.html</a> adding "Protocols h2 http/1.1"<br>
to test the setup, from opensuse factory: curl --http2 <a href="https://HOSTNAME" class="external">https://HOSTNAME</a><br>
The call also might need the --insecure option too if you used a self-signed certificate during apache2 setup.<br>
Another simpler test can be: server# openssl s_server -key key.pem -cert cert.pem -alpn http<br>
client# openssl s_client -connect server:4433 -alpn http<br>
And check the client output for "ALPN protocol: http" / "No ALPN negotiated"</p>
openQA Tests - action #11708 (Resolved): Add-on installation: review zypper_lr testcasehttps://progress.opensuse.org/issues/117082016-04-25T09:31:22Zmaritawernermawerner@suse.com
<p>After the installation the pool channels should be added and tested but it seems that the testcase zypper_lr does not do that properly, no needles are visible,<br>
e.g. <a href="https://openqa.suse.de/tests/356456/modules/zypper_lr/steps/1" class="external">https://openqa.suse.de/tests/356456/modules/zypper_lr/steps/1</a></p>
openQA Tests - action #11564 (Resolved): s390x: add SSH+GUI as frontend to the Installation processhttps://progress.opensuse.org/issues/115642016-04-11T08:27:44Zmaritawernermawerner@suse.com
<p>as discussed with Matthias</p>
openQA Tests - action #11562 (Rejected): s390x: local disk, add a second diskhttps://progress.opensuse.org/issues/115622016-04-11T08:25:18Zmaritawernermawerner@suse.com
<p>as discussed with Matthias, add a Testcae with a second disk</p>
openQA Tests - action #11510 (Closed): SLE HA - add system role https://progress.opensuse.org/issues/115102016-04-06T07:23:09Zmaritawernermawerner@suse.com
<p><a href="https://openqa.suse.de/tests/333661/modules/addon_products_sle/steps/4" class="external">https://openqa.suse.de/tests/333661/modules/addon_products_sle/steps/4</a></p>
openQA Tests - action #11462 (Resolved): Feature 320597 and 320699: Introduce 'zypper lifecycle' ...https://progress.opensuse.org/issues/114622016-04-01T13:08:31Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/320597" class="external">https://fate.suse.com/320597</a></p>
<p>First check if the Feature status is "done".</p>
<hr>
<p>In addition please extend the Testcase to test Feature 320699: Do not communicate End of Support dates, that change later to a previous point in time.</p>
<p>For details see <a href="https://fate.suse.com/320699" class="external">https://fate.suse.com/320699</a></p>
openQA Tests - action #11460 (Resolved): Feature 320494: Disable installation source after instal...https://progress.opensuse.org/issues/114602016-04-01T13:06:12Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/320494" class="external">https://fate.suse.com/320494</a></p>
<p>First check if the Feature status is "done".</p>
openQA Tests - action #11458 (Resolved): Feature 319716: Automatic Update of YaST at beginning of...https://progress.opensuse.org/issues/114582016-04-01T13:04:25Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/319716" class="external">https://fate.suse.com/319716</a></p>
<p>First check if the Feature status is "done".</p>
<a name="tasks-left-to-be-done"></a>
<h2 >tasks left to be done<a href="#tasks-left-to-be-done" class="wiki-anchor">¶</a></h2>
<ul>
<li>verify on osd that it's triggered as <code>yast_no_self_update</code> on 12-sp2 server build > 2002</li>
<li>add to o3</li>
<li>optionally: extend to check that the installer really updates itself in case an update is present</li>
</ul>
openQA Tests - action #11456 (Resolved): Feature 319639: Set hostname in Installer properlyhttps://progress.opensuse.org/issues/114562016-04-01T13:03:11Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/319639" class="external">https://fate.suse.com/319639</a></p>
<p>First check if the Feature status is "done".</p>
<p>All components of the Installer depend on correctly configured network. Current system hostname is, e.g. used as "the default" when user tries to (re)configure their network in Installer. This configuration checks validity of entered (or default) values and complain when something is wrong. This confuses users as we are expected to provide sane defaults (or nothing).</p>
<p>When Linuxrc is in charge of configuring network (e.g. when installation is started with ifcfg=*=dhcp or when Linuxrc just needs network) the inst-sys then resolves own hostname to the ip address of "first" network interface. It confuses all tools which depends on the resolver's result (e.g. hostname --fqdn)</p>
<p>Proper behavior should be (very simple one out of several possible scenarios):</p>
<pre><code>use a hostname provided by DHCP server (if any) or
return "not resolvable" error
</code></pre>
<p>The question is: What to use as a system name (e.g., for command line) in inst-sys? It seems that "installer" or "suse" would just do the job.</p>
<p>For SLE 12 SP1 it was hotfixed on yast side (see <a href="https://bugzilla.suse.com/show_bug.cgi?id=946047" class="external">https://bugzilla.suse.com/show_bug.cgi?id=946047</a> for reference)</p>
<p>Purpose of this request is to get proper fix into linuxrc and to drop above hotfix from yast, so affrected pieces are (probably): Linuxrc, installation-images and yast2</p>
openQA Tests - action #11454 (Resolved): Feature 319624: YaST - Existing SSH Host Keys Dialoghttps://progress.opensuse.org/issues/114542016-04-01T13:02:05Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/319624" class="external">https://fate.suse.com/319624</a></p>
<p>First check if the Feature status is "done".</p>
<p>YaST has the following feature that could lead to security implications.</p>
<a name="httpswwwsusecomdocumentationsles-12book_sle_deploymentdatasec_i_yast2_proposalhtml"></a>
<h2 ><a href="https://www.suse.com/documentation/sles-12/book_sle_deployment/data/sec_i_yast2_proposal.html" class="external">https://www.suse.com/documentation/sles-12/book_sle_deployment/data/sec_i_yast2_proposal.html</a><a href="#httpswwwsusecomdocumentationsles-12book_sle_deploymentdatasec_i_yast2_proposalhtml" class="wiki-anchor">¶</a></h2>
<p>HINT: Existing SSH Host Keys</p>
<a name="If-you-install-SUSE-Linux-Enterprise-Server-on-a-machine-with-one-or-more-existing-Linux-installations-the-installation-routine-automatically-imports-the-SSH-host-key-with-the-most-recent-access-time-from-an-existing-installation"></a>
<h2 >If you install SUSE Linux Enterprise Server on a machine with one or more existing Linux installations, the installation routine automatically imports the SSH host key with the most recent access time from an existing installation.<a href="#If-you-install-SUSE-Linux-Enterprise-Server-on-a-machine-with-one-or-more-existing-Linux-installations-the-installation-routine-automatically-imports-the-SSH-host-key-with-the-most-recent-access-time-from-an-existing-installation" class="wiki-anchor">¶</a></h2>
<p>If a system was compromised the keys shouldn't be used during system re-installation. Currently the user needs to delete the keys manually or to delete the complete partition table so that YaST will not find the data during installation.</p>
<p>The idea of this feature is to have a special YaST dialog that notifies the user that an old system was found and offers the option to import the existing SSH keys. This would make the import and the already existing feature more transparent.</p>
<p>The current list is here, in control file: <a href="https://github.com/yast/skelcd-control-SLES/blob/d2f9a79c0681806bf02eb38c4b7c287b9d9434eb/control/control.SLES.xml#L53-L71" class="external">https://github.com/yast/skelcd-control-SLES/blob/d2f9a79c0681806bf02eb38c4b7c287b9d9434eb/control/control.SLES.xml#L53-L71</a> </p>
openQA Tests - action #11452 (Resolved): Feature 318945: AutoYaST EULA displayhttps://progress.opensuse.org/issues/114522016-04-01T13:00:40Zmaritawernermawerner@suse.com
<p>For details see <a href="https://fate.suse.com/318945" class="external">https://fate.suse.com/318945</a><br>
Feature status is "done".</p>
<p>During the SLES12 Common Criteria AutoYaST profile development we came across a limitation that the EULA page cannot be shown and accepted during the installation.</p>
<p>As the Common Criteria AutoYaST profiles for SLES12 are predefined and not created by a system administrator the EULA needs to be accepted during installation. Right now we use the Firstboot YaST service to show the EULA during first system boot.</p>
<p>Acceptance criteria:</p>
<ul>
<li>define and document the way customers using AutoYaST should accept the EULA</li>
</ul>