March 2021 - ARCHIVED: Uyuni Users - openSUSE Mailing Lists

[uyuni-users] Fresh Install uyuni 2020.05 Error generating bootstrap repo
by Thomas Weis 24 Aug '22

24 Aug '22

Hello everyone we are configuring a fresh installation of Uyuni 2020.05 After a successful reposync of SUSE Linux Enterprise Server 15 SP1 x86_64 we get an error message: Type: Creating Bootstrap Repository failed Summary: Error generating bootstrap repo for: SLE-15-SP1-x86_64 show details said: ERROR: package 'hwdata' not found ERROR: package 'python3-hwdata' not found ERROR: package 'python3-rhnlib' not found ERROR: package 'spacewalk-check' not found ERROR: package 'spacewalk-client-setup' not found ERROR: package 'spacewalk-client-tools' not found ERROR: package 'python3-spacewalk-check' not found ERROR: package 'python3-spacewalk-client-setup' not found ERROR: package 'python3-spacewalk-client-tools' not found ERROR: package 'python3-uyuni-common-libs' not found ERROR: none of 'mgr-daemon', 'spacewalksd' found ERROR: package 'suseRegisterInfo' not found ERROR: package 'python3-suseRegisterInfo' not found ERROR: package 'zypp-plugin-spacewalk' not found ERROR: package 'python3-zypp-plugin-spacewalk' not found The installation was error-free, we proceeded exactly according to the documentation. What is our mistake? thanks for suggestions Regards Thomas-- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org

3 2

Suma feedback / potentital enh requests
by J-M Roth 02 May '21

02 May '21

Hello, We've been in contact with our Suse Account Team after evaluating and getting a Suma subscription to show our support. First, congrats, the product seems pretty stable, usability is high (GUI is very reactive), it is well-integrated with Saltstack while at the same time providing interfaces for customization. Concerning potential feedback and enhancement requests they told us to come here. So here is my current list: * VERY DANGEROUS: Using groups: It is not clear from the system view that a state/config channel is applied to a system via a group. If a system is managed through a group, that should be made clear on the Systems > system > Configuration > Overview screen and also Systems > system > States > Configuration Channels screen of that individual system. This is _very_ dangerous because applying a highstate might do unexpected things since the system is mostly invisibly part of a group. In the same way, Configuration > Channels > channel > Systems does not show that the currently selected channel applies to any group (or a list of systems expanded from the group, for that matter). It looks like groups were retrofitted, this really needs to be cleaned up. * System shows ok (up-to-date) if product does not exist at all. If you add a system for which the product is not mirrored to Suma at all, the "Updates" column of System List shows a green checkmark while the "base repo" column shows "(none)". The green checkmark is misleading, at most there should be a grey icon or so meaning that there is actually no info. * System shows ok if there are non-compliant packages. A green checkmark appears in System List if system contains non-compliant packages (Systems > system > Software > Packages > Non Compliant). The system list could somehow reflect the presence of non-compliant packages. These could for example pose a security risk. * Very old OS release shows as ok/up-to-date. For example, a fully patched SLES11-SP1 is shown with a green checkmark. Technically, this information therefore correct. However, in reality, the OS has been end-of-life for several years. It should show something other than the green checkmark which is creating a false belief that the system is ok while it should be replaced. Certainly it would not be impossible to look at for example the release date of the latest patch. If it's too old, there can be a warning. * In general, the system list/overview page could provide an even more holistic view by making more distinctions in the "Updates" column (or adding another "Status" perhaps) - Show a warning for very old OS (see above) - Show a warning if system contains non-compliant packages (see above) - Show a warning if product does not exist at all (instead of green, see above) - Reboot required could be shown in that same list (like after an SP migration) - State apply failures could also reflect in that list * Suma bootstrapping does not recognize enabled modules/products If the system being onboarded was previously registered to SCC, SMT or RMT, the previously enabled modules (for example SDK or Web-Scripting-Module etc.) are not automatically activated, even if Suma has correctly mirrored them. Instead, you have to compare which modules were used previously and perform manual actions to add them again. Probably this is not fixable, still it was something that caught our attention. * Software Channel Management Software > Manage > Channels page could show the sync policy for the individual channels. Currently there is no overview of the sync policies of the individual channels. You have to click on each one, open it and take a look. Best regards, J-M Roth

3 2

A question on Configurations - Locally managed files.
by Simon Avery 30 Mar '21

30 Mar '21

Hello, Yesterday I got in a bit of a pickle with Uyuni and through my own fault, managed - in relatively few clicks - to add some new files to an existing Configuration channel and set them as "Locally managed" on almost 200 machines. Once I understood my mistake (I wanted to push a new version of existing files), I tried to revert this mistake but I could not find a way to do so globally. The only way I could see to do this was to visit each machine in Uyuni, select the three files one at a time and delete the record for that machine. I did actually try to do this, but Uyuni becomes unresponsive when you have over a hundred browser tabs open to it... Deleting the files from the channel didn't remove the association on the machines, which I expected. Re-adding the files caused the new record to assume the same, and they immediately set as Locally managed, suggesting the link is the file+path on the machines. I searched for some time to find a way to remove this globally but was unsuccessful. Eventually, as I as pressed for time, I restored a backup of Uyuni and re-added the files as centrally managed which worked fine. So my question: Was I being dim and there is a way to globally change what Uyuni records as "Locally managed" configuration files - if so, how? Or is this a "We didn't think users could be so silly so we didn't allow for it" situation? Thanks Simon Avery

1 0

Host-based pillars
by jm+github＠roth.lu 23 Mar '21

23 Mar '21

Hello, How can assign custom metadata to a host? (custom key/value pairs for example) I know I can define a pillar manually in Salt master /srv/pillar. However it would be great to just be able to assign custom values/pillars to a host in the GUI such that I can pick those up in my states. I know I can include this myself in the GUI by using forms. But that's not what I mean because I would have to "ask the same question" in every form where this information is required. Instead, I just want these custom attributes derived from the host, plain and simple. Any idea? Thanks.

3 3

Mandatory and Optional SUSE channels
by Tim Shaw 19 Mar '21

19 Mar '21

Hello I'm puzzled as to how to add optional channels to an existing product in 2012.03 I have a product to which I am subscribed - Open Enterprise Server 2018 SP2 It has mandatory channels which are all there and in sync - but now I need to add a specific optional channel from the same product - there are many listed... I cannot see any way to do this in the GUI - is that right? Can it be done from the CLI I cannot recall whether,l when I added this channel a year ago through the GUI, I was ever given an option to add optional channels or not... Can anyone advise please? 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

3 3

Google Season of Docs: ideas for Uyuni?
by Pau Garcia 10 Mar '21

10 Mar '21

Hello We are going to apply to Google Season of Docs, to improve the existing documentation or write new documentation. What is missing? What can be improved? What can be enhanced? Please come up with ideas until Tuesday next week (16.03.2021). Thank you Pau Garcia Quiles SUSE Manager Product Owner & Technical Project Manager Phone: +34 91 048 7632 SUSE Software Solutions Spain

1 0

Uyuni accepted in Google Summer of Code 2021
by Pau Garcia 09 Mar '21

09 Mar '21

Hello For the second year, we are participating in Google Summer of Code under the umbrella of openSUSE. Google Summer of Code is a global program focused on bringing more student developers into open source software development. Students work with an open source organization on a 10 week programming project during their break from school. Students receive a stipend of USD 1,500-3,300, depending on their country of residence. Here you can see a list of the ideas we proposed but you can of course propose new ideas: https://github.com/openSUSE/mentoring/labels/Uyuni If you are interested in participating, or know someone who is, get in touch with us early, via mailing list or GitHub issues linked above! Thank you Pau Garcia Quiles SUSE Manager Product Owner & Technical Project Manager Phone: +34 91 048 7632 SUSE Software Solutions Spain

1 0

[Looking for ideas] Editor integration of Uyuni
by Dan Čermák 08 Mar '21

08 Mar '21

Hi list, I wanted to kick off a discussion about a potential integration of Uyuni with some text editors/IDEs and start collecting ideas. And this is where you come in ;-) So please, tell me: what is your favorite editor that you'd like to use to interact with Uyuni or SUMA? What kind of integration would you find useful? I've already asked around a bit and the following ideas came up: - better autocompletion & code smarts for writing salt states (e.g. via a language server protocol server[1]) - autocompletion for kiwi templates, autoyast profiles and Dockerfiles with support for software channel information - trigger certain actions directly from the editor, e.g. build an OS image But please think of your dream setup here and be just limited by your imagination :) Have a nice weekend, Dan Footnotes: [1] https://microsoft.github.io/language-server-protocol/ -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer

3 2

Re: Post 2021.02 upgrade issues
by Tim Shaw 05 Mar '21

05 Mar '21

Julio Ah! - this gave me the clue I was looking for I had somehow failed to set this repo up for scheduled synchronisation with the result that the new salt packages were not availabe My fault - and many thanks for the guidance! 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 >>> Julio González Gil <jgonzalez(a)suse.com> 05/03/2021 16:35 >>> I don't recall we ever shipped Salt 2019 to Stable. Maybe you got those packages from the "Master" client tools? Those client tools are not production ready. Please check what repositories you are using on that CentOS7 client (and any other CentOS7 clients). Make sure they are the Stable repositories. If they are not, change the CentoS7 clients to the Stable repositories (you can use "System Set Manager" if you want to change several clients at the same time) Then update the salt packages at the CentOS7 clients (you will get salt 3000), and the problem should go away. On viernes, 5 de marzo de 2021 17:18:39 (CET) Tim Shaw wrote: > Julio > > Many thanks - here is the result > > salt-2019.2.3-18.1.uyuni.x86_64 > python2-salt-2019.2.3-18.1.uyuni.x86_64 > salt-minion-2019.2.3-18.1.uyuni.x86_64 > > 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 > > >>> Julio González Gil <jgonzalez(a)suse.com> 05/03/2021 14:51 >>> > > Can you provide the output of: > > rpm ‑qa|grep salt > > At that CentOS7 minion? > > On viernes, 5 de marzo de 2021 15:05:48 (CET) Tim Shaw wrote: > > Hello > > > > Thanks to all who offered advice during the very long 13 hour > > postgres > > > schema update on my Uyuni system! > > > > Since the update completed I've been testing things today and the > > first > > > issue I see is that hitherto trouble free CentOS7 client systems will > > now > > > no longer apply patches scheduled from Uyuni. If the packages rather > > than > > > the patches are scheduled there is no problem. > > > > SLES based systems appear to be patching just fine.... > > > > The errors look like this: > > > > Mar 5 13:40:24 zabbix salt‑minion: [ERROR ] An exception occurred > > in this > > > state: Traceback (most recent call last): Mar 5 13:40:24 zabbix > > salt‑minion: File "/usr/lib/python2.7/site‑packages/salt/state.py", > > line > > > 1939, in call Mar 5 13:40:24 zabbix salt‑minion: ret = > > self.states[cdata['full']](*cdata['args'], **cdata['kwargs']) Mar 5 > > 13:40:24 zabbix salt‑minion: File > > "/usr/lib/python2.7/site‑packages/salt/loader.py", line 2006, in > > wrapper > > > Mar 5 13:40:24 zabbix salt‑minion: return f(*args, **kwargs) > > Mar 5 13:40:24 zabbix salt‑minion: File > > "/usr/lib/python2.7/site‑packages/salt/states/pkg.py", line 2160, in > > patch_installed Mar 5 13:40:24 zabbix salt‑minion: targets = > > _find_advisory_targets(name, advisory_ids, **kwargs) Mar 5 13:40:24 > > zabbix > > > salt‑minion: File > > "/usr/lib/python2.7/site‑packages/salt/states/pkg.py", > > > line 386, in _find_advisory_targets Mar 5 13:40:24 zabbix > > salt‑minion: > > cur_patches = __salt__['pkg.list_installed_patches'](**kwargs) Mar > > 5 > > > 13:40:24 zabbix salt‑minion: File > > "/usr/lib/python2.7/site‑packages/salt/modules/yumpkg.py", line 3273, > > in > > > list_installed_pat ches > > Mar 5 13:40:24 zabbix salt‑minion: return > > _get_patches(installed_only=True) > > > Mar 5 13:40:24 zabbix salt‑minion: File > > "/usr/lib/python2.7/site‑packages/salt/modules/yumpkg.py", line 3222, > > in > > > _get_patches Mar 5 13:40:24 zabbix salt‑minion: line).groups() > > Mar 5 13:40:24 zabbix salt‑minion: AttributeError: 'NoneType' object > > has no > > > attribute 'groups' > > > > Can anyone offer any ideas as to where to start troubleshooting this > > please > > > (rebooting the CentOS7 client makes no difference) ? > > > > 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 > > ‑‑ > Julio González Gil > Release Engineer, SUSE Manager and Uyuni > jgonzalez(a)suse.com -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

2 1

Re: Post 2021.02 upgrade issues
by Tim Shaw 05 Mar '21

05 Mar '21

Julio Many thanks - here is the result salt-2019.2.3-18.1.uyuni.x86_64 python2-salt-2019.2.3-18.1.uyuni.x86_64 salt-minion-2019.2.3-18.1.uyuni.x86_64 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 >>> Julio González Gil <jgonzalez(a)suse.com> 05/03/2021 14:51 >>> Can you provide the output of: rpm ‑qa|grep salt At that CentOS7 minion? On viernes, 5 de marzo de 2021 15:05:48 (CET) Tim Shaw wrote: > Hello > > Thanks to all who offered advice during the very long 13 hour postgres > schema update on my Uyuni system! > > Since the update completed I've been testing things today and the first > issue I see is that hitherto trouble free CentOS7 client systems will now > no longer apply patches scheduled from Uyuni. If the packages rather than > the patches are scheduled there is no problem. > > SLES based systems appear to be patching just fine.... > > The errors look like this: > > Mar 5 13:40:24 zabbix salt‑minion: [ERROR ] An exception occurred in this > state: Traceback (most recent call last): Mar 5 13:40:24 zabbix > salt‑minion: File "/usr/lib/python2.7/site‑packages/salt/state.py", line > 1939, in call Mar 5 13:40:24 zabbix salt‑minion: ret = > self.states[cdata['full']](*cdata['args'], **cdata['kwargs']) Mar 5 > 13:40:24 zabbix salt‑minion: File > "/usr/lib/python2.7/site‑packages/salt/loader.py", line 2006, in wrapper > Mar 5 13:40:24 zabbix salt‑minion: return f(*args, **kwargs) > Mar 5 13:40:24 zabbix salt‑minion: File > "/usr/lib/python2.7/site‑packages/salt/states/pkg.py", line 2160, in > patch_installed Mar 5 13:40:24 zabbix salt‑minion: targets = > _find_advisory_targets(name, advisory_ids, **kwargs) Mar 5 13:40:24 zabbix > salt‑minion: File "/usr/lib/python2.7/site‑packages/salt/states/pkg.py", > line 386, in _find_advisory_targets Mar 5 13:40:24 zabbix salt‑minion: > cur_patches = __salt__['pkg.list_installed_patches'](**kwargs) Mar 5 > 13:40:24 zabbix salt‑minion: File > "/usr/lib/python2.7/site‑packages/salt/modules/yumpkg.py", line 3273, in > list_installed_pat ches > Mar 5 13:40:24 zabbix salt‑minion: return _get_patches(installed_only=True) > Mar 5 13:40:24 zabbix salt‑minion: File > "/usr/lib/python2.7/site‑packages/salt/modules/yumpkg.py", line 3222, in > _get_patches Mar 5 13:40:24 zabbix salt‑minion: line).groups() > Mar 5 13:40:24 zabbix salt‑minion: AttributeError: 'NoneType' object has no > attribute 'groups' > > Can anyone offer any ideas as to where to start troubleshooting this please > (rebooting the CentOS7 client makes no difference) ? > > 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 ‑‑ Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

2 1