- ARCHIVED: Uyuni Users

[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

[uyuni-users] Uyuni at the openSUSE Virtual Summit (May 1st)
by Pau Garcia Quiles 30 Apr '20

30 Apr '20

Hello Today 01.05.2020 at 15:00 UTC, I will be giving a 30-min introductory talk about Uyuni at the openSUSE Virtual Summit 2020. Topics: where we are, what's next and opportunities for the community. https://events.opensuse.org/conferences/oSvirtsmt/program/proposals/3059 Thank you Pau Garcia Quiles SUSE Manager Product Owner & Technical Project Manager SUSE Software Solutions Spain

1 0

[uyuni-users] hardware refresh/applying default states broken with 2020.04
by Stefan Bogner 30 Apr '20

30 Apr '20

Moin, I am currently playing with 2020.04 and registered a bunch of Ubuntu 18 Clients. Hardware refresh and applying the default states doesn't seem to be working from uyuni. This is what I get: 2020-04-30 09:17:20,334 [salt-event-thread-4] ERROR com.suse.manager.reactor.PGEventListener - Unexpected exception while executing a MessageAction java.lang.NullPointerException (full error log attached) Running the salt states on the CLI (hardware.profileupdate etc) is working fine, so the issue really is when communicating back to uyuni. Any idea? Also, I have another issue. The state package.disablelocalrepos shows changes for all enabled repos, but it only disables the ones in /etc/apt/sources.list.d, the ones in /etc/apt/sources.list are not disabled, even though the state says it should have been done. Thanks Stefan

1 2

[uyuni-users] no tasks tasks were executed and no patches deployed
by Haupt, Torsten 30 Apr '20

30 Apr '20

Hi, obviously since update to 2020.04 no tasks were executed and no patches were deployed (patch download is intiated by an external script). I got this e-mail: Taskomatic bunch minion-action-executor-bunch was scheduled to run within the minion-action-executor-539849 schedule. Subtask minion-action-executor failed. For more information check /var/log/rhn/tasko/sat/minion-action-executor-bunch/minion-action-executor_4416112_err. The mentioned file contains: 2020-04-28 13:30:11,058 [DefaultQuartzScheduler_Worker-9] ERROR com.redhat.rhn.taskomatic.task.MinionActionExecutor - Executing a task threw an exception: org.hibernate.exception.SQLGrammarException 2020-04-28 13:30:11,063 [DefaultQuartzScheduler_Worker-9] ERROR com.redhat.rhn.taskomatic.task.MinionActionExecutor - Message: could not extract ResultSet 2020-04-28 13:30:11,063 [DefaultQuartzScheduler_Worker-9] ERROR com.redhat.rhn.taskomatic.task.MinionActionExecutor - Cause: org.postgresql.util.PSQLException: ERROR: relation "rhnactionvirtpoolrefresh" does not exist Position: 2818 2020-04-28 13:30:11,064 [DefaultQuartzScheduler_Worker-9] ERROR com.redhat.rhn.taskomatic.task.MinionActionExecutor - Stack trace:org.hibernate.exception.SQLGrammarException: could not extract ResultSet at org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:106) at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:42) at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:113) at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:99) at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.extract(ResultSetReturnImpl.java:69) at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.getResultSet(AbstractLoadPlanBasedLoader.java:419) at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeQueryStatement(AbstractLoadPlanBasedLoader.java:191) at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:121) at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:86) at org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:188) at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4269) at org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:511) at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:481) at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:222) at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:281) at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:124) at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:92) at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1257) at org.hibernate.internal.SessionImpl.access$1900(SessionImpl.java:207) at org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.doLoad(SessionImpl.java:2874) at org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2848) at org.hibernate.internal.SessionImpl.get(SessionImpl.java:1093) at com.redhat.rhn.domain.action.ActionFactory.lookupById(ActionFactory.java:561) at com.redhat.rhn.taskomatic.task.MinionActionExecutor.execute(MinionActionExecutor.java:81) at com.redhat.rhn.taskomatic.task.RhnJavaJob.execute(RhnJavaJob.java:88) at com.redhat.rhn.taskomatic.TaskoJob.execute(TaskoJob.java:199) at org.quartz.core.JobRunShell.run(JobRunShell.java:202) at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573) Caused by: org.postgresql.util.PSQLException: ERROR: relation "rhnactionvirtpoolrefresh" does not exist Position: 2818 at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2510) at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2245) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:311) at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:447) at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:368) at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:159) at org.postgresql.jdbc.PgPreparedStatement.executeQuery(PgPreparedStatement.java:109) at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeQuery(NewProxyPreparedStatement.java:249) at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.extract(ResultSetReturnImpl.java:60) ... 23 more And there are a lot of these files. In the journal I found some java errors, like: Apr 28 13:19:08 smduyuni taskomatic[2926]: INFO: Initializing c3p0 pool... com.mchange.v2.c3p0.ComboPooledDataSource [ acquireIncrement -> 3, acquireRetryAttempts -> 30, acquireRetryDelay -> 1000, autoCommit> Apr 28 13:19:08 smduyuni taskomatic[2926]: Apr. 28, 2020 1:19:08 NACHM. com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource getPoolManager Apr 28 13:19:04 smduyuni rhn-search[2925]: ... 1 more Apr 28 13:19:04 smduyuni rhn-search[2925]: at org.quartz.core.JobRunShell.run(JobRunShell.java:202) Apr 28 13:19:04 smduyuni rhn-search[2925]: at com.redhat.satellite.search.scheduler.tasks.IndexPackagesTask.execute(IndexPackagesTask.java:64) Apr 28 13:19:04 smduyuni rhn-search[2925]: at com.redhat.satellite.search.scheduler.tasks.IndexPackagesTask.getPackages(IndexPackagesTask.java:156) Apr 28 13:19:04 smduyuni rhn-search[2925]: at com.redhat.satellite.search.db.Query.loadList(Query.java:61) Apr 28 13:19:04 smduyuni rhn-search[2925]: at org.apache.ibatis.session.defaults.DefaultSqlSession.selectList(DefaultSqlSession.java:98) Apr 28 13:19:04 smduyuni rhn-search[2925]: at org.apache.ibatis.session.defaults.DefaultSqlSession.selectList(DefaultSqlSession.java:104) Apr 28 13:19:04 smduyuni rhn-search[2925]: at org.apache.ibatis.executor.CachingExecutor.query(CachingExecutor.java:81) Apr 28 13:19:04 smduyuni rhn-search[2925]: at org.apache.ibatis.executor.CachingExecutor.query(CachingExecutor.java:105) Apr 28 13:19:04 smduyuni rhn-search[2925]: at org.apache.ibatis.executor.BaseExecutor.query(BaseExecutor.java:132) Apr 28 13:19:04 smduyuni rhn-search[2925]: at org.apache.ibatis.executor.BaseExecutor.queryFromDatabase(BaseExecutor.java:259) Apr 28 13:19:04 smduyuni rhn-search[2925]: at org.apache.ibatis.executor.SimpleExecutor.doQuery(SimpleExecutor.java:57) Apr 28 13:19:04 smduyuni rhn-search[2925]: at org.apache.ibatis.executor.statement.RoutingStatementHandler.query(RoutingStatementHandler.java:70) Apr 28 13:19:04 smduyuni rhn-search[2925]: at org.apache.ibatis.executor.statement.PreparedStatementHandler.query(PreparedStatementHandler.java:57) Apr 28 13:19:04 smduyuni rhn-search[2925]: at org.apache.ibatis.executor.resultset.DefaultResultSetHandler.handleResultSets(DefaultResultSetHandler.java:152) Apr 28 13:19:04 smduyuni rhn-search[2925]: at org.apache.ibatis.executor.resultset.DefaultResultSetHandler.handleResultSet(DefaultResultSetHandler.java:234) Apr 28 13:19:04 smduyuni rhn-search[2925]: at org.apache.ibatis.executor.resultset.DefaultResultSetHandler.handleRowValues(DefaultResultSetHandler.java:264) Apr 28 13:19:04 smduyuni rhn-search[2925]: at org.apache.ibatis.executor.resultset.DefaultResultSetHandler.handleRowValuesForSimpleResultMap(DefaultResultSetHandler.java:289) Apr 28 13:19:04 smduyuni rhn-search[2925]: at org.apache.ibatis.executor.resultset.DefaultResultSetHandler.getRowValue(DefaultResultSetHandler.java:334) Apr 28 13:19:04 smduyuni rhn-search[2925]: at org.apache.ibatis.executor.resultset.DefaultResultSetHandler.applyAutomaticMappings(DefaultResultSetHandler.java:410) Apr 28 13:19:04 smduyuni rhn-search[2925]: at org.apache.ibatis.reflection.MetaObject.findProperty(MetaObject.java:76) Apr 28 13:19:04 smduyuni rhn-search[2925]: at org.apache.ibatis.reflection.wrapper.BeanWrapper.findProperty(BeanWrapper.java:59) Apr 28 13:19:04 smduyuni rhn-search[2925]: at org.apache.ibatis.reflection.MetaClass.findProperty(MetaClass.java:63) Apr 28 13:19:04 smduyuni rhn-search[2925]: at org.apache.ibatis.reflection.MetaClass.findProperty(MetaClass.java:56) Apr 28 13:19:04 smduyuni rhn-search[2925]: at java.base/java.lang.StringBuilder.toString(StringBuilder.java:448) Apr 28 13:19:04 smduyuni rhn-search[2925]: at java.base/java.lang.StringLatin1.newString(StringLatin1.java:715) Apr 28 13:19:04 smduyuni rhn-search[2925]: Caused by: java.lang.OutOfMemoryError: Java heap space Apr 28 13:19:04 smduyuni rhn-search[2925]: at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573) Apr 28 13:19:04 smduyuni rhn-search[2925]: at org.quartz.core.JobRunShell.run(JobRunShell.java:213) Apr 28 13:19:04 smduyuni rhn-search[2925]: org.quartz.SchedulerException: Job threw an unhandled exception. [See nested exception: java.lang.OutOfMemoryError: Java heap space] Apr 28 13:19:04 smduyuni rhn-search[2925]: Caused by: java.lang.OutOfMemoryError: Java heap space Greets Torsten -- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org

4 6

[uyuni-users] Question about channels
by Martin Willisegger 28 Apr '20

28 Apr '20

Hello all There is one thing I don't really understand about channels. I created a channel called "opensuse_leap_15.1" with all repositories connected to a normal openSuSE Leap 15.1 system (openSUSE-Leap-15.1-1, openSUSE-Leap-15.1-Non-Oss, openSUSE-Leap-15.1-Update, openSUSE-Leap-15.1-Update-Non-Oss). Then I created a child channel called "opensuse_leap_15.1_uyuni" with the uyuni repository (uyuni-server-stable). After all channels are synced, I create an Activation Key "openSuSE LEAP 15.1 Uyuni Server" with base channel "opensuse_leap_15.1" and Child Channel "opensuse_leap_15.1_uyuni". After that I use "Bootstrapping" to add my uyuni Server to the system list. The uyuni Server is now displayed in System overview. The connected repositories are: uyuni:/var/spacewalk # zypper lr -E Repository priorities are without effect. All enabled repositories share the same priority. # | Alias | Name | Enabled | GPG Check | Refresh ---+--------------------------------------+--------------------------+---------+-----------+-------- 12 | susemanager:opensuse_leap_15.1 | openSuSE LEAP 15.1 | Yes | ( p) Yes | Yes 13 | susemanager:opensuse_leap_15.1_uyuni | openSuSE LEAP 15.1 Uyuni | Yes | ( p) Yes | Yes Seems to be ok in my eyes - but now I've discovered an unpleasant side effect. In zypper.log I see this messages: 2020-04-25 15:01:34 <1> uyuni(31866) [zypper++] Summary.cc(readPool):144 <uninstall> I_Ts_o(829)patterns-uyuni_server-2020.04-1.1.uyuni.x86_64(@System) 2020-04-25 15:01:34 <1> uyuni(31866) [zypper++] Summary.cc(readPool):144 <uninstall> I_Ts_ou(1162)python3-suseRegisterInfo-4.1.1-1.1.uyuni.noarch(@System) 2020-04-25 15:01:34 <1> uyuni(31866) [zypper++] Summary.cc(readPool):144 <uninstall> I_Ts_o(1254)spacewalk-backend-tools-4.1.7-1.3.uyuni.noarch(@System) 2020-04-25 15:01:34 <1> uyuni(31866) [zypper++] Summary.cc(readPool):144 <uninstall> I_Ts_o(1263)spacewalk-common-4.1.3-1.1.uyuni.noarch(@System) 2020-04-25 15:01:34 <1> uyuni(31866) [zypper++] Summary.cc(readPool):144 <uninstall> I_Ts_o(1270)spacewalk-postgresql-4.1.3-1.1.uyuni.noarch(@System) 2020-04-25 15:01:34 <1> uyuni(31866) [zypper++] Summary.cc(readPool):144 <uninstall> I_Ts_o(1273)spacewalk-setup-4.1.4-4.1.uyuni.noarch(@System) 2020-04-25 15:01:34 <1> uyuni(31866) [zypper++] Summary.cc(readPool):144 <uninstall> I_Ts_o(1287)supportutils-plugin-susemanager-4.1.2-1.1.uyuni.noarch(@System) 2020-04-25 15:01:34 <1> uyuni(31866) [zypper++] Summary.cc(readPool):144 <uninstall> I_Tu_ou(1289)suseRegisterInfo-4.1.1-1.1.uyuni.noarch(@System) 2020-04-25 15:01:34 <1> uyuni(31866) [zypper++] Summary.cc(readPool):144 <uninstall> I_Ts_o(1290)susemanager-4.1.10-1.1.uyuni.x86_64(@System) 2020-04-25 15:01:34 <1> uyuni(31866) [zypper++] Summary.cc(readPool):144 <uninstall> I_Ts_o(1296)susemanager-tools-4.1.10-1.1.uyuni.x86_64(@System) 2020-04-25 15:01:34 <1> uyuni(31866) [zypper++] Summary.cc(readPool):144 <uninstall> I_Ts_u(1494)pattern:uyuni_server-2020.04-1.1.uyuni.x86_64(@System) 2020-04-25 15:02:12 <1> uyuni(1545) [libsolv++] PoolImpl.cc(logSat):123 allowuninstall=1, allowdowngrade=0, allownamechange=1, allowarchchange=0, allowvendorchange=0 2020-04-25 15:02:12 <1> uyuni(1545) [zypper++] Summary.cc(readPool):144 <uninstall> I_Ts_ou(764)mgr-push-4.1.1-1.1.uyuni.noarch(@System) 2020-04-25 15:02:12 <1> uyuni(1545) [zypper++] Summary.cc(readPool):144 <uninstall> I_Ts_ou(1103)python3-mgr-push-4.1.1-1.1.uyuni.noarch(@System) 2020-04-25 15:02:12 <1> uyuni(1545) [zypper++] Summary.cc(readPool):144 <uninstall> I_Ts_ou(1159)python3-spacewalk-certs-tools-4.1.7-1.1.uyuni.noarch(@System) 2020-04-25 15:02:12 <1> uyuni(1545) [zypper++] Summary.cc(readPool):144 <uninstall> I_Ts_o(1160)python3-spacewalk-client-tools-4.1.5-1.1.uyuni.noarch(@System) 2020-04-25 15:02:12 <1> uyuni(1545) [zypper++] Summary.cc(readPool):144 <uninstall> I_Ts_ou(1258)spacewalk-certs-tools-4.1.7-1.1.uyuni.noarch(@System) 2020-04-25 15:02:12 <1> uyuni(1545) [zypper++] Summary.cc(readPool):144 <uninstall> I_Tu_o(1259)spacewalk-client-tools-4.1.5-1.1.uyuni.noarch(@System) And in yes the uyuni_server was uninstalled: yuni:/var/spacewalk # zypper in patterns-uyuni_server Loading repository data... Reading installed packages... Resolving package dependencies... The following 16 NEW packages are going to be installed: mgr-push patterns-uyuni_server python3-mgr-push python3-spacewalk-certs-tools python3-spacewalk-client-tools python3-suseRegisterInfo spacewalk-backend-tools spacewalk-certs-tools spacewalk-client-tools spacewalk-common spacewalk-postgresql spacewalk-setup supportutils-plugin-susemanager suseRegisterInfo susemanager susemanager-tools The following NEW pattern is going to be installed: uyuni_server 16 new packages to install. Overall download size: 1.2 MiB. Already cached: 0 B. After the operation, additional 4.7 MiB will be used. Continue? [y/n/v/...? shows all options] (y): n I can reinstall the pattern, but the rpm's will be uninstalled again later. Did I miss something - or is it not possible to add the Uyuni server to the system itself? 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

3 3

[uyuni-users] New SLES15-Client: 4-Signatures public key is not available
by Tobias Crefeld 26 Apr '20

26 Apr '20

Hi, I created a new SLES15-machine with a minimal setup and tried to add it to Uyuni using the "Bootstrapping" function at the WebGUI. Initially it stopped after creating a Salt key but without any error message on the Uyuni-server and obviously without any deoployment on Uyuni or on the client. It turned out that the resolv.conf was missing on the client and so the client wasn't able to start a connection to the Uyuni-server. After creation of the resolv.conf the bootstrapping / registration process automatically continued, including "Apply states" (channels, packages, etc.) - everything seemed fine now. But during installation of the pre-defined package list an error occured during the installation of one package. A manual installation using zypper install fails with the same message: htop-2.2.0-bp150.2.4.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 65176565: NOKEY htop-2.2.0-bp150.2.4.x86_64 (SUSE-PackageHub-15-Standard-Pool for x86_64): Signature verification failed [4-Signatures public key is not available] The repository list looks fine: # zypper lr |egrep '(Standard|Alias)' # | Alias | Name | Enabled | GPG Check | Refresh 13 | susemanager:suse-packagehub-15-x86_64 | SUSE-PackageHub-15-Standard-Pool for x86_64 | Yes | ( p) Yes | Yes Installation of the same package is no problem on other salt-clients using the same channel. Any idea how to fix this (automatically)? -- Regards, 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

2 4

Re: [uyuni-users] Monitoring with Prometheus and Grafana
by Martin Willisegger 23 Apr '20

23 Apr '20

Hello João I used the command from the guide to install prometheus: zypper in golang-github-prometheus-prometheus This "prometheus" related packes are installed: uyuni:/var/log # zypper se --installed -s prometheus Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository ---+----------------------------------------+---------+-------------------+--------+------------------------------------------------ i+ | golang-github-prometheus-alertmanager | package | 0.16.2-lp151.15.1 | x86_64 | Server Monitoring Software (openSUSE_Leap_15.1) i | golang-github-prometheus-node_exporter | package | 0.18.1-1.1.uyuni | x86_64 | uyuni-server-stable i+ | golang-github-prometheus-prometheus | package | 2.7.1-lp151.1.4 | x86_64 | Haupt-Repository i+ | golang-github-prometheus-promu | package | 0.5.0-lp151.6.1 | x86_64 | Server Monitoring Software (openSUSE_Leap_15.1) i | prometheus-client-java | package | 0.3.0-1.2.uyuni | noarch | uyuni-server-stable i | prometheus-exporters-formula | package | 0.5-3.1.uyuni | noarch | uyuni-server-stable i | prometheus-formula | package | 0.2-1.1.uyuni | noarch | uyuni-server-stable i | prometheus-jmx_exporter | package | 0.3.1-3.3.uyuni | noarch | uyuni-server-stable i | prometheus-jmx_exporter-tomcat | package | 0.3.1-3.3.uyuni | noarch | uyuni-server-stableLoading repository data... Best regards, Martin Am 23.04.20 um 10:43 schrieb João Cavalheiro: > Hello Martin, > > In order to use the Service Discovery feature, you have to use the > Prometheus > version provided in the Uyuni Client Tools channel, which has a specific > extension to support this. > > Can you confirm which version you have installed? > > Best regards, > João > > On 22/04/20 22:08, Martin Willisegger wrote: >> Hello everyone >> >> I have just updated my older (4.0.x) uyuni installation on openSuSE >> Leap 15.1 to >> version 2020.04. >> >> Basically everything worked as before after that. I use the >> installation mainly >> for educational purposes, since we just bought a SuSE Manager license >> at work >> and I will have to familiarize myself with it in the future. >> >> I have now tried to set up the monitoring using this guide: >> https://www.uyuni-project.org/uyuni-docs/uyuni/administration/monitoring.ht… >> >> I tried to install the Prometheus service once via zypper and later >> also via the >> Web GUI. The installation worked with both variants, but Prometheus >> will no >> longer start if you enter the configuration as described in the manual. >> >> The problem seems to be this area: >> # Managed systems metrics: >> - job_name: 'mgr-clients' >> uyuni_sd_configs: >> - host: "http://server.url" >> username: "admin" >> password: "admin" >> >> Journalctl then shows the following error after a restart of >> Prometheus and the >> service dies immediately: >> >> Apr 22 22:21:11 uyuni systemd[1]: Started Monitoring system and time >> series >> database. >> -- Subject: Unit prometheus.service has finished start-up >> -- Defined-By: systemd >> -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org

3 3