May 2020 - ARCHIVED: Uyuni Users - openSUSE Mailing Lists

[uyuni-users] Using AD user account
by Tobias Crefeld 09 Jun '20

09 Jun '20

Hi, on a Linux (SLES15) salt client that is integrated in an Active Directory, the following scriptlet fails with an error message that the user (svc-backup005) is unknown: /home/svc-backup005: file.directory: - user: svc-backup005 - group: users - mode: '0700' Similar scripts with other users run fine. The only difference is, that those users are local users (/etc/passwd) and svc-backup005 is an AD user. Login (PAM + sss) and commands like getent or id run fine with this user but it seems that Salt doesn't recognize AD users. Any idea? Thanks in advance! Regards, Tobias. -- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org

3 5

[uyuni-users] RE: Ansible Role for installing and configuring Uyuni
by Pau Garcia Quiles 02 Jun '20

02 Jun '20

Hey Christian That looks awesome. Would you like to present it in the next Uyuni Community Hours, in 4 weeks? Thank you Pau Garcia Quiles SUSE Manager Product Owner & Technical Project Manager Phone: +1 385-666-5608 SUSE Software Solutions Spain ________________________________ De: Stankowic, Christian Enviado: Viernes, 29 de Mayo de 2020 16:15 Para: uyuni-users(a)opensuse.org Asunto: [uyuni-users] Ansible Role for installing and configuring Uyuni Hi community, I’m working as a consultant and pretty often I need to install Uyuni or SUSE Manager on customer systems. A lot of my customers use Ansible and so I decided to create a role for installing and configuring it. I know SUSE focusses heavily on Salt – but maybe somebody also needs to install and configure Uyuni via Ansible. I’d love to hear your thoughts and feedback: https://galaxy.ansible.com/stdevel/uyuni I successfully tested it with the latest Uyuni and SUSE Manager versions: some features such as Proxy configuration are planned for the future. Best wishes, Christian.

2 1

[uyuni-users] Opportunities for the Community
by Julio González Gil 29 May '20

29 May '20

Hi everyone, As discussed today at the Uyuni Community Hours, there are some opportunities for all the community to contribute back. You do not really need to be a developer, as you can also help with translation, documentation, or even design. Even with the website! Here are the topics that were proposed: - Translations: UI, documentation (no coding skills required) - Learning pills (articles, videos) - Salt formulas, forms: Active Directory authentication, Samba, Web Server... (no real coding skills required) - Import Debian and Ubuntu patches ("errata") information. - Debian autoinstallation: preseed support - Amazon Linux 2 repository syncing (requires adding sqlite support) - Virtual host gatherers for your favourite cloud or virtualizaton platform - Implemente GPG key management RFC - Content mirroring and statging - Virtualization enhacements: network configuration, snapshots management, PXE boot... - Support for more operating systems: MS Windows, Mac, Android... - LSP support in file viewers / editors (e.g. Eclipse Theia / Microsoft Monaco) - Integrate create-your-own-dashboard framework. Those are just some examples, so if you want to do something else, feel free to bring it forward. So if you are interested in any of the topics above, or you want to propose others, just write at uyuni-devel(a)opensuse.org so we can kickoff a discussion :-) Have a nice weekend and... happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

2 1

[uyuni-users] Thanks for the first Uyuni Community Open Hour!
by Jochen Breuer 29 May '20

29 May '20

Hi list! Many thanks to everybody who showed up to the very first Uyuni Community Open Hour! I counted at least 40 people! This clearly shows that there is more than enough demand to make this a regular thing and we'd be delighted to see you again in four weeks to continue and deepen the discussions! We'll make a calendar appointment available very soon, so that you won't miss it and there won't be timezone conversion issues again! Also we'd like to know if you'd be interested in us recording the meeting, so that you'd be able to revisit the discussions later or watch it if you weren't able to make it. Pics or it didn't happen!? Here we go! ;D https://i.imgur.com/BHNZWWu.png Have a nice weekend everybody! Jochen -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer -- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org

2 1

[uyuni-users] Ansible Role for installing and configuring Uyuni
by Stankowic, Christian 29 May '20

29 May '20

Hi community, I'm working as a consultant and pretty often I need to install Uyuni or SUSE Manager on customer systems. A lot of my customers use Ansible and so I decided to create a role for installing and configuring it. I know SUSE focusses heavily on Salt - but maybe somebody also needs to install and configure Uyuni via Ansible. I'd love to hear your thoughts and feedback: https://galaxy.ansible.com/stdevel/uyuni I successfully tested it with the latest Uyuni and SUSE Manager versions: some features such as Proxy configuration are planned for the future. Best wishes, Christian.

2 1

[uyuni-users] spacewalk-repo-sync - repomd.xml
by Nuno Higgs 29 May '20

29 May '20

Hello all. I've recently came over form spacewalk to suse manager, and found an issue, regarding spacewalk-repo-sync, because some of my inhouse software providers do not sign their repomd.xml file: # spacewalk-repo-sync --channel inhousechannel 06:42:48 ====================================== 06:42:48 | Channel: inhousechannel 06:42:48 ====================================== 06:42:48 Sync of channel started. Preparing custom SSL CAPATH at /var/cache/rhn/reposync/.ssl-certs/1 Retrieving repository 'inhousechannel' metadata ----------------------------------------------------------------[] Warning: File 'repomd.xml' from repository 'inhousechannel' is unsigned. Note: Signing data enables the recipient to verify that no modifications occurred after the data were signed. Accepting data with no, wrong or unknown signature can lead to a corrupted system and in extreme cases even to a system compromise. Note: File 'repomd.xml' is the repositories master index file. It ensures the integrity of the whole repo. Warning: We can't verify that no one meddled with this file, so it might not be trustworthy anymore! You should not continue unless you know it's safe. File 'repomd.xml' from repository 'inhousechannel' is unsigned, continue? [yes/no] (no): If i press y, the sync will occur, but i was wondering if there is a flag i can pass for the missing xml signature being ignored? I know that is a BAD security error to do so, but at the present i really do not have any choice. Can you help me please? Thanks Nuno

5 11

[uyuni-users] Update notice CESA-2019:2079 (from susemanager:centos7-x86_64-updates) is broken, or a bad duplicate
by Bidault, Philippe 27 May '20

27 May '20

Hi all, On a CentOS 7 server registered in Uyuni (2020.05), I have this: # yum check-updates Loaded plugins: fastestmirror, susemanagerplugin Loading mirror speeds from cached hostfile Update notice CESA-2019:2079 (from susemanager:centos7-x86_64-updates) is broken, or a bad duplicate, skipping. You should report this problem to the owner of the susemanager:centos7-x86_64-updates repository. To help pinpoint the issue, please attach the output of "yum updateinfo --verbose" to the report. The issue seems to come from the fact that this errata has been published on 2 repos: spacecmd {SSM:0}> errata_details CESA-2019:2079 Name: CESA-2019:2079 Product: CentOS Linux Type: Security Advisory Issue Date: 2/6/20 ... Affected Channels ----------------- centos7-x86_64 centos7-x86_64-updates There is an endless discussion over the years regarding this issue here: https://bugzilla.redhat.com/show_bug.cgi?id=1203963 Does somebody found a workaround about it ? Could be good to have Uyuni checking the duplicate erratas among all the channels belonging to the same parent, and automatically skip them. And BTW, is there a plan to have Uyuni managing the erratas of .DEB and .RPM OS families to avoid to use third-party scripts to inject them in Uyuni ? Thanks ! Regards, Philippe. Philippe Bidault | Unix Engineer Getronics ________________________________ M. 34617301667 | E. Philippe.Bidault(a)Getronics.com | W. www.getronics.com [cid:M17520GetronicsConnectingPossibilitiesE-Sig425x204_e1803ca0-99a5-4a65-abd8-074c86bf11aa.png]<http://www.getronics.com/> <http://www.linkedin.com/company/2077785>[cid:LinkedIn_4aeb630a-f385-4f22-927e-31323d2554b8.png]<https://www.linkedin.com/company/2077785> [cid:Twitter_6c9cce61-b2e3-49d4-991c-e799d031f1ae.png] <https://twitter.com/Getronics> <http://twitter.com/Getronics> [cid:Youtube_5150f807-4ba8-46a3-bbbf-038ccfdc2793.png] <https://www.youtube.com/user/getronicsonline?feature=results_main> <http://www.youtube.com/user/getronicsonline?feature=results_main> sign-info <http://www.getronics.com/knowledge-share/news-and-events/ovum.php#sthash.cb…> Getronics CMC Service Desk Iberia S.L - VAT No:S.L.: B66686262. Registered Office - Getronics CMC Service Desk Iberia S.L, C/Rosselloi, Porcel, 21 planta 11, 08016 Barcelona, Spain. The information transmitted is intended only for use by the addressee and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of it, or the taking of any action in reliance upon this information by persons and/or entities other than the intended recipient is prohibited. If you received this in error, please inform the sender and/or addressee immediately and delete the material. Thank you. Legal disclaimer: http://www.getronics.com/legal/

2 1

[uyuni-users] Uyuni Community Hours 29.05.2020
by Pau Garcia Quiles 26 May '20

26 May '20

Hello Uyuni Community Hours Fri, May 29, 2020 3:00 PM - 4:00 PM (CEST) Please join my meeting from your computer, tablet or smartphone. https://www.gotomeet.me/pagarcia/uyuni-community-hours You can also dial in using your phone. United States: +1 (646) 749-3129<tel:+16467493129,,446874869#> Access Code: 446-874-869 More phone numbers Australia: +61 2 9087 3604<tel:+61290873604,,446874869#> Austria: +43 7 2081 5427<tel:+43720815427,,446874869#> Belgium: +32 28 93 7018<tel:+3228937018,,446874869#> Brazil: +55 21 3500-3941<tel:+552135003941,,446874869#> Bulgaria: +359 2 906 0605<tel:+35929060605,,446874869#> Canada: +1 (647) 497-9391<tel:+16474979391,,446874869#> Chile: +56 2 3214 9680<tel:+56232149680,,446874869#> Colombia: +57 1 600 9953<tel:+5716009953,,446874869#> Czech Republic: +420 2 55 71 95 02<tel:+420255719502,,446874869#> Denmark: +45 43 31 47 82<tel:+4543314782,,446874869#> Finland: +358 923 17 0568<tel:+358923170568,,446874869#> France: +33 170 950 594<tel:+33170950594,,446874869#> Germany: +49 721 9881 4161<tel:+4972198814161,,446874869#> Greece: +30 21 0 300 2583<tel:+302103002583,,446874869#> Hungary: +36 1 933 3699<tel:+3619333699,,446874869#> Ireland: +353 16 572 651<tel:+35316572651,,446874869#> Israel: +972 3 376 3070<tel:+97233763070,,446874869#> Italy: +39 0 247 92 13 01<tel:+390247921301,,446874869#> Luxembourg: +352 34 2080 9219<tel:+3523420809219,,446874869#> Malaysia: +60 3 7724 4059<tel:+60377244059,,446874869#> Mexico: +52 55 3687 7278<tel:+525536877278,,446874869#> Netherlands: +31 207 941 377<tel:+31207941377,,446874869#> New Zealand: +64 9 280 6302<tel:+6492806302,,446874869#> Norway: +47 21 93 37 51<tel:+4721933751,,446874869#> Panama: +507 308 4334<tel:+5073084334,,446874869#> Peru: +51 1 642 9424<tel:+5116429424,,446874869#> Romania: +40 31 780 1158<tel:+40317801158,,446874869#> South Africa: +27 11 259 4924<tel:+27112594924,,446874869#> Spain: +34 932 75 2004<tel:+34932752004,,446874869#> Sweden: +46 853 527 827<tel:+46853527827,,446874869#> Switzerland: +41 435 5015 61<tel:+41435501561,,446874869#> Turkey: +90 212 900 4807<tel:+902129004807,,446874869#> United Kingdom: +44 330 221 0088<tel:+443302210088,,446874869#> Join from a video-conferencing room or system. Dial in or type: 67.217.95.2 or inroomlink.goto.com Meeting ID: 446 874 869 Or dial directly: 446874869(a)67.217.95.2 or 67.217.95.2##446874869 New to GoToMeeting? Get the app now and be ready when your first meeting starts: https://global.gotomeeting.com/install/446874869 Thank you Pau Garcia Quiles SUSE Manager Product Owner & Technical Project Manager SUSE Software Solutions Spain

2 2

[uyuni-users] Unpublished patches: is anyone using this feature?
by Silvio Moioli 26 May '20

26 May '20

Dear Uyuni community, I am writing because we are considering to drop one feature before the next version, that is the ability to create unpublished patches. Reasons are that, as of now, it seems to be obsoleted and unused, and its presence makes it more difficult to improve the codebase in other aspects (case in point is performance of channel management). Background: Uyuni allows users to create their own patches/errata (via WebUI or API). After a patch is created, it can be published or left unpublished[1]. When a patch is left unpublished, it is not part of any channel so it will just not be visible to any client. At some point users can publish an unpublished patch, and at that moment it will be seen normally by clients that have corresponding channels attached. In the vast majority of use cases, both the documentation and the Web UI assume that any "patch" is in fact a "published patch" - unless otherwise noted. The unpublished errata mechanism has been created very long ago (the earliest trace we found is 2002), when lifecycle tools did not exist at all. Today, instead of creating an unpublished patch, it would be advisable to use a regular (published) patch to a test channel instead - the Content Lifecycle Management feature for instance makes it easy to promote it once it has been tested successfully. Testing is just impossible with unpublished errata, which makes us believe the whole mechanism is basically redundant as of today. We would like to know if any of you uses this feature actively or can point out cases we haven't thought about so far. Unless we get a valid case in this thread, we will most probably proceed removing the feature and cleaning up the corresponding codebase soon, and that will open the door to further optimizations around channel management we hope to ship soon. Thanks! [1] feature is documented here: https://www.uyuni-project.org/uyuni-docs/uyuni/client-configuration/patch-m… https://www.uyuni-project.org/uyuni-docs/uyuni/reference/patches/manage-pat… https://www.uyuni-project.org/uyuni-docs/uyuni/reference/patches/clone-patc… Regards, -- Silvio Moioli SUSE Manager Development Team -- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org

1 0

[uyuni-users] Uyuni Community Hours?
by Pau Garcia Quiles 26 May '20

26 May '20

Hello We are considering starting Uyuni Community Hours, open to the public. If you think it's an interesting idea, please complete this survey: https://bit.ly/2LxqMy0 Thank you Pau Garcia Quiles SUSE Manager Product Owner & Technical Project Manager SUSE Software Solutions Spain

1 1

[uyuni-users] Proxying Prometheus exporters
by Witek Bedyk 26 May '20

26 May '20

Hello everyone, we're planning to simplify the monitoring operations of systems which are running behind some kind of network barrier (e.g. firewall, NAT) and would like to hear what are your requirements and expectations. Prometheus architecture requires that all monitored targets are accessible from the server via TCP. The monitored data is most commonly collected via exporters which expose the measurements on dedicated ports. It implies that multiple ports have to be open on the firewall [1] which in some cases is not desired. To simplify the setup we're considering installing a reverse proxy on the managed system. We've got several options: 1. nginx or other general purpose web proxy server It is the most commonly used and most mature solution. The main concern we have here is that the users would possibly want to run nginx for own applications as well which would create a risk of breaking the configuration. 2. Exporter Exporter [2] It is a dedicated Prometheus reverse proxy. Ergo, the above problem is addressed. 3. PushProx [3] Follows a different design than the above two with proxy and client installed on both sides of the network barrier. It allows to keep all the configuration on the server side. The project is still work in progress but has a charm of not requiring any ingress ports to be open. I'd be happy to hear what are the expectations of the users and which of the described solutions would address your needs best. Thanks for your feedback Witek [1] https://www.uyuni-project.org/uyuni-docs/uyuni/administration/monitoring.ht… [2] https://github.com/QubitProducts/exporter_exporter [3] https://github.com/prometheus-community/PushProx -- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org

1 0

[uyuni-users] [IMPORTANT] Uyuni 2020.05 does not update all packages on the Server (manual step required)
by Julio González Gil 25 May '20

25 May '20

Hi everyone. We got reports at the uyuni-users that some packages, namely "spacewalk- backend-*" and "python3-psycopg2" were not being updated. The reason is that we need a temporary vendor change for "python3-psycopg2" as we provide an updated version for the repository syncing performance improvements, that should arrive to openSUSE Leap 15.1 in the following weeks. Sadly this information was missing at the original release notes, so we apologize for that. To fix it, after running "zypper update" you will need force the vendor change with > zypper in python3-psycopg2-2.8.4-2.1.uyuni.x86_64 Then update again again, so the spacewalk-backend subpackages are updated: > zypper update If you already updated to 2020.05, just stop the services with spacewalk- service, run the two steps above, and then start the services again. All other packages such as "lucene" can be ignored. The release notes at the website [1] are already updated (because of the release procedure, we can update the RPM packages for Stable), and we did an announcement at the website. A tweet at Twitter will follow soon. Thank you very much to Philippe Bidault and Cristian Gherman for reporting the issue and helping testing the fix. [1] https://www.uyuni-project.org/doc/2020.05/release-notes-uyuni-server.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

[uyuni-users] grafana-server does not start
by Martin Willisegger 25 May '20

25 May '20

Hello all If anyone else has a problem with the Grafana Server Update on openSuSE 15.1: grafana-6.7.3-4.1.uyuni.x86_64 The error message is: grafana-server.service: Failed to load environment files: No such file or directory Then copy the file /etc/sysconfig/grafana-server from one of the last snapshots to /etc/sysconfig/grafana-server. This file is missing after update. It can also be helpful to start the binary from the command line, as there are some updates: # /usr/sbin/grafana-server --config=/etc/grafana/grafana.ini -homepath=/usr/share/grafana Best regards Martin -- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org

2 2

[uyuni-users] Packages being kept-back after upgrade of Uyuni
by Bidault, Philippe 24 May '20

24 May '20

Hi all, I have updated the uyuni servers+proxies to 2020.05 (zypper update), and for now, so far so good. The only thing I am not really sure to understand, is the presence of newest packages not being updated and being kept-back: On the proxies, there is only one: uyuni_proxy:~ # zypper info Uyuni-Proxy-release Refreshing service 'spacewalk'. Retrieving repository 'Uyuni Client Tools for openSUSE Leap 15.1 (x86_64)' metadata ............................................................................................[done] Retrieving repository 'openSUSE Leap 15.1 (x86_64)' metadata ...................................................................................................................[done] Retrieving repository 'openSUSE Leap 15.1 Updates (x86_64)' metadata ...........................................................................................................[done] Retrieving repository 'Uyuni Proxy Stable for openSUSE Leap 15.1 (x86_64)' metadata ............................................................................................[done] Loading repository data... Reading installed packages... Information for package Uyuni-Proxy-release: -------------------------------------------- Repository : Uyuni Proxy Stable for openSUSE Leap 15.1 (x86_64) Name : Uyuni-Proxy-release Version : 2020.01-75.3.uyuni Arch : x86_64 Vendor : obs://build.opensuse.org/systemsmanagement:Uyuni Support Level : Level 3 Installed Size : 1.4 KiB Installed : Yes Status : out-of-date (version 2020.01-72.1.uyuni installed) Source package : Uyuni-Proxy-release-2020.01-75.3.uyuni.src Summary : Uyuni Proxy 2020.01 Description : Uyuni Proxies extend large and/or geographically dispersed Uyuni environments to reduce load on the Uyuni Server, lower bandwidth needs, and provide faster local updates. But on the Uyuni servers, there are 18: The following 18 package updates will NOT be installed: Uyuni-Server-release lucene python3-psycopg2 spacewalk-backend spacewalk-backend-app spacewalk-backend-applet spacewalk-backend-config-files spacewalk-backend-config-files-common spacewalk-backend-config-files-tool spacewalk-backend-iss spacewalk-backend-iss-export spacewalk-backend-package-push-server spacewalk-backend-server spacewalk-backend-sql spacewalk-backend-sql-postgresql spacewalk-backend-tools spacewalk-backend-xml-export-libs spacewalk-backend-xmlrpc Could you please confirm that this is a normal behaviour, due to perhaps version dependencies coming from the Uyuni zypper pattern? If yes, I guess that I should not see this update available on all the proxies in the Uyuni web console ? Latest Package Installed Package Uyuni-Proxy-release-2020.01-75.3.uyuni.x86_64 Uyuni-Proxy-release-2020.01-72.1.uyuni.x86_64 Thanks, Regards, Philippe. Philippe Bidault | Unix Engineer Getronics ________________________________ M. 34617301667 | E. Philippe.Bidault(a)Getronics.com | W. www.getronics.com [cid:M17520GetronicsConnectingPossibilitiesE-Sig425x204_e1803ca0-99a5-4a65-abd8-074c86bf11aa.png]<http://www.getronics.com/> <http://www.linkedin.com/company/2077785>[cid:LinkedIn_4aeb630a-f385-4f22-927e-31323d2554b8.png]<https://www.linkedin.com/company/2077785> [cid:Twitter_6c9cce61-b2e3-49d4-991c-e799d031f1ae.png] <https://twitter.com/Getronics> <http://twitter.com/Getronics> [cid:Youtube_5150f807-4ba8-46a3-bbbf-038ccfdc2793.png] <https://www.youtube.com/user/getronicsonline?feature=results_main> <http://www.youtube.com/user/getronicsonline?feature=results_main> sign-info <http://www.getronics.com/knowledge-share/news-and-events/ovum.php#sthash.cb…> Getronics CMC Service Desk Iberia S.L - VAT No:S.L.: B66686262. Registered Office - Getronics CMC Service Desk Iberia S.L, C/Rosselloi, Porcel, 21 planta 11, 08016 Barcelona, Spain. The information transmitted is intended only for use by the addressee and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of it, or the taking of any action in reliance upon this information by persons and/or entities other than the intended recipient is prohibited. If you received this in error, please inform the sender and/or addressee immediately and delete the material. Thank you. Legal disclaimer: http://www.getronics.com/legal/

3 7

[uyuni-users] grain item match
by Tobias Crefeld 22 May '20

22 May '20

Hi, at Salt's top.sls an expression like the following one is running fine: base: 'osfinger:SLES-15': - match: - common.ad.ad-sles15 meaning that only on a minion running SLES-15 the SLS common/ad/ad-sles15.sls will get executed. Trying to implement something similar using Uyuni's WebUI in order to create a "Configuration file" (SLS) doesn't work: ServerSpecial: 'host:server01': - match: grain - file.managed: - name: .... (I leave out the rest as it doesn't cause the trouble) My intention is that "file managing" only happens if the hostname is "server01". During deployment the logfile minion says: "State 'host:server01.__call__' was not found in SLS 'manager_org_1.SLES15-WF-SrvSpez-SLS' Reason: 'host:server01.__call__' is not available. I have the vague idea that this happens because this grain-item-matching is only allowed at top.sls but as there is no access to top.sls using Uyuni's WebUI I wonder how this could be done with the WebUI? Any idea? -- Gruss, Tobias Crefeld. xmpp (no email): crefeld(a)xabber.de -- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org

3 3

[uyuni-users] Uyuni 2020.05 is released!
by Julio González Gil 21 May '20

21 May '20

Hello everyone! We are happy to announce the immediate availability of Uyuni 2020.05 At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2020.05, including the release notes, documentation, requirements and setup instructions. This is the list of highlights for this release: * Repository syncing performance improvements * Image profiles key-value pairs supported as arguments for Docker build * Service pack migrations: run a real migration after a successful dry-run Please check the release notes for full details. Remember that Uyuni will follow a rolling release planning, so the next version will contain bugfixes for this one and any new features. There will be no maintenance of 2020.05 As always, we hope you will enjoy Uyuni 2020.05 and invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/pages/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

[uyuni-users] Query all System History Event information
by Javier.Flores＠gmz.migros.ch 14 May '20

14 May '20

Hi all We have State Channels and run them once a day to ensure everything is set up to our guidelines. If one of those events fails or even if it is successful but changes had to be made, I want to know. I can get failed actions using spacecmd schedule_listfailed and more details with schedule_getoutput. However, I haven't been able to identify events that were successful, but had to do changes on the system. The needed information is available in the WebUI in the System History Event (Systems > SystemXY > Events > History > EventXY). First there are the details of the event: > This action will be executed after 5/7/20 10:16:43 AM CEST > This action's status is: Completed. > The client completed this action on 5/7/20 10:16:48 AM CEST > Client execution returned Then there is a box which says: > Successfully applied state(s): [custom] Then comes a second box which contains the information I need. It looks something like this: Results: ---------- ID: /etc/environment_TERM Function: file.blockreplace Name: /etc/environment Result: true Comment: Changes were made Started: 10:16:48.450723 Duration: 4.14 SLS: manager_org_2.base_environment Changed: diff: "--- +++ @@ -4,4 +4,5 @@ # Syntax: simple \"KEY=VAL\" pairs on seperate lines # # BLOCK TOP : salt managed zone. Do not edit!! +TERM=xterm \ \ # BLOCK BOTTOM : end of salt managed zone " I also tried to get this information by using the API (system.listSystemEvents() and schedule.listFailedSystems()) but I can't get more than the details about the action and the message from the first box. Any suggestions how I could get to this information by CLI or the API? I tried with Uyuni 4.0.2 and SUSE Manager 4.0.4. Regards, Javier

3 3

Re: [uyuni-users] Uyuni at the openSUSE Virtual Summit (May 1st)
by Tim Shaw 06 May '20

06 May '20

Will there be a recording of this talk available at some point for those of us who missed the event? Thanks T

2 1

[uyuni-users] Virtual Host Manager - and rights
by Tim Shaw 04 May '20

04 May '20

I discovered - although it took me a while - that it is possible for an organization administrator to create virtual host managers in the web interface but not to trigger a refresh of them - for which you need to have the Uyuni Administrator (SUSE Manager Administrator) role If a non uyuni administrator attempts to do this a Server error - check the log files message is displayed and there is nothing in the gatherer log which is where I expected to see the error. Eventually I realised that there was something else wrong and checked the rhn_we_ui log and saw : Error during transaction. Rolling back com.redhat.rhn.common.validator.ValidatorException: ERRORS: The user tim is the not a Uyuni Administrator. Only users with Uyuni Administra tor role can grant or revoke Uyuni Administrator roles from other users. It would be helpful if this message could be delivered to the web ui to tell the user it's a rights issue....or better still give the rights to do the refresh to organisation administrators... T *Please note I am not normally in the office on Mondays or Fridays* ___________________________________________________________ TIM SHAW - Deputy Director - Network Services Medical Sciences Division - University of Oxford email : tim.shaw(a)medsci.ox.ac.uk tel : +44 (0)1865 289480 -- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org

2 1

[uyuni-users] Conflicts with EPEL8 repository on CentOS8
by Tim Shaw 01 May '20

01 May '20

Hello Uyuni version 2020.03 I installed a CentOS8 salt client and all was well until I added the EPEL 8 repo which contains alternative versions of software which conflict with those on the Uyuni client tools for CentOS8 channel: Error: Problem: package python3-salt-2019.2.3-17.2.uyuni.x86_64 conflicts with python3-tornado >= 5 provided by python3-tornado-6.0.2-1.el8.x86_64 - cannot install the best update candidate for package python3-tornado-4.2.1-1.12.uyuni.x86_64 - cannot install the best update candidate for package python3-salt-2019.2.3-17.2.uyuni.x86_64 I have: python3-tornado-4.2.1-1.12.uyuni.x86_64 but with EPEL 8 available I am offered an upgrade to python3-tornado-6.0.2-1.el8.x86_64 I have worked around this using : yum versionlock add python3-tornado ..but it's obviously a bit of a mess. Any ideas about how this is best solved ? T *Please note I am not normally in the office on Mondays or Fridays* ___________________________________________________________ TIM SHAW - Deputy Director - Network Services Medical Sciences Division - University of Oxford email : tim.shaw(a)medsci.ox.ac.uk tel : +44 (0)1865 289480 -- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org

2 1