May 2020 - ARCHIVED: Uyuni Users - openSUSE Mailing Lists

[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