Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    zettelzottel
    @zettelzottel
    the unix15 system is connected to the repos when i am doing a dnf repolist
    for example
    zettelzottel
    @zettelzottel
    could have something to do with repo metadata signing
    initial dnf update was working ... but now dnf install package fails because key is missing ..
    but all packages should be signed with our gpg key
    anyways .. if someone has an idea what to look for .. drop me a note .. i am in a two day meeting now
    Christian Stankowic
    @stdevel
    Good morning - short question: currently it is necessary to remove child channels and then the parent channel after removing a Lifecycle Project Environment. Is it planning to automate this? Would be great to have a checkbox that does this automatically afterwards. What do you think?
    phibid
    @phibid
    @stdevel This is a good idea and I feel the same way. Channels deriving from the creation of a Lifecycle project should be removed with the Lifecycle project, or at least provide an option to do so (channel inheritance removal). I have spent some time to remove them by hand and this is not funny :-) If not yet done, you should perhaps create an issue for enhancement.
    ppc6446
    @ppc6446

    I'm getting an error in the WebUI trying to add a system - "Cannot read/write '/var/lib/salt/.ssh/known_hosts'. Please check permissions." The associated entry in rhn_web_ui.log is -
    2021-02-23 14:08:14,135 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-11] ERROR com.suse.manager.webui.controllers.utils.AbstractMinionBootstrapper - Error during bootstrap: Cannot read/write '/var/lib/salt/.ssh/known_hosts'. Please check permissions.

    It has been going on for a while - I had been hoping the latest upgrade would fix it, but no such luck. The permissions look correct: # ls -l /var/lib/salt/.ssh/known_hosts
    -rw-r--r-- 1 salt salt 397 Jan 7 15:16 /var/lib/salt/.ssh/known_hosts

    zettelzottel
    @zettelzottel
    can the user change directory to the location?
    ppc6446
    @ppc6446
    Yes, the salt user can cd to /var/lib/salt/.ssh
    phibid
    @phibid
    @ppc6446 If the permission issue is not on the file itself, I guess that it is on 1 of the directory. Please check the permissions of the directory leading to the known_hosts file:
    uyuni:~ # ls -ld /var /var/lib /var/lib/salt /var/lib/salt/.ssh /var/lib/salt/.ssh/known_hosts
    drwxr-xr-x 14 root root   225 Aug  3  2020 /var
    drwxr-xr-x 54 root root  4096 Aug  3  2020 /var/lib
    drwxr-xr-x  3 salt salt    18 Feb  8 09:49 /var/lib/salt
    drwx------  2 salt salt    48 Feb 22 14:49 /var/lib/salt/.ssh
    -rw-r--r--  1 salt salt 20815 Feb 22 14:49 /var/lib/salt/.ssh/known_hosts
    ppc6446
    @ppc6446
    I tried tracing it back to the root and it looks good at each level
    :/var/log # ls -ld / /var /var/lib /var/lib/salt /var/lib/salt/.ssh
    drwxr-xr-x 32 root root 4096 Feb  1 18:47 /
    drwxr-xr-x 13 root root  205 Jan 21 12:10 /var
    drwxr-xr-x 45 root root 4096 Dec  3 17:52 /var/lib
    drwxr-xr-x  3 salt salt   39 Feb 23 15:33 /var/lib/salt
    drwx------  2 salt salt   25 Jan 20 18:23 /var/lib/salt/.ssh
    phibid
    @phibid

    Found this suse-manager-4-unable-to-add-with-bootstrap, with pagarcia and mcalmer already there in 2019 :-)

    Have you the correct spacewalk sudo file ?

    uyuni:~ # cat /etc/sudoers.d/spacewalk  | tail -1
    tomcat  ALL=(root)      NOPASSWD: /usr/bin/ls -la /var/lib/salt/.ssh/known_hosts
    Jesse Harris
    @zigford
    Is there a way to install an older version of Uyuni? I may have encountered a bug with the latest version so want to install the last build released in 2020 to confirm.
    phibid
    @phibid
    @zigford Do not know if you can. But what is the bug you have, this is perhaps already documented ?
    Infinnerty
    @Infinnerty
    hey all, does the newest version of Uyuni support Centos 8 stream? Can only see support for regular Centos 8 in the documentation
    digdilem
    @digdilem
    @Infinnerty - Kind of. See this for more info on what doesn't work; uyuni-project/uyuni#3043
    Otherwise, it does work - just add the stream repos as you would for c8 linux
    Infinnerty
    @Infinnerty
    thanks @digdilem, looks a little broken in your issue notes. high state is pretty important for us so hoping the team can provide an update soon to address :)
    Jesse Harris
    @zigford
    @phibid, I've had a PoC of Suse Manager running with my own third party signed CA working for a while, but after last update spacecmd commands failed with ceritificate verification failed
    I do have a support ticket with SUSE, so will see what they come back with
    Christian Stankowic
    @stdevel
    @zigford : There are frozen release repos, I've documented them here: https://github.com/stdevel/katprep/blob/43-feat-uyuni_support/tests/Uyuni.md
    Unfortunately there is no snapshot for 2020.11
    Jesse Harris
    @zigford
    Thankfully I found the issue was not an issue with Uyuni at all. I simply must not have tested the spacecmd commands since installing the certificate. For other encountering this issue, I needed to combine my subca and rootca into a single ca file before generating the key-pair rpm.
    @stdevel That's really handy. Thankfully I won't need 2020.11, but the others will be useful in the future
    zettelzottel
    @zettelzottel
    what would I need to do getting cve data for centos in uyuni displayed?
    phibid
    @phibid
    @zettelzottel You mainly need to check 2 URLs:
    https://cefs.steve-meier.de/
    And the scripts: https://github.com/stevemeier/cefs
    zettelzottel
    @zettelzottel
    thanks @phibid
    digdilem
    @digdilem
    image.png
    Had a minor annoyance for some time now. Scheduled events are picked up and actioned, but remain as "Queued" in Uyuni for several/many hours until they disappear. This only seems to happen when I'm doing a lot concurrently (100+). Anyone got any ideas why they're not being marked as completed?
    Bob Martens
    @boblmartens
    Repository Uyuni Client Tools for openSUSE Leap 15.2 (x86_64) does not define additional 'gpgkey=' URLs.
    I am getting that error message when trying to update. What should I be doing differently?
    Do I need to set up those gpg keys in order to get this to work?
    Bob Martens
    @boblmartens
    I'm guessing I need to be looking at something like this: https://www.uyuni-project.org/uyuni-docs/uyuni/client-configuration/gpg-keys.html
    But, truth be told, that is not as understandable as I would like. Anyone willing to help translate so that I can move forward?
    Bob Martens
    @boblmartens
    I guess the biggest question I have is what I need to add to my sls file in order to trust the gpg key.
    I have modified the bootstrap script so that I can use that in the future. I continually get the error right now.
    I can refresh the repo on the server and it does not throw an error, but I continually get the following error when it tries to update:
    supportutils-plugin-salt-1.1.4-2.8.uyuni.noarch (Uyuni Client Tools for openSUSE Leap 15.2 (x86_64)): Signature verification failed [4-Signatures public key is not available]
    digdilem
    @digdilem
    2021.02 upgrade went fine, thanks everyone. :thumbsup:
    digdilem
    @digdilem

    Okay, slight qualifier to the above. Looks like this update does cause the centos-errata script by Steve Meier to fail. But it can be ignored by adding --ignore-api-version.

    I can't spot a reference in the release notes that the api version has changed, but Steve's script reports the following, which I don't recall seeing before today;

    INFO: Server is running API version 25
    ERROR: API version 25 is not supported. Try upgrading this script
    phibid
    @phibid

    @digdilem The list of supported API versions is present in errata-import.pl and indeed version 25 is not there:

    my @supportedapi = ( '10.9','10.11','11.00','11.1','12','13','13.0','14','14.0','15','15.0','16','16.0','17','17.0','18','18.0','19','19.0','20','20.0','21','21.0','22','22.0','23','23.0', '24');

    So to not have to use the --ignore-api-version option, the supported version could be added in the script I guess

    digdilem
    @digdilem
    Thanks for verifying. Not the biggest problem and easy to work around, although I'm guessing the value got changed in Uyuni during this version and the release notes didn't get updated?
    Julio González Gil
    @juliogonzalez
    that's right, so far we didn't include it, but it could be something interesting for people using integrations
    I will need to improve the script I have to detect version changes to consider the Java API as well
    digdilem
    @digdilem
    I let Steve know about this too, and he replied to say he's updated the script with support for the new version number.
    zettelzottel
    @zettelzottel
    how can i check from a client if it registered and the uyuni server is responding correctly?
    salt minion
    zettelzottel
    @zettelzottel
    can i use salt-call test.ping .. and if that is successful then the client is registered?