Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    jkinning
    @jkinning
    Ok, so I don't need to have ORG_GPG_KEY=RHN-ORG-TRUSTED-SSL-CERT in my bootstrap file. I should have uyuni-gpg-pubkey-0d20833e.key is there a way to update the current machines I have deployed or do I just re-run the bootstrap script on them? I have the clients appearing in the UI but it is when they try and get packages is when I see that Public key error message. Running command from Salt, which is awesome by the way, works as well.
    jkinning
    @jkinning
    OK, I added those and it now works. However, I am back to trying to figure out how I can update my current registered machines or do I remove them and re-run the bootstrap script on them?
    Julio González Gil
    @juliogonzalez
    personally, I'd create a salt state to import the key, and then I'd apply it to all instances
    or as an alternative, you could also run a salt command to do it, by getting the GPG key from the server, then importing it with rpm
    the GPG key is at /pub at the server
    about ORG_GPG_KEY, do not remove what's there, add the new uyuni gpg key, the variable can have several values separated by ,
    I think the doc should get an update to make this more clear, and maybe the bootstrap script generator as well (if it's not on the comments there)
    jkinning
    @jkinning
    Thanks I was able to run it through the salt command UI to import those keys.
    igorgolm
    @igorgolm
    Hi, does anybody tried to configure LDAP authentication for Uyuni?
    I found this manual https://www.uyuni-project.org/uyuni-docs/uyuni/administration/auth-methods-pam.html - but where I should configure LDAP server etc ?
    Shirocco88
    @Shirocco88
    If you want to configure Uyuni "Authentication With PAM",
    then you have to install pam_ldap
    und configure "pam_ldap" by yast2
    jkinning
    @jkinning
    I originally added a custom repo for Oracle Linux UEK, http://yum.oracle.com/repo/OracleLinux/OL8/UEKR6/x86_64, and set it up to update a 1am EST everyday. I keep getting emails that this fails. RepoMDError: Cannot access repository. Maybe repository GPG keys are not imported. If I run the spacewalk-repo-sync from the uyuni server terminal I see the message about the repomd.xml is unsigned, continue? I select yes and it works. I have been hunting around trying to figure out how I can fix this or what GPG keys I need to import to allow this to just work?
    Julio González Gil
    @juliogonzalez
    the thing is that the repo seems to be unsigned, so doesn't seem you need any keys imported, if so it should be configured that way at Uyuni and I think it should work
    you should be able to configure that from the UI
    for the channel where the repo is enabled, there's a Enable GPG Check that probably is checked in your case
    jkinning
    @jkinning
    I am experimenting with all the various Linux distributions uyuni handles. This is an amazing project! I was going to try and add the Ksplice channels from Oracle's ULN and have modified the /etc/rhn/spacewalk-repo-sync/uln.conf with proper ULN credentials. When I try to create the repo by adding a label - Oracle Ksplice OL 8 and the URL - uln:///ol8_x64_ksplice and change the Repository type to uln within the UI I get a message that says "The given url is invalid. Please enter an url with valid syntax (e.g. specify protocol). I was follwing Oracle's guide https://docs.oracle.com/en/operating-systems/oracle-linux/ksplice-user/ol_ksabout.html#ksplice_swkmirror but not sure it that was specific for their Spacewalk version or if uyuni can sync with ULN. I also have filters applied -uptrack-updates-4.14.35-*
    ewenf-uindy
    @ewenf-uindy
    OL is nothing but a pain in the pooper, I've got to go in and create repos for our databases that OL uses
    Julio González Gil
    @juliogonzalez
    @jkinning on paper Uyuni should be able to handle it, but the problem is that we don't have access to ULN to actually test it and fix problems
    jkinning
    @jkinning
    Gotcha... good to know.
    Back to CentOS 7 :) I registered a device and I see it under the Salt|Keys but it isn't hyperlinked like the other CentOS 7 servers I have. From what I found is cloning may cause this but the fingerprint on them all are different. Is there something else I need to do so this server gets "pushed" over to the Systems area where I can add the channels and all the other good stuff? I tried registering it with the bootstrap script that I used for other CentOS 7 servers. Deleted it from the Salt|Keys and then attempted to register it from the Systems|Bootstraping within the UI. I can interact it from Salt just not the Systems or add channels as the server listed in Salt Keys is just text and no link like the others, if that make sense.
    Julio González Gil
    @juliogonzalez
    if you are using cloned servers, did you regenerate the UUID?
    ewenf-uindy
    @ewenf-uindy
    @jkinning I added # Rebuild uuid since vms were cloned and causes issue with registration.
    rm -f /etc/machine-id
    rm -f /var/lib/dbus/machine-id
    dbus-uuidgen --ensure
    systemd-machine-id-setup to my boostrap
    that way the UUID changes when the bootstrap is run
    jkinning
    @jkinning
    Yes, I just checked and that was all changed. However, my clients are not shown in the Systems just under the Salt|Keys and while the others have the blue text, hyperlinks, a couple are just black text. I have restarted the salt-minion removed and deleted stuff a few times and still the same result. Very strange so been looking at the docs to figure out logs to look at to help troubleshoot. Not sure if I can run the highstate on them, not sure how I would even do that since I am just learning about Salt. :)
    Julio González Gil
    @juliogonzalez
    according to that doc, you could rerun the bootstrap procedure, but make sure you generate a new UUID
    (ahead of the bootstrap)
    jkinning
    @jkinning
    I've ran the bootstrap several times along with the UI bootstrapping. I've also manually run the command to change the UUID's but one of the machines is bare metal and giving me the same problems. Looks like it is alright with Salt but not the other parts to manage packages and such. These were registered with Spacewalk previously but using @ewenf-uindy helpful suggestions it removes all the rhn stuff. I even rebooted the machine and it still isn't kicking over and just Salt aware. I guess that is what you'd call it.
    Shirocco88
    @Shirocco88

    Question: how can I change "package download endpoint override":

    Release Notes:
    It is now possible to set a custom protocol, host and path for minions to download packages at installation time. This will override the default setting of the Uyuni Server or Uyuni Proxy used at registration time.

    jkinning
    @jkinning
    All - I was able to correct my issue be stopping the salt-minion and rm -rf /etc/salt and then re-running the bootstrap script. That was a doozy!
    ewenf-uindy
    @ewenf-uindy
    hold on, let me go back through my notes, there was something I had to delete to get the minion to reregister correctly
    Shirocco88
    @Shirocco88
    If it is a cloned system, then you should clean your client system before bootstrapping:
    rm /etc/salt/pki/minion/minion*
    rm -r /var/cache/salt/minion
    ewenf-uindy
    @ewenf-uindy
    That's what I was about to post
    Shirocco88
    @Shirocco88
    rm /etc/salt/minion_id
    systemctl stop salt-minion.service
    ewenf-uindy
    @ewenf-uindy
    has anyone gotten the centos6 bootstrap to work?
    jkinning
    @jkinning
    I got an Oracle Linux 6 bootstrap to work, shouldn't be too much different.
    ewenf-uindy
    @ewenf-uindy
    what magic voodoo did you have to do, did it just install right out of thee box?
    jkinning
    @jkinning
    I created the bootstrap script and then added your voodoo to the script and then on my client ran 'curl -Sks https://uyuniserver/pub/bootstrap/bootstrap.sh | /bin/bash' then under the Salt keys accepted my client.
    Shirocco88
    @Shirocco88

    Again:
    Question: how can I change "package download endpoint override":

    Release Notes:
    It is now possible to set a custom protocol, host and path for minions to download packages at installation time. This will override the default setting of the Uyuni Server or Uyuni Proxy used at registration time.

    is it possible to define special settings (custom protocol, host and path) whitin /etc/zypp/repos.d/susemanager:channel.repo on a per client basis ?
    is there anyone, who can give me a hint;

    igorgolm
    @igorgolm
    Hi, is there any way to proxy master gpg keys, which are in /srv/www/htdocs/pub/, also?
    Julio González Gil
    @juliogonzalez
    question: is anyone here using Uyuni 2020.07 with the patch for the CVE we released last week?
    I am asking because I'd like to know if anyone else is affected by uyuni-project/uyuni#2623 before releasing Uyuni 2020.09
    Julio González Gil
    @juliogonzalez
    @igorgolm it should be doing it automatically, isn't?
    mmmm, or maybe not
    I see the same things on my server and proxy, but maybe they synced initially
    igorgolm
    @igorgolm
    @juliogonzalez seems like not
    Julio González Gil
    @juliogonzalez
    seems /pub is served by apache, so not proxied
    on paper you could change apache and squid configurations to do it, but I am not sure about the consequences
    well, maybe only apache and not even squid, but again: not sure about the consequences
    igorgolm
    @igorgolm
    @juliogonzalez but anyway - I'd like to try