- ARCHIVED: Uyuni Users

[uyuni-users] API curl example
by Strahil Nikolov 04 Jun '19

04 Jun '19

Hello community, can someone give a short example via curl & xml/json for accessing the API. Sadly my skills in python/perl/ruby are close to 0 . Thanks in advance. Best Regards, Strahil Nikolov -- 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] Feature: Please add opensuse 15.1 to bootstrap
by Strahil Nikolov 25 May '19

25 May '19

Hello Users,Dev, I have modified my '/usr/share/susemanager/mgr_bootstrap_data.py' in order to bootstrap openSUSE Leap 15.1 , but it will be nice if in the next versions we have that out of the box.I haven't tested my modifications, but I will keep you updated. Do you see any issues with my modification? Here is what I got for openSUSE 15.X: openSUSE-Leap-15.0-x86_64' : { 'BASECHANNEL' : 'opensuse_leap15_0-x86_64', 'PKGLIST' : PKGLIST15 + PKGLIST15_NO_Z, 'DEST' : '/srv/www/htdocs/pub/repositories/opensuse/15/0/bootstrap/' }, 'openSUSE-Leap-15.1-x86_64' : { 'BASECHANNEL' : 'opensuse_leap15_1-x86_64', 'PKGLIST' : PKGLIST15 + PKGLIST15_NO_Z, 'DEST' : '/srv/www/htdocs/pub/repositories/opensuse/15/1/bootstrap/' }, Best Regards, Strahil Nikolov -- 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] Feature request: Add missing Debian headers to repository metadata before signing
by Robert Paschedag 23 May '19

23 May '19

Hello Uyuni devel, this is a feature request for sysadmins, managing Debian / Ubuntu systems with Uyuni. Although there has been a lot of work to support Ubuntu / Debian, there is still some major thing missing. Several metadata headers are missing for Debian packages, that causes major issues on Debian / Ubuntu systems. One header is the "Multi-Arch" header, that is missing. This missing header causes packages to be installable over and over again. "apt" does not correctly "get it", that this package is already the newest installed and suggests these packages when searching for updates all the time. Also some dependencies cannot be successfully solved, because of this missing header. So the workaround most Debian / Ubuntu admins are doing right now, is to - sync the data into Uyuni - wait for spacewalk to generate the "Packages.gz" file - start - possibly below - script to add the missing "Multi-Arch" header to the "Packages.gz" file - sign the file Currently, I don't think that there are any efforts to tune the Uyuni database to also support the missing headers of Debian packages. So a further workaround could be to include such a script to add the missing headers "while or after" the "Packages.gz" gets created (or has been created), but before the file gets "signed". This could be added somewhere within the "DebRepositoryWriter.java" file, where the "signing" of the channel starts. First, I only had written a script to only add the "Multi-Arch" header. But this script below adds all headers missing for a packages. For this to work, you - of course - need the original "Packages.gz" file from Debian / Ubuntu with *all* headers present. Think about it. Would be cool, if this part could also be integrated into Uyuni. Just an idea and still used as workaround.... Best regards, Robert #!/usr/bin/env python -tt # Basically, this should only add one major header # 'Multi-Arch' to the Debian Packages file, but now # we add all missing headers. # # This only works correctly, if you are syncing the Debian repos # directly to one channel within Spacewalk or Uyuni # # You also need python-debian (which is installed on # Spacewalk server) to run this script # # Author: Robert Paschedag <robert.paschedag(a)netlution.de> # Version: 20181107 import sys import os from debian.deb822 import * if len(sys.argv) < 3: print "Usage: %s <path_to_unzipped_Packages_from_Spacewalk_Uyuni> <path_to_original_Debian_repo>" % sys.argv[0] sys.exit(1) spacewalk_file = sys.argv[1] original_file = sys.argv[2] if not os.path.isfile(spacewalk_file): print "Error: Inputfile '%s' not available." % spacewalk_file sys.exit(1) if not os.path.isfile(original_file): print "Error: Inputfile '%s' not available." % original_file sys.exit(1) spacewalk_packages = {} original_packages = {} with open(spacewalk_file, 'r') as pkgs: for pkg in Packages.iter_paragraphs(pkgs): spacewalk_packages[pkg['Package'] + pkg['Version'] + pkg['Architecture']] = pkg with open(original_file, 'r') as orig_file: for pkg in Packages.iter_paragraphs(orig_file): p = pkg['Package'] v = pkg['Version'] a = pkg['Architecture'] if spacewalk_packages.has_key(p + v + a): # found package. Check for missing headers for header in pkg.keys(): if not header in spacewalk_packages[p + v + a].keys(): spacewalk_packages[p + v + a][header] = pkg[header] # open new file new_package = open(spacewalk_file + '.new', 'w') for pkg in spacewalk_packages.values(): pkg.dump(new_package) new_package.write("\n") new_package.close() sys.exit(0) uyuni-test:/usr/local/sbin # -- 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] Inactive systems after registration
by Kaercher, Alexander 20 May '19

20 May '19

Hello, i set up a new uyuni and register my test systems. It was possible to registered the server successfully, but all the server are now inactive. After delete and reregistered again, only the salt-key is visible, but the system is not register successfully. After the delete I was also deinstalle the salt-minion, salt and python2-salt from the client and run the bootstrapscript again, without an error on the client side. The salt stack is working, I'm able to contact the minions from the salt-mast and across. The following os-systems are registered to Uyuni and has the same issue: OpenSUSE Leap 15.0 OpenSUSE Leap 15.1 OpenSUSE Leap 42.3 SLES12SP4 By the inactive and registered system it is possible to ask for the salt state from the client side: Salt-call state.highstate: local: ---------- ID: mgrchannels_repo Function: file.managed Name: /etc/zypp/repos.d/susemanager:channels.repo Result: True Comment: File /etc/zypp/repos.d/susemanager:channels.repo is in the correct state Started: 07:43:47.884492 Duration: 181.211 ms Changes: ---------- ID: /etc/pki/trust/anchors/RHN-ORG-TRUSTED-SSL-CERT Function: file.managed Result: True Comment: File /etc/pki/trust/anchors/RHN-ORG-TRUSTED-SSL-CERT is in the correct state Started: 07:43:48.066056 Duration: 1277.558 ms Changes: ---------- ID: update-ca-certificates Function: cmd.run Name: /usr/sbin/update-ca-certificates Result: True Comment: State was not run because none of the onchanges reqs changed Changes: ---------- ID: pkg_installed Function: pkg.installed Result: True Comment: No packages to install provided Started: 07:43:49.383607 Duration: 1.142 ms Changes: ---------- ID: pkg_removed Function: pkg.removed Result: True Comment: All specified packages are already absent Started: 07:43:49.385007 Duration: 1407.343 ms Changes: ---------- ID: pkg_latest Function: pkg.latest Result: True Comment: No packages to install provided Started: 07:43:50.792781 Duration: 0.797 ms Changes: ---------- ID: disable_spacewalksd Function: service.dead Name: rhnsd Result: True Comment: The named service rhnsd is not available Started: 07:43:50.795305 Duration: 17.72 ms Changes: ---------- ID: disable_spacewalk-update-status Function: service.dead Name: spacewalk-update-status Result: True Comment: The named service spacewalk-update-status is not available Started: 07:43:50.813411 Duration: 10.929 ms Changes: ---------- ID: disable_osad Function: service.dead Name: osad Result: True Comment: The named service osad is not available Started: 07:43:50.824714 Duration: 10.748 ms Changes: ---------- ID: remove_traditional_stack Function: pkg.removed Result: True Comment: All specified packages are already absent Started: 07:43:50.835840 Duration: 491.993 ms Changes: ---------- ID: mgr_mine_config Function: file.managed Name: /etc/salt/minion.d/susemanager-mine.conf Result: True Comment: File /etc/salt/minion.d/susemanager-mine.conf is in the correct state Started: 07:43:51.328156 Duration: 8.212 ms Changes: ---------- ID: mgr_salt_minion Function: pkg.installed Name: salt-minion Result: True Comment: All specified packages are already installed Started: 07:43:51.336736 Duration: 28026.016 ms Changes: ---------- ID: mgr_salt_minion Function: service.running Name: salt-minion Result: True Comment: The service salt-minion is already running Started: 07:44:19.363709 Duration: 30.719 ms Changes: Summary for local ------------- Succeeded: 13 Failed: 0 ------------- Total states run: 13 Total run time: 31.464 s >From the Salt-Master: uyuni:~ # salt '*' test.version uyuni-proxy.xxxxx.xxx: 2018.3.0 lxeval02.xxxxx.xxx: 2018.3.0 lxeval01.xxxxx.xxx: 2018.3.0 kvm.xxxxxx.xxx: 2019.2.0 I found no error in the /var/log/salt/master and only the following error is visible in the /etc/var/log/rhn/rhn_web_ui.log: 2019-05-09 07:49:40,330 [salt-event-thread-5] ERROR com.redhat.rhn.frontend.events.TransactionHelper - com.suse.manager.reactor.PGEventListenerException 2019-05-09 07:49:40,350 [salt-event-thread-3] ERROR com.redhat.rhn.frontend.events.TransactionHelper - Additional Exception during Exception handling java.lang.ClassCastException 2019-05-09 07:49:40,352 [salt-event-thread-6] ERROR com.redhat.rhn.frontend.events.TransactionHelper - java.lang.ClassCastException 2019-05-09 07:49:40,352 [salt-event-thread-5] ERROR com.redhat.rhn.frontend.events.TransactionHelper - java.lang.ClassCastException 2019-05-09 07:49:40,353 [salt-event-thread-2] ERROR com.redhat.rhn.frontend.events.TransactionHelper - java.lang.ClassCastException 2019-05-09 07:49:40,353 [salt-event-thread-2] ERROR com.redhat.rhn.frontend.events.TransactionHelper - Additional Exception during Exception handling java.lang.ClassCastException 2019-05-09 07:49:40,353 [salt-event-thread-5] ERROR com.redhat.rhn.frontend.events.TransactionHelper - Additional Exception during Exception handling java.lang.ClassCastException 2019-05-09 07:49:40,353 [salt-event-thread-7] ERROR com.redhat.rhn.frontend.events.TransactionHelper - java.lang.ClassCastException 2019-05-09 07:49:40,354 [salt-event-thread-6] ERROR com.redhat.rhn.frontend.events.TransactionHelper - Additional Exception during Exception handling java.lang.ClassCastException 2019-05-09 07:49:40,355 [salt-event-thread-7] ERROR com.redhat.rhn.frontend.events.TransactionHelper - Additional Exception during Exception handling java.lang.ClassCastException 2019-05-09 07:49:40,368 [salt-event-thread-1] ERROR com.suse.manager.reactor.PGEventListener - Unexpected exception while executing a MessageAction org.hibernate.NonUniqueResultException: query did not return a unique result: 2 at org.hibernate.query.internal.AbstractProducedQuery.uniqueElement(AbstractProducedQuery.java:1468) at org.hibernate.query.internal.AbstractProducedQuery.uniqueResult(AbstractProducedQuery.java:1438) at com.redhat.rhn.domain.server.VirtualInstanceFactory.lookupHostVirtInstanceByHostId(VirtualInstanceFactory.java:370) at com.redhat.rhn.manager.system.VirtualInstanceManager.updateHostVirtualInstance(VirtualInstanceManager.java:60) at com.suse.manager.reactor.messaging.VirtpollerBeaconEventMessageAction.lambda$execute$0(VirtpollerBeaconEventMessageAction.java:36) at java.util.Optional.ifPresent(Optional.java:159) at com.suse.manager.reactor.messaging.VirtpollerBeaconEventMessageAction.execute(VirtpollerBeaconEventMessageAction.java:35) at com.suse.manager.reactor.PGEventListener.lambda$null$1(PGEventListener.java:74) at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382) at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580) at com.suse.manager.reactor.PGEventListener.lambda$notify$2(PGEventListener.java:72) at java.util.stream.Streams$StreamBuilderImpl.forEachRemaining(Streams.java:419) at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580) at com.suse.manager.reactor.PGEventListener.notify(PGEventListener.java:69) at com.suse.salt.netapi.event.AbstractEventStream.notifyListeners(AbstractEventStream.java:64) at com.suse.manager.reactor.PGEventStream.lambda$processEvents$3(PGEventStream.java:147) at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) at java.util.stream.SortedOps$SizedRefSortingSink.end(SortedOps.java:352) at java.util.stream.Sink$ChainedReference.end(Sink.java:258) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) at com.suse.manager.reactor.PGEventStream.processEvents(PGEventStream.java:141) at com.suse.manager.reactor.PGEventStream.lambda$null$0(PGEventStream.java:127) at com.redhat.rhn.frontend.events.TransactionHelper.run(TransactionHelper.java:62) at com.redhat.rhn.frontend.events.TransactionHelper.handlingTransaction(TransactionHelper.java:46) at com.suse.manager.reactor.PGEventStream.lambda$notification$2(PGEventStream.java:126) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) 2019-05-09 07:49:40,386 [salt-event-thread-1] ERROR com.redhat.rhn.frontend.events.TransactionHelper - com.suse.manager.reactor.PGEventListenerException 2019-05-09 07:49:40,386 [salt-event-thread-7] ERROR com.suse.manager.reactor.messaging.JobReturnEventMessageAction - Error mapping action chain result: "'mgractionchains.resume' is not available." com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was STRING at path $ at com.google.gson.Gson.fromJson(Gson.java:900) at com.google.gson.Gson.fromJson(Gson.java:953) at com.suse.manager.reactor.messaging.JobReturnEventMessageAction.lambda$execute$7(JobReturnEventMessageAction.java:128) at java.util.Optional.ifPresent(Optional.java:159) at com.suse.manager.reactor.messaging.JobReturnEventMessageAction.execute(JobReturnEventMessageAction.java:114) at com.suse.manager.reactor.PGEventListener.lambda$null$1(PGEventListener.java:74) at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382) at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580) at com.suse.manager.reactor.PGEventListener.lambda$notify$2(PGEventListener.java:72) at java.util.stream.Streams$StreamBuilderImpl.forEachRemaining(Streams.java:419) at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580) at com.suse.manager.reactor.PGEventListener.notify(PGEventListener.java:69) at com.suse.salt.netapi.event.AbstractEventStream.notifyListeners(AbstractEventStream.java:64) at com.suse.manager.reactor.PGEventStream.lambda$processEvents$3(PGEventStream.java:147) at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) at java.util.stream.SortedOps$SizedRefSortingSink.end(SortedOps.java:352) at java.util.stream.Sink$ChainedReference.end(Sink.java:258) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) at com.suse.manager.reactor.PGEventStream.processEvents(PGEventStream.java:141) at com.suse.manager.reactor.PGEventStream.lambda$null$0(PGEventStream.java:127) at com.redhat.rhn.frontend.events.TransactionHelper.run(TransactionHelper.java:62) at com.redhat.rhn.frontend.events.TransactionHelper.handlingTransaction(TransactionHelper.java:46) at com.suse.manager.reactor.PGEventStream.lambda$notification$2(PGEventStream.java:126) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was STRING at path $ at com.google.gson.internal.bind.JsonTreeReader.expect(JsonTreeReader.java:161) at com.google.gson.internal.bind.JsonTreeReader.beginObject(JsonTreeReader.java:87) at com.google.gson.internal.bind.MapTypeAdapterFactory$Adapter.read(MapTypeAdapterFactory.java:183) at com.google.gson.internal.bind.MapTypeAdapterFactory$Adapter.read(MapTypeAdapterFactory.java:145) at com.google.gson.Gson.fromJson(Gson.java:888) For me it looks like an issue on the Uyuni, but can't found the issue. Who can help ? Best regards Alexander DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --. -- 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] Minions not connect to server
by Cristian Gherman 20 May '19

20 May '19

Hello, I have 50 systems managed by a Uyuni server. From this 7 of the not reconnect to server from 2 days. (Uyuni is 4.0 RC1 on OpensuseLeap). I restart all, minions and server with same results If I check from salt console they are ok, execute all comands. Where I can check the issue? I deleted the system from Uyuni but I can't readd as managed server. (with same hostname) What you suggest? Thanks in advance for any replay -- Cristian Gherman Support / PHP developer cristian.gherman(a)reea.net | www.reea.net | +4 0365410942

2 3

[uyuni-users] change SUSE products
by Haupt, Torsten 30 Apr '19

30 Apr '19

Hello, I want to change /update my SUSE products in Uyuni. I already configured repos for SLES12 some time ago. Now I want to add SLES15, but the GUI shows "Server error, please check log files.". And in rhn_web_ui.log I find: 2019-04-15 10:46:01,798 [ajp-apr-0:0:0:0:0:0:0:1-8009-exec-14] WARN com.redhat.rhn.manager.content.ContentSyncManager - Error reading UUID: /etc/zypp/credentials.d/SCCcredentials (No such file or directory) There is no SCCcredentials file and the folder is empty. What is going wrong and how can I add and change new SLES products? Regards Torsten -- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org

5 16

[uyuni-users] Service management via systemd for system/minon
by Cristian Gherman 17 Apr '19

17 Apr '19

Hello, I like to know if service management - via salt and systemd - for system exist or will be at some point implemented. Salt can manage services easely: - enable/disable service, - start/stop/restart service - show a lot of info about service And I think this feature on Uyuni will be helpfull. PS: I done this with a simple interface writen in PHP wich connect to salt-api. Thanks -- Cristian Gherman -- 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] Bootstrapped salt minions never appear as systems
by David Mace 16 Apr '19

16 Apr '19

Hi, so this was working initially, but something has broke. I am running Uyuni 4.0.1 stable on openSUSE 42.3 host. A new openSUSE Leap 15.0 minion is bootstrapped using bootstrap.sh which was generated using mgr-bootstrap. It joins Salt master and the key shows using command: salt-key -L But the minion never appears in Systems > Systems List Viewing the Salt message bus using salt-run state.event pretty=True I see this: salt/job/20190411153502494691/new { "_stamp": "2019-04-11T14:35:02.495370", "arg": [], "fun": "mgractionchains.resume", "jid": "20190411153502494691", "minions": [ "minion.domain.co.uk" ], "missing": [], "tgt": "minion.domain.co.uk", "tgt_type": "glob", "user": "salt" } salt/job/20190411153502494691/ret/minion.domain.co.uk { "_stamp": "2019-04-11T14:35:06.850239", "cmd": "_return", "fun": "mgractionchains.resume", "fun_args": [], "id": "minion.domain.co.uk", "jid": "20190411153502494691", "metadata": { "suma-action-chain": true }, "out": "nested", "retcode": 254, "return": "'mgractionchains.resume' is not available.", "success": false } >From the minion if I do a salt-call state.apply I get this error: minion.domain.co.uk:~ # salt-call state.apply [WARNING ] /var/cache/salt/minion/extmods/grains/__pycache__/cpuinfo.cpython- 36.py:20: DeprecationWarning: Use of 'salt.utils.which_bin' detected. This function has been moved to 'salt.utils.path.which_bin' as of Salt 2018.3.0. This warning will be removed in Salt Neon. [ERROR ] Error encountered during module reload. Modules were not reloaded. [WARNING ] /var/cache/salt/minion/extmods/modules/udevdb.py:24: DeprecationWarning: Use of 'salt.utils.which_bin' detected. This function has been moved to 'salt.utils.path.which_bin' as of Salt 2018.3.0. This warning will be removed in Salt Neon. [ERROR ] Template was specified incorrectly: False [ERROR ] Template was specified incorrectly: False local: Data failed to compile: ---------- Specified SLS packages.packages_7a5b9695fb48e3a146f6b8d35caf5e2a in saltenv base is not available on the salt master or through a configured fileserver ---------- Specified SLS custom.custom_7a5b9695fb48e3a146f6b8d35caf5e2a in saltenv base is not available on the salt master or through a configured fileserver Not sure where else to look for errors? -- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org

4 7

Re: [uyuni-users] Bootstrapped salt minions never appear as systems
by Strahil Nikolov 12 Apr '19

12 Apr '19

I'm quite new to the list, but the only thing that helps recover the SUMA 3.2 (that's what I have as experience) is to do a full reboot. If possible - try a reboot and check. If somebody more experienced can help you - it will be nice to learn how they do it. best Regards, Strahil Nikolov Hi, I also realised there have been no tasks scheduled or run in Schedule > Pending Actions or Schedule > Completed Actions since yesterday 10:25. I have restarted taskomatic since then. Is there something wrong with my database? Cheers -----Original Message----- Date: Fri, 12 Apr 2019 11:30:55 +0000 (UTC) Subject: Re: [uyuni-users] Bootstrapped salt minions never appear as systems To: uyuni-users(a)opensuse.org, David Mace <david(a)macemail.co.uk> From: Strahil Nikolov <hunter86_bg(a)yahoo.com> Hi David, I also have an openSuSE 15 minion and it joined properly. Here is what I did . 1. Checked what is the expected channel name so the bootstrap repo will be successfully created. -> /usr/share/susemgr/mgr_bootstrap_data.py 2. Created the channel with the same name and added several repos Mines are: oss/nonoss base oss/nonoss updates SLE15-uyuni-client-tools 3. Created the bootstrap repo mgr-create-bootstrap-repo 4. Created bootstrap script via web and edited it manually via cli to add the sle15 key 5. Bootstraped via web filling everything necessary. For bootstraping I have used the ip of the machine , but most probably it will work via hostname. Best Regards, Strahil Nikolov В петък, 12 април 2019 г., 6:37:09 ч. Гринуич-4, David Mace <david(a)macemail.co.uk> написа: Hi, so this was working initially, but something has broke. I am running Uyuni 4.0.1 stable on openSUSE 42.3 host. A new openSUSE Leap 15.0 minion is bootstrapped using bootstrap.sh which was generated using mgr-bootstrap. It joins Salt master and the key shows using command: salt-key -L But the minion never appears in Systems > Systems List Viewing the Salt message bus using salt-run state.event pretty=True I see this: salt/job/20190411153502494691/new { "_stamp": "2019-04-11T14:35:02.495370", "arg": [], "fun": "mgractionchains.resume", "jid": "20190411153502494691", "minions": [ "minion.domain.co.uk" ], "missing": [], "tgt": "minion.domain.co.uk", "tgt_type": "glob", "user": "salt" } salt/job/20190411153502494691/ret/minion.domain.co.uk { "_stamp": "2019-04-11T14:35:06.850239", "cmd": "_return", "fun": "mgractionchains.resume", "fun_args": [], "id": "minion.domain.co.uk", "jid": "20190411153502494691", "metadata": { "suma-action-chain": true }, "out": "nested", "retcode": 254, "return": "'mgractionchains.resume' is not available.", "success": false } >From the minion if I do a salt-call state.apply I get this error: minion.domain.co.uk:~ # salt-call state.apply [WARNING ] /var/cache/salt/minion/extmods/grains/__pycache__/cpuinfo.cpython- 36.py:20: DeprecationWarning: Use of 'salt.utils.which_bin' detected. This function has been moved to 'salt.utils.path.which_bin' as of Salt 2018.3.0. This warning will be removed in Salt Neon. [ERROR ] Error encountered during module reload. Modules were not reloaded. [WARNING ] /var/cache/salt/minion/extmods/modules/udevdb.py:24: DeprecationWarning: Use of 'salt.utils.which_bin' detected. This function has been moved to 'salt.utils.path.which_bin' as of Salt 2018.3.0. This warning will be removed in Salt Neon. [ERROR ] Template was specified incorrectly: False [ERROR ] Template was specified incorrectly: False local: Data failed to compile: ---------- Specified SLS packages.packages_7a5b9695fb48e3a146f6b8d35caf5e2a in saltenv base is not available on the salt master or through a configured fileserver ---------- Specified SLS custom.custom_7a5b9695fb48e3a146f6b8d35caf5e2a in saltenv base is not available on the salt master or through a configured fileserver Not sure where else to look for errors? -- 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] Error during applying the bootstrap state, message: Response code: 500
by Pavel Arnošt 12 Apr '19

12 Apr '19

Hi, I have fresh installation of Uyuni 4.0.1 on fully updated Leap 42.3 and I have problems bootstrapping minions on /rhn/manager/systems/bootstrap page. After click on "Bootstrap" button, it shows " Error during applying the bootstrap state, message: Response code: 500". I didn't do any configuration - I just created admin user. I traced error to salt-api that logs following while bootstrapping minion (fqdn of minion is replaced with "minion.domain"): [DEBUG ] Rendered data from file: /etc/salt/roster: # Sample salt-ssh config file #web1: # host: 192.168.42.1 # The IP addr or DNS hostname # user: fred # Remote executions will be executed as user fred # passwd: foobarbaz # The password to use for login, if omitted, keys are used # sudo: True # Whether to sudo to root, not enabled by default #web2: # host: 192.168.42.2 # Automatically added by "salt" at 2019-04-08T19:44:36.714140 None: host: None user: root passwd: # Automatically added by "salt" at 2019-04-08T19:54:16.464249 None: host: None user: root passwd: [ERROR ] Unable to render roster file: while constructing a mapping in "<unicode string>", line 11, column 1: None: ^ found conflicting ID 'None' in "<unicode string>", line 16, column 1: None: ^ [DEBUG ] Matched minions: {} [INFO ] [u'minion.domain'] [DEBUG ] Error while processing request for: /run Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/salt/netapi/rest_cherrypy/app.py", line 858, in hypermedia_handler ret = cherrypy.serving.request._hypermedia_inner_handler(*args, **kwargs) File "/usr/lib/python2.7/site-packages/cherrypy/_cpdispatch.py", line 61, in __call__ return self.callable(*self.args, **self.kwargs) File "/usr/lib/python2.7/site-packages/salt/netapi/rest_cherrypy/app.py", line 2135, in POST 'return': list(self.exec_lowstate()), File "/usr/lib/python2.7/site-packages/salt/netapi/rest_cherrypy/app.py", line 1185, in exec_lowstate ret = self.api.run(chunk) File "/usr/lib/python2.7/site-packages/salt/netapi/__init__.py", line 75, in run return l_fun(*f_call.get('args', ()), **f_call.get('kwargs', {})) File "/usr/lib/python2.7/site-packages/salt/netapi/__init__.py", line 140, in ssh return ssh_client.cmd_sync(kwargs) File "/usr/lib/python2.7/site-packages/salt/client/ssh/client.py", line 179, in cmd_sync **kwargs) File "/usr/lib/python2.7/site-packages/salt/client/ssh/client.py", line 141, in cmd **kwargs) File "/usr/lib/python2.7/site-packages/salt/client/ssh/client.py", line 73, in _prep_ssh return salt.client.ssh.SSH(opts) File "/usr/lib/python2.7/site-packages/salt/client/ssh/__init__.py", line 233, in __init__ self._update_targets() File "/usr/lib/python2.7/site-packages/salt/client/ssh/__init__.py", line 401, in _update_targets if salt.utils.network.is_reachable_host(hostname): File "/usr/lib/python2.7/site-packages/salt/utils/network.py", line 236, in is_reachable_host assert type(socket.getaddrinfo(entity_name, 0, 0, 0, 0)) == list TypeError: getaddrinfo() argument 1 must be string or None What am I doing wrong? Thanks, Regards, Pavel -- 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] Build repositories for openSUSE 42.3
by Robert Paschedag 28 Mar '19

28 Mar '19

Hi all, I already asked several times several weeks ago within the chat but I still have problems. I have a test uyuni server (4.0.1) running on openSUSE 42.3. Now I want to build new packages based on the "ubuntu-support" branch since there has been a lot of work in the last weeks and I want to test these improvements, since we are currently running Spacewalk 2.7 with a lot of Debian clients and are planning (or at least thinking about) migrating to Uyuni (to also get Salt). Now I also have a "build system" also based on openSUSE 42.3. But it seems that at least one "build repository" seems to be missing. Trying to build "spacewalk-backend" returns uyuni-build:~/git/uyuni/backend # rpmbuild -bb spacewalk-backend.spec error: Failed build dependencies: python2-spacewalk-usix is needed by spacewalk-backend-4.0.7-1.noarch python2-gzipstream is needed by spacewalk-backend-4.0.7-1.noarch python2-rhn-client-tools is needed by spacewalk-backend-4.0.7-1.noarch python2-rhnlib >= 2.5.74 is needed by spacewalk-backend-4.0.7-1.noarch My current list of repos. I know, there is missing but I did not find the above mentioned packages around the build.opensuse.org system (or I really overlooked something). uyuni-build:~/git/uyuni/backend # zypper lr Repository priorities are without effect. All enabled repositories share the same priority. # | Alias | Name | Enabled | GPG Check | Refresh ---+----------------------------------+-----------------------------------------+---------+-----------+-------- 1 | openSUSE-Leap-42.3-0 | openSUSE-Leap-42.3-0 | Yes | (r ) Yes | Yes 2 | repo-debug | openSUSE-Leap-42.3-Debug | No | ---- | ---- 3 | repo-debug-non-oss | openSUSE-Leap-42.3-Debug-Non-Oss | No | ---- | ---- 4 | repo-debug-update | openSUSE-Leap-42.3-Update-Debug | No | ---- | ---- 5 | repo-debug-update-non-oss | openSUSE-Leap-42.3-Update-Debug-Non-Oss | No | ---- | ---- 6 | repo-non-oss | openSUSE-Leap-42.3-Non-Oss | Yes | (r ) Yes | Yes 7 | repo-oss | openSUSE-Leap-42.3-Oss | Yes | (r ) Yes | Yes 8 | repo-source | openSUSE-Leap-42.3-Source | No | ---- | ---- 9 | repo-source-non-oss | openSUSE-Leap-42.3-Source-Non-Oss | No | ---- | ---- 10 | repo-update | openSUSE-Leap-42.3-Update | Yes | (r ) Yes | Yes 11 | repo-update-non-oss | openSUSE-Leap-42.3-Update-Non-Oss | Yes | (r ) Yes | Yes 12 | uyuni-master_leap42_client-tools | uyuni-master_leap42_client-tools | Yes | (r ) Yes | No uyuni-build:~/git/uyuni/backend # Where do I find the needed repositories for openSUSE 42.3 to be able to successfully build all "changed" packages? Thanks Robert -- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org

2 3

[uyuni-users] Bootstrap repo question
by Steve Moring 21 Mar '19

21 Mar '19

Hi, I'm trying to figure out why my bootstrap repo for os150 seems to be wanting to install older rpms. Any thoughts how I should go about trouble-shooting this? The channels were sync'd by: # spacewalk-common-channels -u <myuser> -p <mypassword> -a x86_64 'opensuse_leap42_3*' # spacewalk-common-channels -u <myuser> -p <mypassword> -a x86_64 'opensuse_leap15* ..after sync's finished about 2 days later :-) The bootstrap repo's were created with: #mgr-create-bootstrap-repo -c openSUSE-Leap-15-x86_64 #mgr-create-bootstrap-repo -c openSUSE-Leap-42.3-x86_64 # mgr-create-bootstrap-repo -l 1. openSUSE-Leap-15-x86_64 2. openSUSE-Leap-42.3-x86_64 The bootstrap_os150.sh file has the key defined, that key has the os150 base channel set, and has: openSUSE 15.0 non oss (x86_64) openSUSE Leap 15.0 non oss Updates (x86_64) openSUSE Leap 15.0 Updates (x86_64) Bootstrap output... uyuni:~ # cat /srv/www/htdocs/pub/bootstrap/bootstrap_os150.sh | ssh r oot@os150test /bin/bash The authenticity of host 'os150test (192.168.5.23)' can't be established. ECDSA key fingerprint is SHA256:EELiWSn3F8JABjdagE2OuHxCDWNGZQNf7R7Fiv12o8o. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'os150test,192.168.5.23' (ECDSA) to the list of known hosts. Password: Uyuni Server Client bootstrap script v4.0 MINOR MANUAL EDITING OF THIS FILE MAY BE REQUIRED! If this bootstrap script was created during the initial installation of a Uyuni Server, the ACTIVATION_KEYS, and ORG_GPG_KEY values will probably *not* be set (see below). If this is the case, please do the following: - copy this file to a name specific to its use. (e.g., to bootstrap-SOME_NAME.sh - like bootstrap-web-servers.sh.) - on the website create an activation key or keys for the system(s) to be registered. - edit the values of the VARIABLES below (in this script) as appropriate: - ACTIVATION_KEYS needs to reflect the activation key(s) value(s) from the website. XKEY or XKEY,YKEY Please note that if you are using this script to boostrap minions, only the FIRST activation key will be used. Multiple activation keys are not supported with salt - ORG_GPG_KEY needs to be set to the name(s) of the corporate public GPG key filename(s) (residing in /srv/www/htdocs/pub) if appropriate. XKEY or XKEY,YKEY Verify that the script variable settings are correct: - CLIENT_OVERRIDES should be only set differently if a customized client-config-overrides-VER.txt file was created with a different name. - ensure the value of HOSTNAME is correct. - ensure the value of ORG_CA_CERT is correct. Enable this script: comment (with #'s) this block (or, at least just the exit below, if present) UPDATING RHN_REGISTER/UP2DATE CONFIGURATION FILES ------------------------------------------------- * downloading necessary files client_config_update.py... WARNING: cannot verify uyuni.mydomain.site's certificate, issued by ‘CN=uyuni.mydomain.site,OU=services,O=mydomain,L=Fort Wayne,ST=IN,C=US’: Unable to locally verify the issuer's authority. 2019-03-14 11:55:34 URL:https://uyuni.mydomain.site/pub/bootstrap/clie nt_config_update.py [6478/6478] -> "client_config_update.py" [1] FINISHED --2019-03-14 11:55:34-- Total wall clock time: 0.04s Downloaded: 1 files, 6.3K in 0s (167 MB/s) client-config-overrides.txt... WARNING: cannot verify uyuni.mydomain.site's certificate, issued by ‘CN=uyuni.mydomain.site,OU=services,O=mydomain,L=Fort Wayne,ST=IN,C=US’: Unable to locally verify the issuer's authority. 2019-03-14 11:55:34 URL:https://uyuni.mydomain.site/pub/bootstrap/clie nt-config-overrides.txt [641/641] -> "client-config-overrides.txt" [1] FINISHED --2019-03-14 11:55:34-- Total wall clock time: 0.04s Downloaded: 1 files, 641 in 0s (65.1 MB/s) PREPARE GPG KEYS AND CORPORATE PUBLIC CA CERT ------------------------------------------------- * no organizational GPG keys to import * attempting to install corporate public CA cert WARNING: cannot verify uyuni.mydomain.site's certificate, issued by ‘CN=uyuni.mydomain.site,OU=services,O=mydomain,L=Fort Wayne,ST=IN,C=US’: Unable to locally verify the issuer's authority. 2019-03-14 11:55:34 URL:https://uyuni.mydomain.site/pub/rhn-org-truste d-ssl-cert-1.0-1.noarch.rpm [9416/9416] -> "rhn-org-trusted-ssl-cert- 1.0-1.noarch.rpm" [1] FINISHED --2019-03-14 11:55:34-- Total wall clock time: 0.04s Downloaded: 1 files, 9.2K in 0s (101 MB/s) Preparing... ################################ ######## Updating / installing... rhn-org-trusted-ssl-cert-1.0- 1 ######################################## CLEANING UP OLD SUSE MANAGER REPOSITORIES ------------------------------------------------- CHECKING THE REGISTRATION STACK ------------------------------------------------- * check for necessary packages being installed... * client codebase is opensuse-15-sp0 package salt is not installed package salt-minion is not installed 2019-03-14 11:55:35 URL:https://uyuni.mydomain.site/pub/repositories/o pensuse/15/0/bootstrap/repodata/repomd.xml [1279/1279] -> "repomd.xml" [1] FINISHED --2019-03-14 11:55:35-- Total wall clock time: 0.04s Downloaded: 1 files, 1.2K in 0s (130 MB/s) * going to install missing packages... 2019-03-14 11:55:35 URL:https://uyuni.mydomain.site/pub/repositories/o pensuse/15/0/bootstrap/repodata/repomd.xml [1279/1279] -> "repomd.xml" [1] FINISHED --2019-03-14 11:55:35-- Total wall clock time: 0.04s Downloaded: 1 files, 1.2K in 0s (95.1 MB/s) adding client software repository at https://uyuni.mydomain.site/pub/ repositories/opensuse/15/0/bootstrap Retrieving repository 'susemanager:bootstrap' metadata [.done] Building repository 'susemanager:bootstrap' cache [....done] Specified repositories have been refreshed. Loading repository data... Reading installed packages... Resolving package dependencies... 2 Problems: Problem: nothing provides python2-salt = 2018.3.0-33.2 needed by salt- 2018.3.0-33.2.x86_64 Problem: nothing provides python2-salt = 2018.3.0-33.2 needed by salt- 2018.3.0-33.2.x86_64 Problem: nothing provides python2-salt = 2018.3.0-33.2 needed by salt- 2018.3.0-33.2.x86_64 Solution 1: do not install salt-2018.3.0-33.2.x86_64 Solution 2: break salt-2018.3.0-33.2.x86_64 by ignoring some of its dependencies Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c] (c): c no package provides salt ERROR: Failed to install all missing packages. Thanks, -Steve -- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org

2 6

Re: [uyuni-users] proper update steps using uyuni os423 to os150
by Julio González Gil 14 Mar '19

14 Mar '19

On jueves, 14 de marzo de 2019 11:22:50 (CET) Steve Moring wrote: > Julio, > > On Thu, 2019-03-14 at 09:19 +0100, Julio González Gil wrote: > > Are you talking about migrating a client? > > Yes, sorry. I have some clients that are os423, some are os150. I > have keys defined for both. I have bootstraps for both. All are > salt. Understood :-) > > As far as I know we don't have an official procedure. > > I totally understand. It's not enterprise (SUMA). Well, what I mean is that I am not aware of anybody testing that so far, so I can't provide instructions that will work for sure (that's why I mentioned there is no "official procedure" :-) > I'm wondering how I would move an os423 client to be subscribed to the > channels defined with the os150 keys. Or, if I can unsubscribe the > os423 clients, clean up the bootstrapped components, then re-subscribe > to the os150 key/channels and upgrade. I get to play, so this is all > blue sky. Well, first of all I am not sure about your channel structure. But assuming that you have one base channel for Leap 42.3 and another base c channel for 15.0: a) If you are not worried about changing the activation key used for the current 42.3 clients, you could change the channels assigned to that key, and then create an action change as described. I am not sure if changing an activation key propagates the changes to the clients. b) If that doesn't work, then the other way to do it is to change the base channel for all 42.3 clients from the 42.3 base channel to the 15.0 base channel. That could be done with the API, to find all 42.3 clients and then change the base channel, And then, again, an action change to update all clients and reboot. In theory maybe you can also use spacecmd instead of raw calls to the API. I am not sure how easy will be filtering 42.3 clients with spacecmd as "system_list" does not seem to allow filters. > > But since Uyuni manages the repositories for the clients, and > > assuming your > > > > current Leap 42.3 are NOT traditional clients you could: > > > > 1. Adjust the channels assigned to the activation key to change them > > from Leap > > > > 42.3 to 15.0 > > > > 2. Create an action change to: > > > > - Apply the highstate (so the Leap 15.0 repositories become > > available for the > > > > client(s) > > > > - Update all packages > > > > - Reboot. > > Unfortunately, for this particular scenario, I'd have to move all the > clients at once. You can do that. The action change can be defined for several clients. I think you can achieve this with SSM (System Set Manager) I suggest you try with only one client first so you can fix the issues before applying the change to all of them. > > O course, this assumes the clients will not have any kind of > > dependency > > > > conflicts when switching from Leap 42.3 to Leap 15.0. > > Agreed, should be fun :-) If you are using the official repositories from Leap, and nothing else, then you should not have problems. In this case I was thinking when I migrated my laptop from Leap 42.3 to Leap 15.0. That was a problem because I use A LOT of extra repositories from OBS, and zypper complained about vendor changes and that sort of things :-) Anyway, if the clients are similar, remember: try first with one and fix as needed, before doing the massive change. If there are groups that are similar, then try first with one system for each group. Good luck! > Thanks for the cycles. > > -Steve -- Julio González Gil <jgonzalez(a)suse.com> Release Engineer SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

1 0

[uyuni-users] proper update steps using uyuni os423 to os150
by Steve Moring 14 Mar '19

14 Mar '19

Hi, Having lab time is infrequent. I'm planning to spend some time playing this coming weekend. I'd like to test updating from os423 to os150 using uyuni. What are the proper highlevel steps to perform this upgrade? Are there proper steps to clear a client bootstrapping? I'd like to test removing the channels defined for os423, updating to os150 using installation media, re-bootstrapping to os150 channels to compare the process. Thanks, -Steve -- 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 on openSUSE Leap 15
by Haupt, Torsten 02 Feb '19

02 Feb '19

Hello, the website mentions openSUSE Leap 42.3 as operating system. What about openSUSE Leap 15 or SLES 15? Works an installation on these systems, too? Or are there any disadvantages? Torsten -- 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] openSUSE 42.3 repo setup within wizard
by Steve Moring 02 Jan '19

02 Jan '19

Just getting started. I skipped the SCC credentials as I didn't have anything I wished to test against the SUSE SLE* repos (I do that with SUMA). Which brings up the question, how does one setup uyuni to mirror the openSUSE repos? I'd like to mirror then then bootstrap a few test boxes to play with. -Steve -- 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] Uyuni 4.0.1 is released!
by Julio González Gil 20 Dec '18

20 Dec '18

Hello everyone, We are happy to announce the immediate availability of Uyuni 4.0.1, our second Uyuni release! Repositories: - Server: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… - Proxy: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… - openSUSE Leap 42.3 (x86_64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… - openSUSE Leap 15.0 (x86_64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… - SLE12 (x86_64, pcc64le, s390x, aarch64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… - SLE15 (x86_64, pcc64le, s390x, aarch64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… - CentOS6 (i686, x86_64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… - CentOS7 (x86_64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… At https://www.uyuni-project.org/stable-version.html you will find all the resources you need to start working with Uyuni 4.0.1, including the release notes, documentation, requirements and setup instructions. Remember you can find the update instructions at the Best Practices guide. This is the list of highlights for this release: - Support for PostgreSQL 10 - spacecmd: Support state channels (aka Salt Minion config channels) - spacecmd: New API calls and spacecmd commands to merge packages and errata. - spacewalk-common-channels: Support for Uyuni, Fedora 29 and cleanup - openSUSE Leap 42.3/15.0, SLE12/15 and CentOS6 have now full support as salt, salt-ssh and traditional clients (Client Tools are still Beta) - New products added to SCC syncing Please check the release notes for full details. Remember that Uyuni will follow a rolling release planning, so next version will be 4.0.2 with bugfixes and features, and there will be no maintenance of 4.0.1. We hope you will enjoy Uyuni 4.0.1 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/contact.html -- Julio González Gil <jgonzalez(a)suse.com> Release Engineer SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

1 0

[uyuni-users] Re: Aw: [uyuni-devel] Looking for a way to automate the first organization creation
by Julio González Gil 14 Nov '18

14 Nov '18

Hi Christian and Robert. AFAIK, /root/setup_env.sh will not allow you to specify data for the first org and user. But you can use curl to fill in the form with a call like this one: curl -k -X POST -d "submitted=true&orgName=MYORGNAME&login=MYADMINUSER&desiredpassword=MYADMINPASSWORD&desiredpasswordConfirm=MYADMINPASSWORD&email=MYADMINEMAIL&firstNames=MYADMINFIRSTNAME&lastName=MYADMINLASTNAME" https://UYUNISERVERHOSTNAME/rhn/newlogin/CreateFirstUser.do Just replace the stuff in caps with the data you want for your first organization and user, and UYUNISERVERHOSTNAME with the hostname/IP for the server. Needless to say, the call could change a little if the webUI changes at some point, but this was working when I prepared the workshop for Uyuni at the openSUSE Conference 2018, and I am not aware we changed this part of the WebUI. BTW: Since the last week we already have uyuni-users(a)opensuse.org [1] available for user related discussion. I am adding this to CC so we can have record of this thread there. Best regards. [1] You can subscribe at https://lists.opensuse.org/uyuni-users/ On miércoles, 14 de noviembre de 2018 0:28:32 (CET) Robert Paschedag wrote: > I think, currently there is no way. This has been removed in 2015. See > https://www.redhat.com/archives/spacewalk-devel/2015-December/msg00000.html > . > > Currently, I could only think of manual SQL to first create the user and > then, create the org. > > Good luck. > > Robert > > > Gesendet: Dienstag, 13. November 2018 um 23:30 Uhr > > Von: "Stankowic, Christian" <Christian.Stankowic(a)sva.de> > > An: "uyuni-devel(a)opensuse.org" <uyuni-devel(a)opensuse.org> > > Betreff: [uyuni-devel] Looking for a way to automate the first > > organization creation > > > > Hello Uyuni team! > > > > I'm currently writing a Chef cookbook for automating Uyuni test > > deployments. After installing Uyuni, the first organization still needs > > to be created using the web page. > > > > I understand that there is an automation tool spacecmd, but this seems not > > to work if no organization or admin user exist: > > > > # spacecmd org_create > > Spacewalk Username: > > Spacewalk Password: > > ERROR: Invalid credentials > > > > I figured out that entering no username/password does not work (also not > > via the .spacecmd/config file) - so therefore the error message seems > > legit. > > > > My question is now: how can I automate this? I cannot used the web page in > > an automated manner. Is there an option for the /root/setup_env.sh file? > > > > Thanks a lot in advance - also keep up the good work! > > > > > > > > Best wishes, > > Christian Stankowic -- Julio González Gil <jgonzalez(a)suse.com> Release Engineer SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

2 1

[uyuni-users] Welcome to the uyuni-users mailing list!
by Julio González Gil 06 Nov '18

06 Nov '18

This message serves to test that the list is working fine, and to give you a warm welcome! This is the list where we will be discussing Uyuni usage stuff, such as commenting the experience with Uyuni, questions, best practices, etc. Anyone can post to this list as long as it is registered. Enjoy! -- Julio González Gil <jgonzalez(a)suse.com> Release Engineer SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

1 0