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