SuSE Manager

From Lolly's Wiki
Revision as of 17:53, 25 November 2021 by Lollypop (talk | contribs) (Text replacement - "<source" to "<syntaxhighlight")
Jump to navigationJump to search


SuSE Manager

Channels

Refresh channle list

# mgr-sync refresh
</source>
===List available channels===
<syntaxhighlight lang=bash>
# mgr-sync list channels
</source>
===Add Channel===
<syntaxhighlight lang=bash>
# mgr-sync add channel <channel>
</source>
===Delete Channel===
<syntaxhighlight lang=bash>
# spacewalk-remove-channel -c <channel>
</source>
===Create a frozen channel===
Clone a channel (which is like a snapshot) and add a timestamp at the end of the name:
<syntaxhighlight lang=bash>
# spacecmd softwarechannel_clonetree -s '<syntaxhighlight channel or pool>' -x "s/\$/-$(date '+%Y-%m-%d_%H:%M:%S')/"
</source>
e.g.:
<syntaxhighlight lang=bash>
# spacecmd softwarechannel_clonetree -s 'sles12-sp3-pool-x86_64' -x "s/\$/-$(date '+%Y-%m-%d_%H:%M:%S')/"
</source>
will result in a new channel pool named e.g. sles12-sp3-pool-x86_64-2017-11-22_14:26:42

===Compose your own channel===
<syntaxhighlight lang=bash>
# spacecmd
spacecmd {SSM:0}> softwarechannel_create -n OpenSuSE -l opensuse -a x86_64 -c sha256

spacecmd {SSM:0}> repo_create -n opensuse-database-sles12-sp2-x86_64 -u https://download.opensuse.org/repositories/server:/database/SLE_12_SP2/
spacecmd {SSM:0}> repo_create -n opensuse-database-sles12-sp3-x86_64 -u https://download.opensuse.org/repositories/server:/database/SLE_12_SP3/

spacecmd {SSM:0}> repo_list
opensuse-database-sles12-sp2-x86_64
opensuse-database-sles12-sp3-x86_64

spacecmd {SSM:0}> softwarechannel_addrepo opensuse opensuse-database-sles12-sp2-x86_64
spacecmd {SSM:0}> softwarechannel_addrepo opensuse opensuse-database-sles12-sp3-x86_64

spacecmd {SSM:0}> quit
# spacewalk-repo-sync -c opensuse
</source>

==Bootstrap==
===Create bootstrap repo===
Do it for each channel!
<syntaxhighlight lang=bash>
# mgr-create-bootstrap-repo
</source>

===Create bootstrap shell scripts in /srv/www/htdocs/pub/bootstrap===
Do not forget to lookup the available [[#List available activation keys|activation keys]]
<syntaxhighlight lang=bash>
# spacecmd -s susemanager.server.de -u mytestuser -q  activationkey_list
6-sles11-sp3-x86_64
6-sles11-sp4-x86_64
6-sles12-default
6-sles12-sp0-x86_64
6-sles12-sp1-x86_64
6-sles12-sp2-x86_64
6-sles12-sp3-x86_64
6-sles12-sp4-x86_64
6-sles12-sp5-x86_64
6-sles15-sp0-x86_64
6-sles15-sp1-x86_64
6-sles15-sp2-x86_64
# mgr-bootstrap --traditional --script=My-New-SLES11-SP4.sh --activation-keys=6-sles11-sp4-x86_64
</source>

==Activation keys==
===List available activation keys===
web: Systems -> Activation Keys
<syntaxhighlight lang=bash>
# spacecmd -q activationkey_list
6-sles11-sp3-x86_64
6-sles11-sp4-x86_64
6-sles12-sp0-x86_64
6-sles12-sp1-x86_64
6-sles12-sp2-x86_64
6-sles12-sp3-x86_64
</source>

==spacecmd==
Just some useful space commands
<syntaxhighlight lang=bash>
# spacecmd system_list
</source>
==rhn-search==
===Cleanup the search index===
<syntaxhighlight lang=bash>
# rhn-search cleanindex
</source>


==Troubleshooting==
===Clients===
====Error code: Curl error 59 / Error message: failed setting cipher list: DEFAULT_SUSE====
<syntaxhighlight lang=bash>
# zypper refresh
...
Error code: Curl error 59
Error message: failed setting cipher list: DEFAULT_SUSE
...
</source>
The reason is that zypper in newer versions calls curl with a specific cipher list named "DEFAULT_SUSE" which is not defined in curl version 7.37.0-37.17.1 (version 7.37.0-28.1 is OK).


Now get any kind of repository bound to your SuSE like the ISO this version was installed with:
<syntaxhighlight lang=bash>
# zypper addrepo --check --type yast2 'iso:///?iso=/install/OS/suse/iso/SLE-12-SP2-Server-DVD-x86_64-GM-DVD1.iso' 'SLES12-SP2-12.2-0'
Adding repository 'SLES12-SP2-12.2-0' ...........................................................................................................[done]
Repository 'SLES12-SP2-12.2-0' successfully added
Enabled     : Yes                                                                      
Autorefresh : No                                                                       
GPG Check   : Yes                                                                      
Priority    : 99                                                                       
URI         : iso:///?iso=/install/OS/suse/iso/SLE-12-SP2-Server-DVD-x86_64-GM-DVD1.iso
</source>
or enable it:
<syntaxhighlight lang=bash>
# zypper modifyrepo --enable SLES12-SP2-12.2-0
</source>

Reinstall zypper in the old version that does not call curl with the cipher list SUSE_DEFAULT:
<syntaxhighlight lang=bash>
# zypper install --force --repo SLES12-SP2-12.2-0 $(rpm --query --all *curl* --queryformat '%{NAME} ')
</source>

And disable the ISO repository:
<syntaxhighlight lang=bash>
# zypper modifyrepo --disable SLES12-SP2-12.2-0
</source>

Done.

=====Note: After some further debugging we found that the system path forces a wrong openssl library to come in place.=====
<syntaxhighlight lang=bash>
# curl --version ; zypper --version
curl 7.37.0 (x86_64-suse-linux-gnu) libcurl/7.37.0 OpenSSL/1.0.2h zlib/1.2.8 libidn/1.28 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp 
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP 
zypper 1.13.40
</source>
In our version of curl it should be OpenSSL/1.0.2j.
<syntaxhighlight lang="bash" highlight="5">
# rpm -qv openssl
openssl-1.0.2j-60.24.1.x86_64
# openssl version
WARNING: can't open config file: /usr/local/ssl/openssl.cnf
OpenSSL 1.0.2j-fips  26 Sep 2016 (Library: OpenSSL 1.0.2h-fips  3 May 2016)

Ha! Ok... then after lookin at the system library path, we got a clue ;-): 

# ldconfig -p | grep ssl
	libssl.so.1.0.0 (libc6,x86-64) => /usr/lib/nsr/lib64/libssl.so.1.0.0
	libssl.so.1.0.0 (libc6,x86-64) => /lib64/libssl.so.1.0.0
	libssl.so.1.0.0 (libc6) => /usr/lib/nsr/libssl.so.1.0.0
	libgnutls-xssl.so.0 (libc6,x86-64) => /usr/lib64/libgnutls-xssl.so.0
	libevent_openssl-2.0.so.5 (libc6,x86-64) => /usr/lib64/libevent_openssl-2.0.so.5
	libcommonssl.so (libc6,x86-64) => /usr/lib/nsr/lib64/libcommonssl.so
	libcommonssl.so (libc6) => /usr/lib/nsr/libcommonssl.so
	libcommonssl-9.2.1.so (libc6,x86-64) => /usr/lib/nsr/lib64/libcommonssl-9.2.1.so

The problem was a file in /etc/ld.so.conf.d/ which brought /usr/lib/nsr/lib64 in the system library path. There was another libssl.so.1.0.0 which was version 1.0.2h. OK. What to do? <syntaxhighlight lang=bash>

  1. rm /etc/ld.so.conf.d/problematic.conf
  2. rm /etc/ld.so.cache
  3. ldconfig

</source> Check the success: <syntaxhighlight lang=bash>

  1. ldconfig -p | grep ssl

libssl.so.1.0.0 (libc6,x86-64) => /lib64/libssl.so.1.0.0 libgnutls-xssl.so.0 (libc6,x86-64) => /usr/lib64/libgnutls-xssl.so.0 libevent_openssl-2.0.so.5 (libc6,x86-64) => /usr/lib64/libevent_openssl-2.0.so.5 </source>

Now you just have to find a way to get your other stuff running without the manipulation at the system library path.

Last check for our case. Does our networker use it's own ssl libraries? <syntaxhighlight lang=bash>

  1. ls -al /proc/$(pgrep --full /usr/sbin/nsrexecd)/map_files | egrep "lib(ssl|crypto)"

lr-------- 1 root root 64 17. Jul 11:31 7f9d1bb73000-7f9d1bdc7000 -> /usr/lib/nsr/lib64/libcrypto.so.1.0.0 lr-------- 1 root root 64 17. Jul 11:31 7f9d1bdc7000-7f9d1bec7000 -> /usr/lib/nsr/lib64/libcrypto.so.1.0.0 lr-------- 1 root root 64 17. Jul 11:31 7f9d1bec7000-7f9d1bef3000 -> /usr/lib/nsr/lib64/libcrypto.so.1.0.0 lr-------- 1 root root 64 17. Jul 11:31 7f9d1bfab000-7f9d1c00c000 -> /usr/lib/nsr/lib64/libssl.so.1.0.0 lr-------- 1 root root 64 17. Jul 11:31 7f9d1c00c000-7f9d1c10c000 -> /usr/lib/nsr/lib64/libssl.so.1.0.0 lr-------- 1 root root 64 17. Jul 11:31 7f9d1c10c000-7f9d1c116000 -> /usr/lib/nsr/lib64/libssl.so.1.0.0 </source> Yep. Great!

Remove spacewalk from client

So the way to get rid spacewalk is: <syntaxhighlight lang=bash>

  1. zypper remove --clean-deps spacewalksd spacewalk-check zypp-plugin-spacewalk spacewalk-client-tools

</source>

Register at SuSE Manager

After that reregister your server with the SuSE Manager like this: <syntaxhighlight lang=bash>

  1. /usr/bin/wget --no-check-certificate -O - https://susemgr.server.tld/pub/bootstrap/yourbootstrap.sh | bash

</source>

Update SuSE Manager certificate

Create work place

<syntaxhighlight lang=bash>

  1. mkdir ~/ssl-build
  2. mkdir ~/ssl-build/$(hostname --short)
  3. cd ~/ssl-build

</source>

Build RHN-ORG-TRUSTED-SSL-CERT and rhn-org-trusted-ssl-cert-1.0-*.noarch.rpm

<syntaxhighlight lang=bash>

  1. rhn-ssl-tool --gen-ca --rpm-only --dir="~/ssl-build" --from-ca-cert=<path to your CA certificate file>
  2. openssl x509 -noout -subject -dates -in ~/ssl-build/RHN-ORG-TRUSTED-SSL-CERT

subject=C = DE, O = Hosting, CN = My-CA notBefore=Mar 22 12:28:05 2017 GMT notAfter=Mar 22 12:38:05 2027 GMT

  1. ls -al ~/ssl-build/*.rpm

... -rw-r--r-- 1 root root 18262 17. Nov 12:10 rhn-org-trusted-ssl-cert-1.0-17.noarch.rpm -rw-r--r-- 1 root root 16672 17. Nov 12:10 rhn-org-trusted-ssl-cert-1.0-17.src.rpm </source>

Generate CSR

<syntaxhighlight lang=bash>

  1. cd ~/ssl-build/$(hostname --short)
  2. declare -a hosts=( "susemgr.tld.de" "othername.tld.de" "anotheranothername.tld.de" )
  3. subject_without_cn='/C=DE/ST=Hamburg/L=Hamburg/O=Hosting/OU=Administration'
  4. emailAddress='suselinux-admin@tld.de'

</source> <syntaxhighlight lang=bash>

  1. openssl req -newkey rsa:4096 -nodes -sha256 -keyout server.key -out server.csr -batch -subj "${subject_without_cn}/CN=${hosts[0]}/emailAddress=${emailAddress}" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:${hosts[0]}${hosts[1]:+,DNS:${hosts[1]}}${hosts[2]:+,DNS:${hosts[2]}}${hosts[3]:+,DNS:${hosts[3]}}${hosts[4]:+,DNS:${hosts[4]}}"))

Generating a RSA private key ...............................................++++ .................................................................................................................................................................++++ writing new private key to 'server.key'

</source>

<syntaxhighlight lang=bash>

  1. openssl req -noout -verify -subject -in server.csr

verify OK subject=C = DE, ST = Hamburg, L = Hamburg, O = Hosting, OU = Administration, CN = susemgr.tld.de, emailAddress = suselinux-admin@tld.de </source>


Generate RPMs from certificate and key

<syntaxhighlight lang=bash>

  1. rhn-ssl-tool --gen-server --rpm-only --dir="/root/ssl-build"

...working...

Generating web server's SSL key pair/set RPM: 

   /root/ssl-build/susemgr/rhn-org-httpd-ssl-key-pair-susemgr-1.0-3.src.rpm
   /root/ssl-build/susemgr/rhn-org-httpd-ssl-key-pair-susemgr-1.0-3.noarch.rpm

The most current SUSE Manager Proxy installation process against SUSE Manager hosted requires the upload of an SSL tar archive that contains the CA SSL public certificate and the web server's key set.

Generating the web server's SSL key set and CA SSL public certificate archive: 

   /root/ssl-build/susemgr/rhn-org-httpd-ssl-archive-susemgr-1.0-3.tar

Deploy the server's SSL key pair/set RPM: 

   (NOTE: the SUSE Manager or Proxy installers may do this step for you.)
   The "noarch" RPM needs to be deployed to the machine working as a
   web server, or SUSE Manager, or SUSE Manager Proxy.
   Presumably 'susemgr.tld.de'.

</source>

Install certificate and key in the apache directories

<syntaxhighlight lang=bash>

  1. cd /root/ssl-build/susemgr
  2. rpm -i $(grep -E "rhn-org-httpd-ssl-key-pair-.*.noarch.rpm" latest.txt)

</source>


<syntaxhighlight lang=bash> </source>

<syntaxhighlight lang=bash> </source>

<syntaxhighlight lang=bash> </source>

Retrieved from "https://lars.timmann.de/wiki/index.php?title=SuSE_Manager&oldid=2306"