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
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
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
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
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
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
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
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
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
Hello
Whenever a date is displayed in the Uyuni Web GUI it is always of the format m/d/y. Is this configurable anywhere? I see user preferences allow for selecting a time zone but not a date format. Is it a system preference or is it hard-coded somewhere?
Not being American, I'd obviously like to change it...
Many thanks
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
