- ARCHIVED: Uyuni Development

[uyuni-devel] Thanks for the first Uyuni Community Open Hour!
by Jochen Breuer 29 May '20

29 May '20

Hi list! Many thanks to everybody who showed up to the very first Uyuni Community Open Hour! I counted at least 40 people! This clearly shows that there is more than enough demand to make this a regular thing and we'd be delighted to see you again in four weeks to continue and deepen the discussions! We'll make a calendar appointment available very soon, so that you won't miss it and there won't be timezone conversion issues again! Also we'd like to know if you'd be interested in us recording the meeting, so that you'd be able to revisit the discussions later or watch it if you weren't able to make it. Pics or it didn't happen!? Here we go! ;D https://i.imgur.com/BHNZWWu.png Have a nice weekend everybody! Jochen -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer -- To unsubscribe, e-mail: uyuni-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-devel+owner(a)opensuse.org

2 1

[uyuni-devel] Java import order config changes
by Cedric Bosdonnat 29 May '20

29 May '20

Hi fellow hackers, I have fixed the import order configuration file for Eclipse and the wiki for IntelliJ to avoid useless import order changes while switching editor in the commits. Action Items for everyone: * Eclipse Users: import the conf/eclipse/uyuni.importorder file in the import order config. Depending on your setup you may need to apply it in the project or the global settings. * IntelliJ Idea users: ensure you have a blank line between all import blocks. Note that there will still be changes while editing files that still have the old import order. Let's fix this while we edit files rather than in one go. The wiki pages for [0](Eclipse) and [1](IntelliJ) have been updated. [0]: https://github.com/uyuni-project/uyuni/wiki/Eclipse-specific-development-in… [1]: https://github.com/uyuni-project/uyuni/wiki/IntelliJ-IDEA-specific-developm… -- Cedric

1 0

[uyuni-devel] Uyuni Community Hours 29.05.2020
by Pau Garcia Quiles 26 May '20

26 May '20

Hello Uyuni Community Hours Fri, May 29, 2020 3:00 PM - 4:00 PM (CEST) Please join my meeting from your computer, tablet or smartphone. https://www.gotomeet.me/pagarcia/uyuni-community-hours You can also dial in using your phone. United States: +1 (646) 749-3129<tel:+16467493129,,446874869#> Access Code: 446-874-869 More phone numbers Australia: +61 2 9087 3604<tel:+61290873604,,446874869#> Austria: +43 7 2081 5427<tel:+43720815427,,446874869#> Belgium: +32 28 93 7018<tel:+3228937018,,446874869#> Brazil: +55 21 3500-3941<tel:+552135003941,,446874869#> Bulgaria: +359 2 906 0605<tel:+35929060605,,446874869#> Canada: +1 (647) 497-9391<tel:+16474979391,,446874869#> Chile: +56 2 3214 9680<tel:+56232149680,,446874869#> Colombia: +57 1 600 9953<tel:+5716009953,,446874869#> Czech Republic: +420 2 55 71 95 02<tel:+420255719502,,446874869#> Denmark: +45 43 31 47 82<tel:+4543314782,,446874869#> Finland: +358 923 17 0568<tel:+358923170568,,446874869#> France: +33 170 950 594<tel:+33170950594,,446874869#> Germany: +49 721 9881 4161<tel:+4972198814161,,446874869#> Greece: +30 21 0 300 2583<tel:+302103002583,,446874869#> Hungary: +36 1 933 3699<tel:+3619333699,,446874869#> Ireland: +353 16 572 651<tel:+35316572651,,446874869#> Israel: +972 3 376 3070<tel:+97233763070,,446874869#> Italy: +39 0 247 92 13 01<tel:+390247921301,,446874869#> Luxembourg: +352 34 2080 9219<tel:+3523420809219,,446874869#> Malaysia: +60 3 7724 4059<tel:+60377244059,,446874869#> Mexico: +52 55 3687 7278<tel:+525536877278,,446874869#> Netherlands: +31 207 941 377<tel:+31207941377,,446874869#> New Zealand: +64 9 280 6302<tel:+6492806302,,446874869#> Norway: +47 21 93 37 51<tel:+4721933751,,446874869#> Panama: +507 308 4334<tel:+5073084334,,446874869#> Peru: +51 1 642 9424<tel:+5116429424,,446874869#> Romania: +40 31 780 1158<tel:+40317801158,,446874869#> South Africa: +27 11 259 4924<tel:+27112594924,,446874869#> Spain: +34 932 75 2004<tel:+34932752004,,446874869#> Sweden: +46 853 527 827<tel:+46853527827,,446874869#> Switzerland: +41 435 5015 61<tel:+41435501561,,446874869#> Turkey: +90 212 900 4807<tel:+902129004807,,446874869#> United Kingdom: +44 330 221 0088<tel:+443302210088,,446874869#> Join from a video-conferencing room or system. Dial in or type: 67.217.95.2 or inroomlink.goto.com Meeting ID: 446 874 869 Or dial directly: 446874869(a)67.217.95.2 or 67.217.95.2##446874869 New to GoToMeeting? Get the app now and be ready when your first meeting starts: https://global.gotomeeting.com/install/446874869 Thank you Pau Garcia Quiles SUSE Manager Product Owner & Technical Project Manager SUSE Software Solutions Spain

2 2

[uyuni-devel] Uyuni Community Hours?
by Pau Garcia Quiles 26 May '20

26 May '20

Hello We are considering starting Uyuni Community Hours, open to the public. If you think it's an interesting idea, please complete this survey: https://bit.ly/2LxqMy0 Thank you Pau Garcia Quiles SUSE Manager Product Owner & Technical Project Manager SUSE Software Solutions Spain

1 1

[uyuni-devel] [IMPORTANT] Uyuni 2020.05 does not update all packages on the Server (manual step required)
by Julio González Gil 25 May '20

25 May '20

Hi everyone. We got reports at the uyuni-users that some packages, namely "spacewalk- backend-*" and "python3-psycopg2" were not being updated. The reason is that we need a temporary vendor change for "python3-psycopg2" as we provide an updated version for the repository syncing performance improvements, that should arrive to openSUSE Leap 15.1 in the following weeks. Sadly this information was missing at the original release notes, so we apologize for that. To fix it, after running "zypper update" you will need force the vendor change with > zypper in python3-psycopg2-2.8.4-2.1.uyuni.x86_64 Then update again again, so the spacewalk-backend subpackages are updated: > zypper update If you already updated to 2020.05, just stop the services with spacewalk- service, run the two steps above, and then start the services again. All other packages such as "lucene" can be ignored. The release notes at the website [1] are already updated (because of the release procedure, we can update the RPM packages for Stable), and we did an announcement at the website. A tweet at Twitter will follow soon. Thank you very much to Philippe Bidault and Cristian Gherman for reporting the issue and helping testing the fix. [1] https://www.uyuni-project.org/doc/2020.05/release-notes-uyuni-server.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

[uyuni-devel] Uyuni 2020.05 is released!
by Julio González Gil 21 May '20

21 May '20

Hello everyone! We are happy to announce the immediate availability of Uyuni 2020.05 At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2020.05, including the release notes, documentation, requirements and setup instructions. This is the list of highlights for this release: * Repository syncing performance improvements * Image profiles key-value pairs supported as arguments for Docker build * Service pack migrations: run a real migration after a successful dry-run Please check the release notes for full details. Remember that Uyuni will follow a rolling release planning, so the next version will contain bugfixes for this one and any new features. There will be no maintenance of 2020.05 As always, we hope you will enjoy Uyuni 2020.05 and invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/pages/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

[uyuni-devel] Uyuni at the openSUSE Virtual Summit (May 1st)
by Pau Garcia Quiles 30 Apr '20

30 Apr '20

Hello Today 01.05.2020 at 15:00 UTC, I will be giving a 30-min introductory talk about Uyuni at the openSUSE Virtual Summit 2020. Topics: where we are, what's next and opportunities for the community. https://events.opensuse.org/conferences/oSvirtsmt/program/proposals/3059 Thank you Pau Garcia Quiles SUSE Manager Product Owner & Technical Project Manager SUSE Software Solutions Spain

1 0

[uyuni-devel] RE: [uyuni-users] Uyuni 2020.04 is released!
by Pau Garcia Quiles 17 Apr '20

17 Apr '20

Hello I have built unofficial Uyuni 2020.04 Server and Proxy VM appliances for KVM and Xen, VMware, Hyper-V, VirtualBox, AWS EC2, Azure, GCE and OpenStack. https://build.opensuse.org/project/show/home:pagarcia:Uyuni:2020.04 Direct download: https://build.opensuse.org/package/binaries/home:pagarcia:Uyuni:2020.04/Uyu… https://build.opensuse.org/package/binaries/home:pagarcia:Uyuni:2020.04/Uyu… Thank you Pau Garcia Quiles SUSE Manager Product Owner & Technical Project Manager SUSE Software Solutions Spain ________________________________ De: Julio Gonzalez Enviado: Jueves, 16 de Abril de 2020 13:13 Para: uyuni-announce(a)opensuse.org; uyuni-users(a)opensuse.org; uyuni-devel(a)opensuse.org Asunto: [uyuni-users] Uyuni 2020.04 is released! Hello everyone! We are happy to announce the immediate availability of Uyuni 2020.04 At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2020.04, including the release notes, documentation, requirements and setup instructions. This is the list of highlights for this release: * Recurring actions * Bootstrapping Salt Clients with a Private SSH key (from API) * CentOS8 Content Lifecycle Management: Better Feedback with Appstreams * Automated Schema Database Upgrades and Failure Security Mechanism * Large Deployments Guide (draft) * Uyuni Hub documentation * Public Cloud QuickStart Guide (draft) * CaaSP Grafana Dashboads * Prometheus Federation Support in Formulas with Forms * Pre-configured default alerting rules * Prometheus Exporters for CentOS8 x86_64 * Node Exporter Updated to 0.18.1 * Virtualization: Management of storage pools Please check the release notes for full details. Remember that Uyuni will follow a rolling release planning, so the next version will contain bugfixes for this one and any new features. There will be no maintenance of 2020.04 As always, we hope you will enjoy Uyuni 2020.04 and invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/pages/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

2 1

[uyuni-devel] Uyuni 2020.04 is released!
by Julio González Gil 16 Apr '20

16 Apr '20

Hello everyone! We are happy to announce the immediate availability of Uyuni 2020.04 At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2020.04, including the release notes, documentation, requirements and setup instructions. This is the list of highlights for this release: * Recurring actions * Bootstrapping Salt Clients with a Private SSH key (from API) * CentOS8 Content Lifecycle Management: Better Feedback with Appstreams * Automated Schema Database Upgrades and Failure Security Mechanism * Large Deployments Guide (draft) * Uyuni Hub documentation * Public Cloud QuickStart Guide (draft) * CaaSP Grafana Dashboads * Prometheus Federation Support in Formulas with Forms * Pre-configured default alerting rules * Prometheus Exporters for CentOS8 x86_64 * Node Exporter Updated to 0.18.1 * Virtualization: Management of storage pools Please check the release notes for full details. Remember that Uyuni will follow a rolling release planning, so the next version will contain bugfixes for this one and any new features. There will be no maintenance of 2020.04 As always, we hope you will enjoy Uyuni 2020.04 and invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/pages/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

[uyuni-devel] tito is now available for Fedora, CentOS, Debian and Ubuntu
by Julio González Gil 20 Mar '20

20 Mar '20

Hi, While tito is a tool mostly used as a releasing tool to adjust the versions and changelogs of our packages, it is also used by a very useful tool that you can use during development. That tool is `rel-eng/build-packages-local-obs.sh`, and allows you to build packages locally without pushing them to OBS and even without branching anything. Quite useful to test packages before starting PRs. That tool requires tito, and that's the reason we decided to make tito available for Fedora, CentOS, Debian and Ubuntu. You can installing using the following repositories: CentOS7: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Utils/… CentOS8: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Utils/… Fedora30: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Utils/… Fedora31: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Utils/… FedoraRahide: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Utils/… Debian9: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Utils/… Debian10: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Utils/… DebianTesting: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Utils/… DebianUnstable: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Utils/… Ubuntu16.04: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Utils/… Ubuntu18.04: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Utils/… Ubuntu18.10: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Utils/… Ubuntu19.04: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Utils/… And you can see the builds at https://build.opensuse.org/project/show/systemsmanagement:Uyuni:Utils If you are using an old repository from Michael Calmer (https://download.opensuse.org/repositories/home:/mcalmer:/tito/), you can safely switch to the new one. The current repositories from Michael Calmer will be removed in a few weeks to allow the transition. NOTES: * Debian s390x and ppc64le for all versions is not building. Seems to an OBS problem. * Debian aarch64 and armv7l for Sid and Testing is not building. Seems to be an OBS problem. * Ubuntu Next is broken as some dependencies are not available (most probably the SPEC needs fixes) We will keep working to fix such architectures, but with low priority, so if you really need them, please join us fixing it :-) Enjoy! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

[uyuni-devel] Uyuni 2020.03 is released!
by Julio González Gil 19 Mar '20

19 Mar '20

Hello everyone! We are happy to announce the immediate availability of Uyuni 2020.03 At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2020.03, including the release notes, documentation, requirements and setup instructions. This is the list of highlights for this release: * Debian client tools * Content Lifecycle Filters for AppStreams (Appstream repositories can now be used to manage packages at the instances) * Recurring highstate scheduling * Automatic generation of bootstrap repositories * Ubuntu enhancements * Yomi (Technology Preview) * Uyuni Hub XML-RPC API (Technology Preview) * spacewalk-utils * EFI HTTP booting * SUSE Container as a Service Platform v4 nodes: action filtering * Subscription matching in public cloud: BYOS vs PAYG * Salt clients: provisioning API * New products enabled * Subscription matching enhancements * Single Sign-On (SSO) is now stable * Single Page Application UI (SPA) is now stable * Red Hat Enterprise Linux 8 onboarding simplified * Fix failures while setting up new servers due to a Tomcat change at openSUSE Leap 15.1 Please check the release notes for full details. Remember that Uyuni will follow a rolling release planning, so the next version will contain bugfixes for this one and any new features. There will be no maintenance of 2020.03 We hope you will enjoy Uyuni 2020.03 and invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/pages/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

[uyuni-devel] HTML e-mail?
by Pau Garcia Quiles 18 Mar '20

18 Mar '20

Hello Currently these lists only accept plain text e-mail and reject HTML mail. This is inconvenient and harms our community, specially newcomers whose e-mail client sends HTML mail by default (it's 2020, yes, HTML mail is the default for many clients). I have received complaints about this and I have been bitten by this myself. Is anyone against HTML mail? why? Please speak up until next Friday 13.03.2020. Thank you Pau Garcia Quiles SUSE Manager Product Owner & Technical Project Manager SUSE Software Solutions Spain Thank you Pau Garcia Quiles SUSE Manager Product Owner & Technical Project Manager Phone: +34 91 9018066 SUSE Software Solutions Spain -- To unsubscribe, e-mail: uyuni-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-devel+owner(a)opensuse.org

8 7

[uyuni-devel] Re: [Spacewalk-devel] Spacewalk on RHEL8 - Step 1 (of many) completed
by Pau Garcia Quiles 13 Mar '20

13 Mar '20

On dv, 2020-03-13 at 12:04 +0000, francisco.cardoso(a)gmail.com wrote: > I think the main issue with all this is going to be the brutal > fragmentation that’s going to be going forward. > Oracle has his own twisted fork of spacewalk that isn’t even a fork > by itself. > SUSE has SUSE Manager and Uyuni which are both based on the vanilla > Spacewalk project but at least they are giving something back. Actually, we SUSE are giving it all: the Uyuni codebase (and even docs base) is identical to SUSE Manager. The only difference is support. As a contributor to Uyuni, SUSE will focus on openSUSE/SUSE Linux Enterprise on the server side, and on the most popular distributions on the client side (e. g. Uyuni includes crazy clients stuff such as Springdale Linux -Princeton's clone of RHEL-, Astra Linux -Russian Debian-derivative-, etc; SUSE Manager also includes that -because the codebase is the same as Uyuni, we don't add or remove- but there is no support from SUSE, it's only community-supported) I said this when I presented Uyuni at CentOS Dojo in Brussels 6 weeks ago and I will repeat it again: we are open to run Uyuni Server and Proxy on other platforms (e. g. CentOS or Debian) if anyone is willing to contribute and maintain it. https://wiki.centos.org/Events/Dojo/Brussels2020 Same for governance: I would love to open it. Thank you Pau Garcia Quiles Product Owner & Technical Project Manager, SUSE Manager SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) N��r��y隊[��x�z��칻�&ޢ��'��-��w�zf��쮞'^��~� ޮ�^�ˬz��

1 0

[uyuni-devel] GSoC'20 aspirant
by Riya Kalra 12 Mar '20

12 Mar '20

Hello! I am Riya Kalra, a GSoC'20 aspirant. I wish to contribute to your organization. I am currently a second year student of B.Sc (hons) Computer Science. I am familiar with CPP, Java, HTML, CSS, JavaScript. After going through the list of projects, the project 'Improve Uyuni Documentation Publishing Theme #125' seems pretty interesting to me and my skills match with the required ones. I would like to work on this project.-- To unsubscribe, e-mail: uyuni-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-devel+owner(a)opensuse.org

2 1

[uyuni-devel] Introducing
by Naman Bhatia 10 Mar '20

10 Mar '20

Hello! I am Naman Bhatia, an aspirant of GsoC'20. I introduced myself on gitter channel of uyuni. After being guided, i went through project list and chose "Improving Documentation Publishing theme". I have had a look to the getting started links provided there. What should I do next. Please help me to take next step -- To unsubscribe, e-mail: uyuni-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-devel+owner(a)opensuse.org

2 2

[uyuni-devel]
by Naman Bhatia 10 Mar '20

10 Mar '20

-- To unsubscribe, e-mail: uyuni-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-devel+owner(a)opensuse.org

1 0

[uyuni-devel] New wiki page with Uyuni presentations
by Pau Garcia Quiles 20 Feb '20

20 Feb '20

Hello I have added a new page to the Uyuni wiki with links to past presentations about Uyuni, how to get started developing, etc: https://github.com/uyuni-project/uyuni/wiki/Presentations If there is any other presentation you would like to be linked, please tell me. Thank you Pau Garcia Quiles SUSE Manager Product Owner & Technical Project Manager SUSE Software Solutions Spain -- To unsubscribe, e-mail: uyuni-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-devel+owner(a)opensuse.org

1 0

[uyuni-devel] Uyuni accepted in Google Summer of Code 2020
by Pau Garcia Quiles 20 Feb '20

20 Feb '20

Hello We have been accepted in Google Summer of Code (look for the openSUSE organization, we are participating as an openSUSE project) This is the initial list of ideas we submitted: * Convert Virtual Systems page to ReactJS https://github.com/openSUSE/mentoring/issues/124 * Breakdown Uyuni into plugins architecture https://github.com/openSUSE/mentoring/issues/126 * Enhance Debian support https://github.com/openSUSE/mentoring/issues/127 * Add KDE support (co-mentored with KDE) https://github.com/openSUSE/mentoring/issues/128 * Improve Uyuni Documentation Publishing Theme https://github.com/openSUSE/mentoring/issues/125 We are still on time to add more ideas, please tell me (or add directly to the openSUSE mentoring GH repository) if you have something in mind. If you are a student and are interested in taking one of them, or have some other proposal, speak up! Also if you want to be a mentor. Thank you Pau Garcia Quiles SUSE Manager Product Owner & Technical Project Manager SUSE Software Solutions Spain -- To unsubscribe, e-mail: uyuni-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-devel+owner(a)opensuse.org

1 0

[uyuni-devel] Uyuni 2020.01 is released!
by Julio Gonzalez 31 Jan '20

31 Jan '20

Hello everyone! We are happy to announce the immediate availability of Uyuni 2020.01 As you can notice, we changed the version schema from X.Y to YYYY.MM. The reason is that this will allow us improve the releasing procedure, it will make things easier for users (as they will not need to change URLs for the repositories in the future), and will avoid mistakes with SUSE Manager versioning, which is using Uyuni as upstream. This means you need to CAREFULLY read the release notes, as they contain instructions for the setup of the new repositories for Server and Proxy that you need to follow before starting with the update. Repositories: - Server: https://download.opensuse.org/repositories/systemsmanagement:/ Uyuni:/Stable/images/repo/Uyuni-Server-POOL-x86_64-Media1/ - Proxy: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/ Stable/images/repo/Uyuni-Proxy-POOL-x86_64-Media1/ - openSUSE Leap 15.* (x86_64): https://download.opensuse.org/repositories/ systemsmanagement:/Uyuni:/Stable:/openSUSE_Leap_15-Uyuni-Client-Tools/ openSUSE_Leap_15.0/ - SLE12 (x86_64, pcc64le, s390x, aarch64): https://download.opensuse.org/ repositories/systemsmanagement:/Uyuni:/Stable:/SLE12-Uyuni-Client-Tools/ SLE_12/ - SLE15 (x86_64, pcc64le, s390x, aarch64): https://download.opensuse.org/ repositories/systemsmanagement:/Uyuni:/Stable:/SLE15-Uyuni-Client-Tools/SLE_15 - CentOS6 (i686, x86_64): https://download.opensuse.org/repositories/ systemsmanagement:/Uyuni:/Stable:/CentOS6-Uyuni-Client-Tools/CentOS_6/ - CentOS7 (x86_64): https://download.opensuse.org/repositories/ systemsmanagement:/Uyuni:/Stable:/CentOS7-Uyuni-Client-Tools/CentOS_7/ - CentOS8 (x86_64): https://download.opensuse.org/repositories/ systemsmanagement:/Uyuni:/Stable:/CentOS8-Uyuni-Client-Tools/CentOS_8/ - Ubuntu 16.04 (x86_64): https://download.opensuse.org/repositories/ systemsmanagement:/Uyuni:/Master:/Ubuntu1604-Uyuni-Client-Tools/xUbuntu_16.04/ - Ubuntu 18.04 (x86_64): https://download.opensuse.org/repositories/ systemsmanagement:/Uyuni:/Master:/Ubuntu1804-Uyuni-Client-Tools/xUbuntu_18.04/ At https://www.uyuni-project.org/stable-version.html you will find all the resources you need to start working with Uyuni 2020.01, including the release notes, documentation, requirements and setup instructions. This is the list of highlights for this release: - Version format change - CentOS8, RHEL 8 and SLES ES 8 support - Monitoring for Ubuntu 18.04, CentOS6, CentOS7 and Proxy. - Prometheus service autodiscovery - Grafana - New Prometheus exporters and formulas - Package Hub - Formulas with forms improvements - CPU mitigation formula - New Content Lifecycle Management filters - Enhanced support for Debian and Ubuntu - Subscription matching in Public Cloud - Preventive shutdown of Server when running out of disk space - Single Page Application UI - Updated documentation - New products enabled (from SCC) - SUSE Container as a Service Platform v4 support Please check the release notes for full details. Remember that Uyuni will follow a rolling release planning, so the next version will contain bugfixes for this one and any new features. There will be no maintenance of 2020.01 We hope you will enjoy Uyuni 2020.01 and invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

[uyuni-devel] Uyuni at CentOS Dojom FOSDEM and Config Management Camp
by Julio González Gil 29 Jan '20

29 Jan '20

Hello! There will be a few Uyuni-related talks and a workshop in Brussels and Ghent this weekend and next week. We will be happy to meet you there! ================================== CENTOS DOJO (31.01.2020, Brussels) ================================== Introduction to Uyuni and using Uyuni to manage CentOS ------------------------------------------------------ Pau Garcia Quiles (Product Owner & Technical Project Manager, SUSE Manager) https://wiki.centos.org/Events/Dojo/Brussels2020 Uyuni is a software-defined infrastructure and configuration management solution. It bootstraps physical servers, creates VMs for virtualization and cloud, deploys and updates packages -even with content lifecycle management features-, builds container images, and tracks what runs on your Kubernetes clusters. All using Salt under the hood. ================================ FOSDEM (01-02.02.2020, Brussels) ================================ Stand ----- https://fosdem.org/2020/stands/ We will be present at the openSUSE booth at building K, Level1. Come visit us! ============================================= CONFIG MANAGEMENT CAMP (03-05.02.2020, Ghent) ============================================= Presenting Yomi --------------- Alberto Planas (Developer, SUSE Future Technologies) https://cfp.cfgmgmtcamp.be/2020/talk/XPFAWX/ Yomi (Yet one more installer) is a new proposal for an OS installer that is build on top of the features that a Software Configuration Tool (StalStack) provides. In this talk we will present the objectives of the projects, the technical decisions done, how it works internally, and an small demo that will present the installation of MicroOS (transactional updates) and a normal openSUSE Tumbleweed with LVM/RAID. Installing dozens of systems with different hardware profiles, services and network configurations can be tricky without a formal approach to the problem. Yomi is a proposal for a new kind of installer that uses the mechanisms provided by your Software Configuration Management tool (in this case SaltStack), to drive in parallel and in unattended fashion the installation of multiple nodes in your network. From a DevOps PoV, this have the advantage that the installation process can be naturally integrated into the more general provisioning workflow, making of the discovery, bootstrap and redeployment of systems a more straightforward task. For a cluster/cloud management PoV (OpenStack, Kubernetes, etc), where the difference on hardware profiles of the nodes implies a different role in the cluster (compute nodes, control plane, storage), this king of installation will delegate decisions like partitioning (RAID, LVM, file system used), software and service configuration to the SCM tool in use. Running Ansible within Salt: Smoothly migrate away from Ansible to Salt ----------------------------------------------------------------------- Pablo Suárez Hernández (Developer, SUSE Manager) https://cfp.cfgmgmtcamp.be/2020/talk/7EUV3A/ At SUSE we firmly believe that Salt is the best choice for Configuration Management and Orchestration. We actively develop and integrate Salt as a core component of some of our products. Sometimes we face customers and users who chose Ansible as their Configuration Management engine. They invested time and efforts designing all states and playbooks to define their infrastructure. Then, at some point, they realize that with Salt they would have the same functionality and much more: real-time monitoring, reactors, event driven orchestration, superior flexibility, and more. The latest Fluorine release of Salt comes with a new module called ansiblegate which has been started by SUSE and allows a user to run Ansible from within Salt. You can execute any Ansible module directly using Salt and you can even reuse your own Ansible playbooks and apply them using Salt! Since many customers and users have invested time designing their Ansible states and playbooks, this session will show how Salt is able to run Ansible using ansiblegate. That will allow users to smoothly migrate away from Ansible by switching to Salt and reusing all their previous Ansible efforts plus adding all extra value that Salt brings into the scene. Manage Virtual Machines like Configuration with Salt ---------------------------------------------------- Cédric Bosdonnat (Developer, SUSE Labs) https://cfp.cfgmgmtcamp.be/2020/talk/HR39GE/ Virtual Machines are live things, but what if I want to manage them just like configuration? Salt helps you doing it by defining the VMs using states. This talk will be showing off how to leverage this feature. The talk will quickly walk through the basics of Salt states before exploring the virt state. Then we will see how Salt uses libvirt to get this done. Since this is also used by Uyuni, the session will provide an insight of a real-life use case. Workshop: Learn configuration management and SDI from scratch using Uyuni ------------------------------------------------------------------------- Pau Garcia Quiles (Product Owner & Technical Project Manager, SUSE Manager) Pablo Suárez Hernández (Developer, SUSE Manager) https://cfp.cfgmgmtcamp.be/2020/talk/FAYVSX/ Uyuni is a software-defined infrastructure and configuration management solution. You can use it to bootstrap physical servers, deploy and update packages and patches -even with content lifecycle management features- create VMs for virtualization and cloud, builds container images, tracks what runs on your Kubernetes clusters, CVE audit your machines and containers, etc. All using Salt under the hood! In this workshop we will start from scratch: install Uyuni, register some clients machines, deploy software, subscribe machine to software channels, learn how to use the content lifecycle management features, create and manage virtual machines, etc. -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

[uyuni-devel] Cobbler system add fails with exception
by Strahil Nikolov 07 Dec '19

07 Dec '19

Hello Community, I'm trying to setup a fully automated deployment with Uyuni and cobbler, but it seems that there is something wrong with my setup. When I run 'uyuni:/etc/cobbler # cobbler system add --help' Traceback (most recent call last): File "/usr/bin/cobbler", line 35, in <module> sys.exit(app.main()) File "/usr/lib/python3.6/site-packages/cobbler/cli.py", line 745, in main rc = cli.run(sys.argv) File "/usr/lib/python3.6/site-packages/cobbler/cli.py", line 358, in run self.object_command(object_type, object_action) File "/usr/lib/python3.6/site-packages/cobbler/cli.py", line 428, in object_command network_interface_fields, settings, object_action) File "/usr/lib/python3.6/site-packages/cobbler/cli.py", line 238, in add_options_from_fields _add_parser_option_from_field(parser, field, settings) File "/usr/lib/python3.6/site-packages/cobbler/cli.py", line 209, in _add_parser_option_from_field raise Exception("field %s default value (%s) is not listed in choices (%s)" % (name, default, str(choices))) Exception: field redhat_management_key default value (<<inherit>>) is not listed in choices (str) I got a traceback that 'redhat_management_key' default value is not listed in choices. My guess is that this should not happen,but my python skills are quite limited. As I have a separate NIC (separate VLAN) for the Uyuni's cobbler, I wanted to be able to pass in kickstart/autoyast 's script the network settings (via system variables) before powering off the machine. Then an automated process will change the VLAN (and PXE boot) of the client's NIC and will start it up. Once it's available, it will be bootstrapped and additional configuration can be done on the permanent address. Also, it seems that bootstrapping RHEL 7 via cobbler is failing, so that cannot be done during initial deployment. Most probably the 'spacewalk/redhat_register' snippet has an issue and cobbler is not expanding the it. Thanks for reading such a long post and any help is appreciated, maybe there is already a fix. If not - I can provide details in an issue. Best Regards, Strahil Nikolov -- To unsubscribe, e-mail: uyuni-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-devel+owner(a)opensuse.org

2 5

[uyuni-devel] New repository URLs for Uyuni Master/Develop Server and Proxy
by Julio Gonzalez 30 Oct '19

30 Oct '19

Hi everyone. The URLs for Uyuni Master (AKA Develop), Server and Proxy are now as follows: Server: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Master… Proxy: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Master… The reason for this change is that we plan to replicate this for Stable as well, so in the future changing the Uyuni version will not affect the repositories. I repeat, because this is important: this change does NOT affect Stable for now. When the time comes, we will warn about it at the mailing lists, and at the release notes (change does not affect Client Tools neither for Master/Develop or Stable, and will never affect them). # NEW INSTALLATIONS The website is now updated, so if you install a new Uyuni Master environment, you will be using the new URLs. # EXISTING INSTALLATIONS For existing installations, remember: those are NOT intended for production, and updating is NOT supported. Still, if you want to do things on your own then, at the server: 1. Update your `.repo` file for the server with the new URL. 2. Update at least `spacewalk-utils` package 3. Use `spacewalk-common-channels` to add the channels you need: uyuni-proxy- devel (and uyuni-server-devel if for some reason you already have the previous one). 4. If you don't need the previous channels, remove them: uyuni-proxy-devel- leap-151 (and uyuni-server-devel-leap-151 if for some reason you have it). Remember to remove the repositories as well. Best regards. -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

[uyuni-devel] Uyuni chat now available at Gitter!
by Julio Gonzalez 18 Oct '19

18 Oct '19

Hi all, We are now starting a PoC to consider moving our IRC channel at Freenode to Gitter. So as part of the PoC, our Gitter is now available at: https://gitter.im/uyuni-project/ Among other benefits, Gitter provides provide: - Rich text and files (and an easier way for people to provide commands, logs, etc). - Notifications - History (without bouncers). - Easy linking to GitHub issues. It also as an IRC gateway, for those that want to use an IRC client: https://irc.gitter.im/ We invite you all to join, and give it a try during the next two weeks. Meanwhile, we will be collecting feedback from you at Gitter, IRC and the uyuni-devel and uyuni-users mailing lists [1] With the experience and the feedback, we will decide in two weeks. Best regards, and have a nice weekend! [1] https://www.uyuni-project.org/pages/contact.html#ml -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

[uyuni-devel] Moving IRC channel to Gitter
by Julio Gonzalez 07 Oct '19

07 Oct '19

Hi all, We are considering moving our IRC channel at Freenode to Gitter. We would like to give it a try (meaning we'd keep both IRC and Gitter in parallel for some time), and mid-term replace it if we find the test satisfactory. Among other benefits, Gitter would provide: - Rich text and files (and an easier way for people to provide commands, logs, etc). - Notifications - History (without bouncers). - Easy linking to GitHub issues. But, before starting testing anything, we would like to know what our community thinks about it. Best regards. -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

[uyuni-devel] Building the Java code
by Cedric Bosdonnat 02 Sep '19

02 Sep '19

Hi all, Now it is possible to build the Java code without any dependency on SUSE R&D internal resources. Check this page for updated informations on how to setup your environment: https://github.com/uyuni-project/uyuni/wiki/Java-Development-Environment What actually changed? Before we were manually maintaining an Apache Ivy repository with the JAR files built from the openSUSE / SLE RPMs needed to build. Since Friday this is no longer needed, but you need to install a tiny script called obs-to-maven that will create such a repository locally out of OBS packages. You can install obs-to-maven for your distro from this repository: https://build.opensuse.org/package/show/systemsmanagement:Uyuni:Utils/obs-t… Then all you need to get the dependencies is to run: cd $UYUNI_SRC/java; ant -f manager-build.xml ivy All those instructions and how to setup your development environment is fairly well documented on the wiki page. Have fun! -- Cedric Bosdonnat N��r��y隊[��x�z��칻�&ޢ��'��-��w�zf��쮞'^��~� ޮ�^�ˬz��

1 0

[uyuni-devel] Re: [uyuni-users] Fwd: openSUSE 15.1 tools repo sync errors?
by Strahil Nikolov 23 Aug '19

23 Aug '19

On August 23, 2019 5:06:33 PM GMT+03:00, Boris Manojlovic <boris(a)steki.net> wrote: >kernel-default but it is multiple packages that will trigger this >(same update as in SLE SP1 in which i first noticed this issue with >this specific changelog entry ) > >sw:~ # cat /etc/*rele* >NAME="openSUSE Leap" >VERSION="15.1 " >ID="opensuse-leap" >ID_LIKE="suse opensuse" >VERSION_ID="15.1" >PRETTY_NAME="openSUSE Leap 15.1" >ANSI_COLOR="0;32" >CPE_NAME="cpe:/o:opensuse:leap:15.1" >BUG_REPORT_URL="https://bugs.opensuse.org" >HOME_URL="https://www.opensuse.org/" >Spacewalk release 4.0 (Smile) >sw:~ # rpm -q --changelog kernel-default |grep -A 5 -B1 >'reclaimed_journal_buckets' >* Mon Jul 15 2019 colyli(a)suse.de >- bcache: add reclaimed_journal_buckets to struct cache_set > (bsc#1140652). >- bcache: performance improvement for btree_flush_write() > (bsc#1140652). >- bcache: fix race in btree_flush_write() (bsc#1140652). >- bcache: remove retry_flush_write from struct cache_set >-- >* Mon Jul 15 2019 colyli(a)suse.de >- bcache: add reclaimed_journal_buckets to struct cache_set > (bsc#1140652). >- bcache: performance improvement for btree_flush_write() > (bsc#1140652). >- bcache: fix race in btree_flush_write() (bsc#1140652). >- bcache: remove retry_flush_write from struct cache_set >sw:~ # > >On Fri, Aug 23, 2019 at 12:46 AM Strahil Nikolov ><hunter86_bg(a)yahoo.com> wrote: >> >> >> On August 21, 2019 12:21:29 PM GMT+03:00, Boris Manojlovic ><boris(a)steki.net> wrote: >> >> >Hi list, >> > >> >reason why all of you had issues with updates from opensuse 15.1 is >> >kernel update that originated from suse sources (or someone made >> >exactly SAME kind of mistake) >> > >> >in source code (database code) you will find your mentioned unique >> >index creation code >> > >> >``` >> >CREATE UNIQUE INDEX rhn_pkg_clr_pid_cld_uq >> > ON rhnPackageChangeLogRec (package_id, changelog_data_id) >> > NOLOGGING >> > TABLESPACE [[32m_tbs]]; >> >``` >> > >> >so what happens in other part of code is next >> >get changelog data from rpm, insert it into db line by line (all >text >> >as one row per changelog entry ) >> >some other stuff in between >> >try adding rpm package changelog info into table as bellow >(arbitrary >> >values 10 and 3 just to show point) >> >``` >> >info into packagechangelogrec ( pkg_id=10 , chg_id=3 ,...); >> >info into packagechangelogrec ( pkg_id=10 , chg_id=3 ,...); <- >second >> >one fails with unique index problerm >> >` >> >insert will of course fail with given error (from log file pasted) >as >> >package has exactly same changelog entries. >> > >> >hope this helps someone in future to debug this kind of error >> > >> >P.S. >> >sorry for not responding to thread as is, simply was not subscribed >> >before :) >> > >> >P.P.S. >> > >> >Not sure list got it as i still did not confirm my subscription >before >> >sending... >> > >> > >> >Is it fixed, as I thought my Uyuni DB 'ended' and redeployed again >:) ? >> > >> >I will need to create all repos again. >> > >> >Best Regards, >> >Strahil Nikolov >> >> >> It's definitely not fixed: >> >> 01:39:50 01:39:50 Importing packages to DB: >Importing packages: >|--------------------------------------------------| 0.21% 01:41:24 >0.21 % Importing packages: >|--------------------------------------------------| 0.38% 01:42:40 >duplicate key value violates unique constraint "rhn_pkg_clr_pid_cld_uq" >DETAIL: Key (package_id, changelog_data_id)=(36047, 35803) already >exists. 01:42:40 Unexpected error: 01:42:40 Traceback (most recent call >last): File >"/usr/lib/python3.6/site-packages/spacewalk/satellite_tools/reposync.py", >line 568, in sync ret = self.import_packages(plugin, data['id'], >url, is_non_local_repo) File >"/usr/lib/python3.6/site-packages/spacewalk/satellite_tools/reposync.py", >line 1086, in import_packages importer.run() File >"/usr/lib/python3.6/site-packages/spacewalk/server/importlib/importLib.py", >line 764, in run self.submit() File >"/usr/lib/python3.6/site-packages/spacewalk/server/importlib/packageImport.py", >line 343, in submit transactional=self.transactional) File >"/usr/lib/python3.6/site-packages/spacewalk/server/importlib/backend.py", >line 853, in processPackages transactional=transactional) File >"/usr/lib/python3.6/site-packages/spacewalk/server/importlib/backend.py", >line 2158, in __processObjectCollection__ return self.__doDML(dml) >File >"/usr/lib/python3.6/site-packages/spacewalk/server/importlib/backend.py", >line 2263, in __doDML self.__doInsert(dml.insert, dml.tables) >File >"/usr/lib/python3.6/site-packages/spacewalk/server/importlib/backend.py", >line 2270, in __doInsert self.__doInsertTable(tname, dict) File >"/usr/lib/python3.6/site-packages/spacewalk/server/importlib/backend.py", >line 2285, in __doInsertTable insertObj.query(hash) File >"/usr/lib/python3.6/site-packages/spacewalk/server/importlib/backendLib.py", >line 459, in query executeStatement(statement, values, chunksize) >File >"/usr/lib/python3.6/site-packages/spacewalk/server/importlib/backendLib.py", >line 484, in executeStatement count += >statement.executemany(**tempdict) File >"/usr/lib/python3.6/site-packages/spacewalk/server/rhnSQL/sql_base.py", >line 159, in executemany return >self._execute_wrapper(self._executemany, *p, **kw) File >"/usr/lib/python3.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql.py", >line 298, in _execute_wrapper retval = function(*p, **kw) File >"/usr/lib/python3.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql.py", >line 348, in _executemany self._real_cursor.executemany(self.sql, >all_kwargs) psycopg2.IntegrityError: duplicate key value violates >unique constraint "rhn_pkg_clr_pid_cld_uq" DETAIL: Key (package_id, >changelog_data_id)=(36047, 35803) already exists. >> >> Does anyone know the names of the offending packages ? >> >> Best Regards, >> Strahil Nikolov >-- >To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org >To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org Adding uyuni-devel list. I hope someone in the dev can assist us. Best Regards, Strahil Nikolov -- To unsubscribe, e-mail: uyuni-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-devel+owner(a)opensuse.org

1 0

[uyuni-devel] Documentation Bug in Uyuni 4.0.2 Reference guide (PDF)
by Strahil Nikolov 05 Aug '19

05 Aug '19

Hello All, Can someone rebuild the reference guide for Uyuni 4.0.2 ,as there is a difference between the PDF and the HTML ? I have described the issue in : https://github.com/uyuni-project/uyuni-docs/issues/6 Best Regards, Strahil Nikolov -- To unsubscribe, e-mail: uyuni-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-devel+owner(a)opensuse.org

1 0

[uyuni-devel] New website and branding
by Julio Gonzalez 02 Aug '19

02 Aug '19

Together with the announcement of Uyuni 4.0.2 we are happy to present our new website and branding: https://www.uyuni-project.org/ You can also check the updated documentation as HTML, and with a search engine working at: https://www.uyuni-project.org/uyuni-docs/uyuni/index-uyuni.html What's more, you can even contribute to the documentation from there! We hope you will enjoy it, and we will be happy to receive your feedback and contributions. Happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

[uyuni-devel] Uyuni 4.0.2 is released!
by Julio Gonzalez 02 Aug '19

02 Aug '19

Hello everyone, We are happy to announce the immediate availability of Uyuni 4.0.2, our third Uyuni release! At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 4.0.2, including the release notes, documentation, requirements and setup instructions. ===================================== IMPORTANT: If you are migrating from 4.0.1 check the release notes [1], as a special procedure is needed for the server! ===================================== This is the list of highlights for this release: - Base system upgrade to openSUSE Leap 15.1 - Salt 2019.2.0 - Prometheus Monitoring - Content lifecycle management - Virtualization management for Salt minions - Updated Documentation Structure - Improved logging for Salt Remote Command Page - Support for more Distributions as Clients - EoL for openSUSE Leap 42.3 clients - Salt Rate Limiting (Batching) - Product Information Loaded from SCC - Image build host with SLES 12 SP4 - Updated backend for communicating with SCC - XMLRPC API changes - Support for Ubuntu Clients - Change behavior on token refresh - New option to force regeneration of channel metadata - New products supported - Package download endpoint override - Technical preview: Single Sign-On (SSO) Please check the release notes for full details. Remember that Uyuni follows a rolling release planning, so there will be no maintenance of 4.0.2, but a new version with bugfixes and most probably new features. We hope you will enjoy Uyuni 4.0.2 and invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/doc/4.0.2/release-notes-uyuni-server.html [2] https://www.uyuni-project.org/pages/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

[uyuni-devel] Re: [uyuni-users] need assistance with debugging bootstrap issues
by Strahil Nikolov 16 Jul '19

16 Jul '19

Hi Chris, thanks for your hint. I have tested adding a fresh openSUSE 15.1 and everything is fine until I have noticed that every minute the Uyuni is doing package refresh (8 refresh per minute) and never stops. Running it manually passes in 3.22s . Now I have to find the reason behind this constant running of package refresh. Adding uyuni-devel list. Best Regards, Strahil Nikolov В вторник, 9 юли 2019 г., 17:47:16 ч. Гринуич+3, Cristian Gherman <cristian.gherman(a)reea.net> написа: I had to change the id of minions in something: fe-1.blabla.com => fe-1-prod.blabla,com If I use previous names , they are not added to Uyuni any more. Cristian Gherman -------- Forwarded Message -------- Subject: Re: [uyuni-users] need assistance with debugging bootstrap issues Date: Tue, 9 Jul 2019 13:55:59 +0000 (UTC) From: Strahil Nikolov <hunter86_bg(a)yahoo.com> To: Cristian Gherman <cristian.gherman(a)reea.net> Hi Christian, thanks for the fast reply. Already done all of these. The new key is accepted , but the machines are not added. I even used "snapper" to rollback one of the VMs to openSUSE 15.0 in order to check bootstraping. The results are the same. Rebooting Uyuni doesn't solve the issue :) Any ideas appreciated. Best Regards, Strahil Nikolov В вторник, 9 юли 2019 г., 9:52:05 ч. Гринуич-4, Cristian Gherman <cristian.gherman(a)reea.net> написа: Hello, Can you try this: - remove minion key from master - stop the salt-minion on VM's - remove minion key from /etc/salt/pki/ - change the minion id in /etc/minion_id - change the machine id in /etc/machine-id with command systemd-machine-id-setup - start the salt-minion on VM's - accept new keys, check if minons is added on Uyuni This steps helped me with some stoborn minions some time ago. Cristian Gherman On 7/9/19 4:39 PM, Strahil Nikolov wrote: > Hello All, > can you assist me by guiding me in the correct direction? > Yesterday I found out that all my clients (4 openSUSE 15.1) are not reporting for the past 3 days.I tried to refresh , but it didn't do anything . > > Then I removed the VMs and tried to add them, but after accepting the salt key - the VM is not added as a system. > I have checked the logs and I see a lot of errors , one of them is : > 2019-07-09 16:26:24,719 [salt-event-thread-1] ERROR com.suse.manager.reactor.PGEventListener - Unexpected exception while executing a MessageAction com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was STRING at path $ > at com.google.gson.Gson.fromJson(Gson.java:900) > at com.google.gson.Gson.fromJson(Gson.java:953) > at com.suse.manager.reactor.messaging.JobReturnEventMessageAction.lambda$execute$7(JobReturnEventMessageAction.java:128) > at java.util.Optional.ifPresent(Optional.java:159) > at com.suse.manager.reactor.messaging.JobReturnEventMessageAction.execute(JobReturnEventMessageAction.java:114) > at com.suse.manager.reactor.PGEventListener.lambda$null$1(PGEventListener.java:74) > at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382) > at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580) > at com.suse.manager.reactor.PGEventListener.lambda$notify$2(PGEventListener.java:72) > at java.util.stream.Streams$StreamBuilderImpl.forEachRemaining(Streams.java:419) > at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580) > at com.suse.manager.reactor.PGEventListener.notify(PGEventListener.java:69) > at com.suse.salt.netapi.event.AbstractEventStream.notifyListeners(AbstractEventStream.java:64) > at com.suse.manager.reactor.PGEventStream.lambda$processEvents$3(PGEventStream.java:147) > at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) > at java.util.stream.SortedOps$SizedRefSortingSink.end(SortedOps.java:352) > at java.util.stream.Sink$ChainedReference.end(Sink.java:258) > at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:483) > at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472) > at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) > at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) > at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) > at com.suse.manager.reactor.PGEventStream.processEvents(PGEventStream.java:141) > at com.suse.manager.reactor.PGEventStream.lambda$null$0(PGEventStream.java:127) > at com.redhat.rhn.frontend.events.TransactionHelper.run(TransactionHelper.java:62) > at com.redhat.rhn.frontend.events.TransactionHelper.handlingTransaction(TransactionHelper.java:46) > at com.suse.manager.reactor.PGEventStream.lambda$notification$2(PGEventStream.java:126) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was STRING at path $ > at com.google.gson.internal.bind.JsonTreeReader.expect(JsonTreeReader.java:161) > at com.google.gson.internal.bind.JsonTreeReader.beginObject(JsonTreeReader.java:87) > at com.google.gson.internal.bind.MapTypeAdapterFactory$Adapter.read(MapTypeAdapterFactory.java:183) > at com.google.gson.internal.bind.MapTypeAdapterFactory$Adapter.read(MapTypeAdapterFactory.java:145) > at com.google.gson.Gson.fromJson(Gson.java:888) > ... 30 more > 2019-07-09 16:26:24,719 [salt-event-thread-4] ERROR com.redhat.rhn.frontend.events.TransactionHelper - java.lang.ClassCastException 2019-07-09 16:26:24,719 [salt-event-thread-4] ERROR com.redhat.rhn.frontend.events.TransactionHelper - Additional Exception during Exception handling java.lang.ClassCastException > 2019-07-09 16:26:24,720 [salt-event-thread-3] ERROR com.redhat.rhn.frontend.events.TransactionHelper - java.lang.ClassCastException 2019-07-09 16:26:24,719 [salt-event-thread-1] ERROR com.redhat.rhn.frontend.events.TransactionHelper - com.suse.manager.reactor.PGEventListenerException > 2019-07-09 16:26:24,720 [salt-event-thread-5] ERROR com.redhat.rhn.frontend.events.TransactionHelper - com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected NUMBER but was BEGIN_OBJECT at path $.retcode > > Any ideas how to debug this one? Which logs should I check ? > Maybe someone has already had a similar situation... > > Best Regards, > Strahil Nikolov -- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org -- To unsubscribe, e-mail: uyuni-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-devel+owner(a)opensuse.org

1 3

[uyuni-devel] Uyuni 4.0.1 Configuration files - schedule a check
by Strahil Nikolov 10 Jun '19

10 Jun '19

Hello Community, I have setup a system with a centrally managed configuration file (/etc/motd) and when applying high state - it gets deployed. I checked the taskomatic and there is a job for checking (compare-configs-default) which properly detects a difference from centrally managed file and local one . Can someone hint me , how can I schedule a task so the files that diff to be replaced with the centrally managed one (from uyuni) - so if I edit /etc/motd locally -> the file to be restored on a schedule ? If there is no such option , is it currently under development ? Thanks in advance. Best Regards, Strahil Nikolov -- To unsubscribe, e-mail: uyuni-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-devel+owner(a)opensuse.org

3 4

[uyuni-devel] Uyuni Master (development) is now based on openSUSE Leap 15.1
by Julio González Gil 05 Jun '19

05 Jun '19

Hello, In preparation for the next release of Uyuni, we switched the base OS for Master (the development version) Server and Proxy to openSUSE Leap 15.1 https://www.uyuni-project.org/devel-version.html is now updated showing this. For new installations, please use the new repositories. For older installations remember that updating is not supported, but if you still want to try, replace the repositories at /etc/zypper/repos.d and adjust your synced repositories the server. Please remember that Uyuni Master is intended for development and testing, and not for production. We cannot still give you an exact date for release of the next version, but we expect to have it ready in the next two to four weeks, and it will have big new features such as support for Ubuntu clients, monitoring with prometheus and grafana and much more. Stay tuned! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

[uyuni-devel] Feature request: Add missing Debian headers to repository metadata before signing
by Robert Paschedag 27 May '19

27 May '19

Hello Uyuni devel, this is a feature request for sysadmins, managing Debian / Ubuntu systems with Uyuni. Although there has been a lot of work to support Ubuntu / Debian, there is still some major thing missing. Several metadata headers are missing for Debian packages, that causes major issues on Debian / Ubuntu systems. One header is the "Multi-Arch" header, that is missing. This missing header causes packages to be installable over and over again. "apt" does not correctly "get it", that this package is already the newest installed and suggests these packages when searching for updates all the time. Also some dependencies cannot be successfully solved, because of this missing header. So the workaround most Debian / Ubuntu admins are doing right now, is to - sync the data into Uyuni - wait for spacewalk to generate the "Packages.gz" file - start - possibly below - script to add the missing "Multi-Arch" header to the "Packages.gz" file - sign the file Currently, I don't think that there are any efforts to tune the Uyuni database to also support the missing headers of Debian packages. So a further workaround could be to include such a script to add the missing headers "while or after" the "Packages.gz" gets created (or has been created), but before the file gets "signed". This could be added somewhere within the "DebRepositoryWriter.java" file, where the "signing" of the channel starts. First, I only had written a script to only add the "Multi-Arch" header. But this script below adds all headers missing for a packages. For this to work, you - of course - need the original "Packages.gz" file from Debian / Ubuntu with *all* headers present. Think about it. Would be cool, if this part could also be integrated into Uyuni. Just an idea and still used as workaround.... Best regards, Robert #!/usr/bin/env python -tt # Basically, this should only add one major header # 'Multi-Arch' to the Debian Packages file, but now # we add all missing headers. # # This only works correctly, if you are syncing the Debian repos # directly to one channel within Spacewalk or Uyuni # # You also need python-debian (which is installed on # Spacewalk server) to run this script # # Author: Robert Paschedag <robert.paschedag(a)netlution.de> # Version: 20181107 import sys import os from debian.deb822 import * if len(sys.argv) < 3: print "Usage: %s <path_to_unzipped_Packages_from_Spacewalk_Uyuni> <path_to_original_Debian_repo>" % sys.argv[0] sys.exit(1) spacewalk_file = sys.argv[1] original_file = sys.argv[2] if not os.path.isfile(spacewalk_file): print "Error: Inputfile '%s' not available." % spacewalk_file sys.exit(1) if not os.path.isfile(original_file): print "Error: Inputfile '%s' not available." % original_file sys.exit(1) spacewalk_packages = {} original_packages = {} with open(spacewalk_file, 'r') as pkgs: for pkg in Packages.iter_paragraphs(pkgs): spacewalk_packages[pkg['Package'] + pkg['Version'] + pkg['Architecture']] = pkg with open(original_file, 'r') as orig_file: for pkg in Packages.iter_paragraphs(orig_file): p = pkg['Package'] v = pkg['Version'] a = pkg['Architecture'] if spacewalk_packages.has_key(p + v + a): # found package. Check for missing headers for header in pkg.keys(): if not header in spacewalk_packages[p + v + a].keys(): spacewalk_packages[p + v + a][header] = pkg[header] # open new file new_package = open(spacewalk_file + '.new', 'w') for pkg in spacewalk_packages.values(): pkg.dump(new_package) new_package.write("\n") new_package.close() sys.exit(0) uyuni-test:/usr/local/sbin # -- To unsubscribe, e-mail: uyuni-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-devel+owner(a)opensuse.org

3 4

[uyuni-devel] Feature: Please add opensuse 15.1 to bootstrap
by Strahil Nikolov 25 May '19

25 May '19

Hello Users,Dev, I have modified my '/usr/share/susemanager/mgr_bootstrap_data.py' in order to bootstrap openSUSE Leap 15.1 , but it will be nice if in the next versions we have that out of the box.I haven't tested my modifications, but I will keep you updated. Do you see any issues with my modification? Here is what I got for openSUSE 15.X: openSUSE-Leap-15.0-x86_64' : { 'BASECHANNEL' : 'opensuse_leap15_0-x86_64', 'PKGLIST' : PKGLIST15 + PKGLIST15_NO_Z, 'DEST' : '/srv/www/htdocs/pub/repositories/opensuse/15/0/bootstrap/' }, 'openSUSE-Leap-15.1-x86_64' : { 'BASECHANNEL' : 'opensuse_leap15_1-x86_64', 'PKGLIST' : PKGLIST15 + PKGLIST15_NO_Z, 'DEST' : '/srv/www/htdocs/pub/repositories/opensuse/15/1/bootstrap/' }, Best Regards, Strahil Nikolov -- To unsubscribe, e-mail: uyuni-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-devel+owner(a)opensuse.org

2 2

[uyuni-devel] New RFC proposed: Migrating to DNF for managing RPM content
by Neal Gompa 04 Apr '19

04 Apr '19

Hey all, As I mentioned in my previous mail[0], I have been working on making Uyuni work on CentOS and Fedora servers. I was frustrated by the migration to Zypper, but now it became more serious than that. My recent experiments with integrating Fedora releases and RHEL 8 beta has become tremendously more difficult due to incomplete and improper handling of RH/Fedora modules. I've filed issues related to these two problems[1][2], but I've also decided to try to take advantage of the new RFC process introduced last month[3]. In order to fix these problems and to open the door to future features that would benefit people wanting to manage Linux distributions that use RH/Fedora modularity technology, I have proposed an RFC to migrate the underlying repository sync and dependency resolver code for RPM content to DNF[4]. The details about the proposal are in the pull request referenced. The highlights: * YUM is dead and removed in Fedora and DNF is officially part of RHEL/CentOS 7 now * Zypper and YUM both do the wrong things for handling new RH/Fedora releases. * DNF is available for SUSE distributions, with support for handling RH/Fedora modules * This should be a fairly painless migration, though there are a couple of open questions related to handling legacy metadata and some extra metadata. Please take a look! I'd greatly appreciate your feedback in the pull request. Thanks in advance and best regards, Neal [0]: https://lists.opensuse.org/uyuni-devel/2019-01/msg00000.html [1]: https://github.com/uyuni-project/uyuni/issues/804 [2]: https://github.com/uyuni-project/uyuni/issues/805 [3]: https://lists.opensuse.org/uyuni-devel/2019-03/msg00000.html [4]: https://github.com/uyuni-project/uyuni-rfc/pull/4 -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: uyuni-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-devel+owner(a)opensuse.org

1 0

[uyuni-devel] Build repositories for openSUSE 42.3
by Robert Paschedag 28 Mar '19

28 Mar '19

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-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-devel+owner(a)opensuse.org

2 5

[uyuni-devel] Uyuni RFCs are now available for the community
by Julio González Gil 21 Mar '19

21 Mar '19

Hello, We are happy to announce that all the RFCs (Requests For Comments) for Uyuni are now available at https://github.com/uyuni-project/uyuni-rfc As described at the repository: > The "RFC" (request for comments) process is intended to provide a consistent > and controlled path for such substantial changes to enter the project. This > process will be adjusted over time as more features are implemented and the > community settles on specific approaches to feature development. And as discussed at uyuni-devel mailing list [1], we are publishing not only so you can check those that already exist and are archived, but so the community can also participate in future RFCs. If you want to start a RFC, we strongly suggest starting an initial discussion at the uyuni-devel mailing list [2]. Remember that the procedure is described at the README.md file at https://github.com/uyuni-project/uyuni-rfc Next step will be managing all of our issues directly at the Uyuni repository (I will provide a schedule as soon as I have one). Happy hacking! [1] https://lists.opensuse.org/uyuni-devel/2019-02/msg00000.html [2] https://lists.opensuse.org/uyuni-devel -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

[uyuni-devel] About Uyuni development decisionmaking
by Neal Gompa 08 Feb '19

08 Feb '19

Hey all, So I've been following the development of Uyuni in parallel to the Spacewalk development for the past few months. I've been glad to see that both projects are showing a steady state of development, and Uyuni development is evenly paced. However, there have been some (IMO) major disappointments in how the development process for Uyuni is going, which all seem to stem from a foundational issue: It is fundamentally impossible for me to figure out what is going on as you guys are developing and merging in code. The main "symptoms" of this opaque development process: * Pull requests are referencing issues that exist in a private repository (SUSE/spacewalk), which presumably is the SUSE Manager codebase. This means that many pull requests have no context for external (i.e. non-SUSE) contributors to review. * Changes are being made with no obvious indicator of why they are happening, and the way the developers are committing to the codebase makes it impossible to divine any useful understanding. The style of just slamming out change after change with inscrutable commit messages really makes it hard to figure out what the meaningful change even is! * To my surprise, there is apparently an RFC process for figuring out major decisions. Unfortunately, external contributors have no opportunity to weigh in and help with those decisions. This is because that process is completely private and not open for public discussion. This means that by the time external contributors can react, it's already been implemented and there's no time anymore, which means we're stuck with a potentially bad decision due to incomplete information. Each of these things have happened during my time observing the Uyuni project. That said, it's not like Spacewalk is too much better, but we should aim for better no matter what! This most recently was a problem for me because I had been slowly examining the effort required to run Uyuni on Fedora and CentOS and I kept getting broken by changes done before I had any time to react. The most recent one completely broke everything for me[1], and had I known they were trying to decide on an approach to solve that, I would have given them a better strategy that would have worked on CentOS/RHEL 7, Fedora, openSUSE Leap 15.0, and SUSE Linux Enterprise 15. However, I didn't know until it was literally about to be merged, which is a terrible way to find these things out. This change exhibits the characteristics of all the problems I described earlier, because the way changes were done means that reverting this and doing it right will be extraordinarily painful _for me_, and it shows some callousness for the community, because we have no opportunity to be part of the project. Julio and Pablo (cc'd to this email) have already affirmed to me that they'll reconsider their approach so that this is unbroken. But this development process needs to change. It's too daunting for me to track and work with (and I'm pretty experienced at this stuff!). I worry that it's even scarier for people less versed in these kinds of projects. I know that in a lot of projects, I wind up being the token "community guy". And I'm okay playing that role for a while, if I can help make a project become good enough that it can start attracting a community to sustain itself. I've done this for a number of projects over the years, and I'm okay with doing this. But I don't want to be only community person forever, and the only way that will improve is if the development process improves. All the best, Neal [1]: https://github.com/uyuni-project/uyuni/pull/527 -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: uyuni-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-devel+owner(a)opensuse.org

3 3

[uyuni-devel] Client tools question
by Thomas Sundell 20 Dec '18

20 Dec '18

Hi, we are in the process of setting up a SES cluster and planning on using Uyuni to deploy SLES12 and provide SLES12+SES5 packages/patches using traditional client mode to our SES nodes. I'm trying to create a bootstrap repo but it complains about missing packages: mgr-create-bootstrap-repo -l 1. SLE-12-SP3-x86_64 mgr-create-bootstrap-repo -c SLE-12-SP3-x86_64 ERROR: package 'hwdata' not found ERROR: package 'libnewt0_52' not found ERROR: package 'newt' not found ... ERROR: package 'salt' not found ERROR: package 'salt-minion' not found ERROR: package 'python2-salt' not found My guess is that I need to setup "Client Tools" for SLE12 but I can't find anything about that in the documentation. Do I simply create a new channel with SLES12SP3-Pool as parent and add https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… as a repository to that channel or? Have a nice day! Thomas -- To unsubscribe, e-mail: uyuni-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-devel+owner(a)opensuse.org

4 7

[uyuni-devel] Uyuni 4.0.1 is released!
by Julio González Gil 20 Dec '18

20 Dec '18

Hello everyone, We are happy to announce the immediate availability of Uyuni 4.0.1, our second Uyuni release! Repositories: - Server: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… - Proxy: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… - openSUSE Leap 42.3 (x86_64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… - openSUSE Leap 15.0 (x86_64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… - SLE12 (x86_64, pcc64le, s390x, aarch64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… - SLE15 (x86_64, pcc64le, s390x, aarch64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… - CentOS6 (i686, x86_64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… - CentOS7 (x86_64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… At https://www.uyuni-project.org/stable-version.html you will find all the resources you need to start working with Uyuni 4.0.1, including the release notes, documentation, requirements and setup instructions. Remember you can find the update instructions at the Best Practices guide. This is the list of highlights for this release: - Support for PostgreSQL 10 - spacecmd: Support state channels (aka Salt Minion config channels) - spacecmd: New API calls and spacecmd commands to merge packages and errata. - spacewalk-common-channels: Support for Uyuni, Fedora 29 and cleanup - openSUSE Leap 42.3/15.0, SLE12/15 and CentOS6 have now full support as salt, salt-ssh and traditional clients (Client Tools are still Beta) - New products added to SCC syncing Please check the release notes for full details. Remember that Uyuni will follow a rolling release planning, so next version will be 4.0.2 with bugfixes and features, and there will be no maintenance of 4.0.1. We hope you will enjoy Uyuni 4.0.1 and invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/contact.html -- 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)

1 0

[uyuni-devel] Looking for a way to automate the first organization creation
by Stankowic, Christian 14 Nov '18

14 Nov '18

Hello Uyuni team! I'm currently writing a Chef cookbook for automating Uyuni test deployments. After installing Uyuni, the first organization still needs to be created using the web page. I understand that there is an automation tool spacecmd, but this seems not to work if no organization or admin user exist: # spacecmd org_create Spacewalk Username: Spacewalk Password: ERROR: Invalid credentials I figured out that entering no username/password does not work (also not via the .spacecmd/config file) - so therefore the error message seems legit. My question is now: how can I automate this? I cannot used the web page in an automated manner. Is there an option for the /root/setup_env.sh file? Thanks a lot in advance - also keep up the good work! Best wishes, Christian Stankowic

5 7

[uyuni-devel] Re: [uyuni-announce] Upgrade Question from Beta to Stable
by Julio González Gil 01 Nov '18

01 Nov '18

Hi Bernd, First of all, thanks for trying out Uyuni! I am moving this thread to uyuni-devel since list is supposed to be only for announces. Best regards. On jueves, 1 de noviembre de 2018 10:55:38 (CET) Bernd Helber wrote: > Hi Uyuni Team, > > impressed by the Stability of the Beta Product, > > i tried to give the Upgrade from Beta to Stable a Shot. > > > What i did so far... > > 1st removed the Beta Repos > > 2nd added the Uyuni Stable Reps > > 3rd Database Hot Backup from the Existing Installation. > > smdba backup-hot --backup-dir=/var/spacewalk/db-backup > > zypper dup (Vendor got changed succesfully) > > spacewalk-service stop > > Postgres was running as it should be. > > THe issue i had to face covers the Topic Schema Upgrade. > > > > # spacewalk-schema-upgrade > Schema upgrade: [susemanager-schema-3.2.10-320.1.2.develHead] -> > [susemanager-schema-4.0.2-1.1] > Searching for upgrade path to: [susemanager-schema-4.0.2-1.1] > Searching for upgrade path to: [susemanager-schema-4.0.2] > Searching for start path: [susemanager-schema-3.2.10-320.1.2] > Searching for start path: [susemanager-schema-3.2.10] > Was not able to find upgrade path in directory > [/etc/sysconfig/rhn/schema-upgrade]. > > Do you guys have an Advice for me, to get this fixed? > > With kind regards. > > Bernd Helber -- 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)

2 2

[uyuni-devel] Uyuni 4.0.0 is released!
by Julio González Gil 26 Oct '18

26 Oct '18

Hello everyone, We are happy to announce the immediate availability of Uyuni 4.0.0, our first Uyuni release! Repositories: - Server: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… - Proxy: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… - openSUSE Leap 42.3 (x86_64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Master… - openSUSE Leap 15.0 (x86_64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Master… - SLE12 (x86_64, pcc64le, s390x, aarch64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Master… - SLE15 (x86_64, pcc64le, s390x, aarch64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Master… - CentOS6 (i686, x86_64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Master… - CentOS7 (x86_64): https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Master… At https://www.uyuni-project.org/stable-version.html you will find all the resources you need to start working with Uyuni 4.0.0, including the release notes, documentation, requirements and setup instructions. For this first release, all the functionality of Uyuni Server and Uyuni proxy is ready, and only certain clients distributions have some functionality restricted, or untested (but most probably should work). We hope to test and fix everything during the following releases. Remember that Uyuni will follow a rolling release planning, so next version will be 4.0.1 with bugfixes and features, and there will be no maintenance of 4.0.0. If you are wondering why 4.0.0 if it is the first release, please the FAQ, as it explains everything: https://www.uyuni-project.org/faq.html#first-version We hope you will enjoy Uyuni 4.0.0 and invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/contact.html -- 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)

1 0

[uyuni-devel] Welcome to the uyuni-devel mailing list!
by Julio González Gil 14 Sep '18

14 Sep '18

This message serves to test that the list is working fine, and to give you a warm welcome! This is the list where we will be discussing Uyuni development stuff with all developers. Anyone can post to this list as long as it is registered. Enjoy! -- 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)

1 0