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
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
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.
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
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
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
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
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
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
