├── .gitignore ├── .gitmodules ├── Gemfile ├── Gemfile.lock ├── LICENSE ├── README.md ├── _config.yml ├── _data ├── projects.yml ├── requirements.yml └── requirements.yml.bak ├── _includes └── icons │ ├── chat.svg │ ├── chip.svg │ ├── chip.svg.bak │ ├── cpu.svg │ ├── documentation.svg │ ├── download.svg │ ├── github.svg │ ├── hdd.svg │ ├── hdd.svg.bak │ ├── idea.svg │ ├── install.svg │ ├── key.svg │ ├── lock.svg │ ├── mail.svg │ ├── shield.svg │ ├── spanner.svg │ ├── tool.svg │ ├── update.svg │ └── work.svg ├── assets ├── css │ └── app.css └── images │ ├── ARM_Logo.jpg │ ├── FullyAutomated.png │ ├── MicroOS_booted.png │ ├── ShorterRoleName.png │ ├── TransactionalRole.png │ ├── TransactionalScrenshot.png │ ├── cdfrdb-plot.png │ ├── certified-kubernetes-1.13-color.svg │ ├── certified-kubernetes-color.svg │ ├── criologo.svg │ ├── kata-horz-onwhite.png │ ├── kubeadm-intro │ ├── master-cni.png │ ├── master-firstrun-errors.png │ ├── master-initcomplete.png │ ├── master-login.png │ ├── master-nodes.png │ ├── master-secondrun.png │ ├── node-join.png │ ├── node-joined.png │ └── system-role.png │ ├── logo.svg │ ├── microos-logo.svg │ ├── symbolic.svg │ └── traefik_webui.jpeg ├── blog ├── _posts │ ├── 2018-03-22-introduction.md │ ├── 2018-03-25-podman.md │ ├── 2018-04-04-transactionalupdates.md │ ├── 2018-04-20-transactionalupdates2.md │ ├── 2018-07-09-kubicatosc18.md │ ├── 2018-08-09-newdirection.md │ ├── 2018-08-20-kubeadm-intro.md │ ├── 2018-09-17-crio-default.md │ ├── 2019-01-23-certified.md │ ├── 2019-01-24-traefik.md │ ├── 2019-01-30-kubiconaarch64.md │ ├── 2019-08-14-kata-in-tumbleweed.md │ ├── 2019-08-27-kubic-control-intro.md │ ├── 2019-10-22-toolbox.md │ ├── 2019-11-15-private-registry.md │ ├── 2019-12-05-usr-etc.md │ ├── 2020-01-15-k8s-117.md │ ├── 2020-02-04-quickboot.md │ ├── 2020-04-03-k8s-118.md │ ├── 2020-07-27-tmp_on_tmpfs.md │ ├── 2020-09-09-k8s-119.md │ ├── 2020-11-23-requirements.md │ ├── 2020-12-12-k8s-120.md │ ├── 2021-02-21-MicroOS-Kubic-Rancher-RKE.md │ ├── 2021-04-28-k8s-121.md │ ├── 2021-09-06-k8s-122.md │ ├── 2021-11-08-MicroOS-Keylime-TPM.md │ ├── 2022-05-05-NetworkManager-Wicked.md │ ├── 2022-06-10-kubic-retired.md │ └── _2018-03-20-template.markdown └── index.html ├── check.txt ├── documentation ├── man-pages │ ├── 90-issue-generator.rules.8.html │ ├── create_autoyast_profile.1.html │ ├── index.html │ ├── issue-add-ssh-keys.service.8.html │ ├── issue-generator.8.html │ ├── issue-generator.conf.8.html │ ├── issue-generator.service.8.html │ ├── issue.d.5.html │ ├── org.opensuse.RebootMgr.conf.8.html │ ├── rebootmgr.conf.5.html │ ├── rebootmgr.index.html │ ├── rebootmgr.service.8.html │ ├── rebootmgrctl.1.html │ ├── rebootmgrd.8.html │ ├── transactional-update.8.html │ ├── transactional-update.conf.5.html │ ├── transactional-update.index.html │ ├── transactional-update.service.8.html │ ├── transactional-update.timer.8.html │ └── tukit.conf.5.html ├── png │ ├── Workflow-After-Reboot.png │ ├── Workflow-Start.png │ ├── Workflow-Step2.png │ ├── Workflow-Step3.png │ ├── Workflow-Step4.png │ ├── Workflow-Step5.png │ └── Workflow-Without-Reboot.png └── transactional-update-guide │ ├── transactional-update.html │ ├── tu-author.html │ ├── tu-components.html │ ├── tu-copyright.html │ ├── tu-files.html │ ├── tu-howitworks.html │ ├── tu-introduction.html │ ├── tu-porting.html │ └── tu-setup.html ├── index.html └── release ├── latest-1.18.txt ├── latest-1.19.txt ├── latest-1.20.txt ├── latest-1.21.txt ├── latest-1.22.txt ├── latest-1.23.txt ├── latest-1.24.txt ├── latest-1.25.txt ├── latest-1.26.txt ├── latest-1.27.txt ├── latest-1.28.txt ├── latest-1.29.txt ├── latest-1.30.txt ├── latest-1.31.txt ├── latest-1.32.txt ├── latest-1.33.txt ├── latest-1.txt ├── latest.txt ├── stable-1.18.txt ├── stable-1.19.txt ├── stable-1.20.txt ├── stable-1.21.txt ├── stable-1.22.txt ├── stable-1.23.txt ├── stable-1.24.txt ├── stable-1.25.txt ├── stable-1.26.txt ├── stable-1.27.txt ├── stable-1.28.txt ├── stable-1.29.txt ├── stable-1.30.txt ├── stable-1.31.txt ├── stable-1.32.txt ├── stable-1.33.txt ├── stable-1.txt └── stable.txt /.gitignore: -------------------------------------------------------------------------------- 1 | .bundle/ 2 | .jekyll-cache/ 3 | .jekyll-metadata 4 | .sass-cache/ 5 | _site/ 6 | vendor/ 7 | -------------------------------------------------------------------------------- /.gitmodules: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kubic-project/kubic-o-o/79d1a7c4fa009a8cc5a92340a438da5f084fab70/.gitmodules -------------------------------------------------------------------------------- /Gemfile: -------------------------------------------------------------------------------- 1 | source "https://rubygems.org" 2 | gem "jekyll", "~> 4.1.1" 3 | gem 'jekyll-theme-opensuse', :git => 'https://github.com/opensuse/jekyll-theme.git' 4 | gem 'jekyll-feed' 5 | gem 'jekyll-paginate' 6 | -------------------------------------------------------------------------------- /Gemfile.lock: -------------------------------------------------------------------------------- 1 | GIT 2 | remote: https://github.com/opensuse/jekyll-theme.git 3 | revision: e630b4ec5f7d37ac5820e0827c91f3f87c2f638e 4 | specs: 5 | jekyll-theme-opensuse (0.7.0) 6 | jekyll 7 | jekyll-archives 8 | jekyll-paginate 9 | 10 | GEM 11 | remote: https://rubygems.org/ 12 | specs: 13 | addressable (2.7.0) 14 | public_suffix (>= 2.0.2, < 5.0) 15 | colorator (1.1.0) 16 | concurrent-ruby (1.1.6) 17 | em-websocket (0.5.1) 18 | eventmachine (>= 0.12.9) 19 | http_parser.rb (~> 0.6.0) 20 | eventmachine (1.2.7) 21 | ffi (1.13.1) 22 | forwardable-extended (2.6.0) 23 | http_parser.rb (0.6.0) 24 | i18n (1.8.3) 25 | concurrent-ruby (~> 1.0) 26 | jekyll (4.1.1) 27 | addressable (~> 2.4) 28 | colorator (~> 1.0) 29 | em-websocket (~> 0.5) 30 | i18n (~> 1.0) 31 | jekyll-sass-converter (~> 2.0) 32 | jekyll-watch (~> 2.0) 33 | kramdown (~> 2.1) 34 | kramdown-parser-gfm (~> 1.0) 35 | liquid (~> 4.0) 36 | mercenary (~> 0.4.0) 37 | pathutil (~> 0.9) 38 | rouge (~> 3.0) 39 | safe_yaml (~> 1.0) 40 | terminal-table (~> 1.8) 41 | jekyll-archives (2.2.1) 42 | jekyll (>= 3.6, < 5.0) 43 | jekyll-feed (0.15.0) 44 | jekyll (>= 3.7, < 5.0) 45 | jekyll-paginate (1.1.0) 46 | jekyll-sass-converter (2.1.0) 47 | sassc (> 2.0.1, < 3.0) 48 | jekyll-watch (2.2.1) 49 | listen (~> 3.0) 50 | kramdown (2.3.0) 51 | rexml 52 | kramdown-parser-gfm (1.1.0) 53 | kramdown (~> 2.0) 54 | liquid (4.0.3) 55 | listen (3.2.1) 56 | rb-fsevent (~> 0.10, >= 0.10.3) 57 | rb-inotify (~> 0.9, >= 0.9.10) 58 | mercenary (0.4.0) 59 | pathutil (0.16.2) 60 | forwardable-extended (~> 2.6) 61 | public_suffix (4.0.5) 62 | rb-fsevent (0.10.4) 63 | rb-inotify (0.10.1) 64 | ffi (~> 1.0) 65 | rexml (3.2.4) 66 | rouge (3.20.0) 67 | safe_yaml (1.0.5) 68 | sassc (2.4.0) 69 | ffi (~> 1.9) 70 | terminal-table (1.8.0) 71 | unicode-display_width (~> 1.1, >= 1.1.1) 72 | unicode-display_width (1.7.0) 73 | 74 | PLATFORMS 75 | ruby 76 | 77 | DEPENDENCIES 78 | jekyll (~> 4.1.1) 79 | jekyll-feed 80 | jekyll-paginate 81 | jekyll-theme-opensuse! 82 | 83 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # kubic-o-o 2 | 3 | This is the jekyll sources for the kubic.opensuse.org website 4 | 5 | ## How to contribute (Site Design) 6 | 7 | Fork the repository and make some changes. 8 | Once you're done with your changes send a pull request. 9 | 10 | To test your changes locally make sure to have the git submodules for the CSS and blog files calling `git submodule update --init`. 11 | 12 | Use `bundle exec jekyll serve` to provide a local webserver on which the visual representation of your changes can be seen. 13 | 14 | ## How to contribute (Blog Posts) 15 | 16 | Please fork and submit changes to https://github.com/kubic-project/blog 17 | -------------------------------------------------------------------------------- /_config.yml: -------------------------------------------------------------------------------- 1 | title: openSUSE Kubic - Retired 2 | title_short: Kubic - Retired 3 | email: opensuse-factory@opensuse.org 4 | description: Retired Kubernetes distribution & container-related technologies formerly built by the openSUSE community 5 | copyright: '© 2017–2022 openSUSE contributors' 6 | baseurl: "" 7 | url: "" 8 | plugins: 9 | - jekyll-feed 10 | - jekyll-paginate 11 | - jekyll-archives 12 | paginate: 10 13 | paginate_path: "/blog/page:num/" 14 | breadcrumb_icon: 15 | 16 | enable_feed: true 17 | 18 | navbar_links: 19 | - 20 | link: https://registry.opensuse.org/ 21 | text: Registry 22 | - 23 | link: https://en.opensuse.org/Portal:Container 24 | text: Container Documentation 25 | - 26 | link: /blog 27 | text: Blog 28 | - 29 | icon: 30 | link: /feed.xml 31 | text: RSS Feed 32 | 33 | footer_links: 34 | - 35 | text: Source Code 36 | link: https://github.com/kubic-project/kubic-o-o 37 | - 38 | text: License 39 | link: https://github.com/kubic-project/kubic-o-o/blob/master/LICENSE 40 | 41 | permalink: /blog/:year-:month-:day-:title/ 42 | 43 | theme: jekyll-theme-opensuse 44 | 45 | messages: 46 | categories: 'Categories' 47 | tags: 'Tags' 48 | months: 49 | - January 50 | - February 51 | - March 52 | - April 53 | - May 54 | - June 55 | - July 56 | - August 57 | - September 58 | - October 59 | - November 60 | - December 61 | share_this_post: Share this post 62 | 63 | jekyll-archives: 64 | enabled: all 65 | layout: 'archive' 66 | permalinks: 67 | year: '/:year/' 68 | month: '/:year/:month/' 69 | day: '/:year/:month/:day/' 70 | tag: '/tag/:name/' 71 | category: '/category/:name/' 72 | layouts: 73 | year: year-archive 74 | month: month-archive 75 | day: day-archive 76 | tag: cattag-archive 77 | category: cattag-archive 78 | 79 | # Exclude these files from production site 80 | exclude: 81 | - Gemfile 82 | - Gemfile.lock 83 | - README.md 84 | 85 | -------------------------------------------------------------------------------- /_data/projects.yml: -------------------------------------------------------------------------------- 1 | - name: Kubic Kubic Logo 2 | rundown: Certified Kubernetes Distribution based on openSUSE MicroOS 3 | description: >- 4 | Certified Kubernetes 5 | Kubernetes is an open-source system for automating deployment, scaling, and management of containerised applications. 6 | Kubic uses kubeadm to provide an easy way of configuring a Kubernetes cluster across multiple machines, while our MicroOS base keeps your operating system updated automatically, with fully atomic rollbacks if required. 7 | links: 8 | - name: Documentation 9 | link: https://en.opensuse.org/Portal:Kubic 10 | icon: documentation 11 | color: light 12 | - name: System Requirements 13 | link: '#hardware' 14 | icon: cpu 15 | color: primary 16 | - name: Downloads 17 | link: https://en.opensuse.org/Portal:Kubic/Downloads 18 | icon: download 19 | color: success 20 | - name: Report a Bug 21 | link: https://bugzilla.opensuse.org/enter_bug.cgi?product=openSUSE+Tumbleweed&component=Kubic&format=guided 22 | icon: spanner 23 | color: warning 24 | 25 | - name: MicroOS MicroOS Logo 26 | rundown: Micro Service OS providing Transactional (Atomic) Updates upon a read-only btrfs root filesystem 27 | description: >- 28 | Designed to host container workloads with automated administration & patching. 29 | Installing openSUSE MicroOS you get a quick, small environment for deploying Containers, or any other workload that benefits from Transactional Updates. As rolling release distribution the software is always up-to-date.
30 | Check out the MicroOS website for further information. 31 | 32 | - name: Containers 33 | rundown: A huge pool of freshly build images for your workload 34 | description: >- 35 | Our Container Registry offers a great choice of containers based on either openSUSE Kubic or plain Tumbleweed. Use them as a base for your project and be on the safe side by our automated rebuilds in Open Build Service to get security updates of your dependencies fast and easy – continuously tested by openQA. You can even publish your own project using the infrastructure around Open Build Service. 36 | links: 37 | - name: Documentation 38 | link: https://en.opensuse.org/Portal:Container 39 | icon: documentation 40 | color: light 41 | - name: Registry 42 | link: https://registry.opensuse.org/ 43 | icon: install 44 | color: success 45 | 46 | - name: And much much more 47 | rundown: Please contribute to our projects on Github, the Open Build Service, or join us in discussion at IRC and mailing list 48 | links: 49 | - name: Github 50 | link: https://github.com/kubic-project 51 | icon: github 52 | color: light 53 | 54 | - name: OBS 55 | link: https://build.opensuse.org/project/show/devel:kubic 56 | icon: spanner 57 | color: light 58 | 59 | - name: IRC 60 | link: irc://irc.opensuse.org/#kubic 61 | icon: chat 62 | color: primary 63 | 64 | - name: Mailing List 65 | link: https://lists.opensuse.org/opensuse-kubic/ 66 | icon: mail 67 | color: primary 68 | -------------------------------------------------------------------------------- /_data/requirements.yml: -------------------------------------------------------------------------------- 1 | - name: Memory 2 | icon: chip 3 | description: >- 4 | * minimum: 4 GB physical RAM 5 | 6 | * recommended: 8 GB or more 7 | 8 | * additional memory is needed for your workload 9 | 10 | * swap space **disabled** in order for kubernetes to work properly 11 | 12 | - name: Storage 13 | icon: hdd 14 | description: >- 15 | * / (root) partition: 5 GB available disk space minimum, 20 GB maximum 16 | 17 | * /var partition: 5 GB available disk space minimum, 40 GB or more recommended 18 | 19 | * increasing based on the needs of your container workloads 20 | 21 | * high write speed rate: SSD recommended 22 | 23 | - name: System 24 | icon: cpu 25 | description: >- 26 | * 2 CPUs or more 27 | 28 | * Full network connectivity between all machines in the cluster 29 | 30 | * Unique hostname and MAC address for every node 31 | -------------------------------------------------------------------------------- /_data/requirements.yml.bak: -------------------------------------------------------------------------------- 1 | - name: Memory Memory Icon 2 | description: >- 3 | * minimum 1 GB physical RAM 4 | 5 | * additional memory is needed for your workload 6 | 7 | - name: Storage Storage Icon 8 | description: >- 9 | * minimum 20 GB available disk space 10 | 11 | * recommended: 40GB or more 12 | 13 | * increasing based on the needs of your container workloads 14 | -------------------------------------------------------------------------------- /_includes/icons/chat.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | -------------------------------------------------------------------------------- /_includes/icons/chip.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | -------------------------------------------------------------------------------- /_includes/icons/chip.svg.bak: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | -------------------------------------------------------------------------------- /_includes/icons/cpu.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | -------------------------------------------------------------------------------- /_includes/icons/documentation.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | -------------------------------------------------------------------------------- /_includes/icons/download.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | -------------------------------------------------------------------------------- /_includes/icons/github.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | -------------------------------------------------------------------------------- /_includes/icons/hdd.svg: -------------------------------------------------------------------------------- 1 | 3 | 4 | 5 | -------------------------------------------------------------------------------- /_includes/icons/hdd.svg.bak: -------------------------------------------------------------------------------- 1 | 3 | 4 | 5 | -------------------------------------------------------------------------------- /_includes/icons/idea.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 20 | 22 | 24 | Lightbulb 26 | 31 | 32 | 33 | 51 | 53 | 54 | 56 | image/svg+xml 57 | 59 | 60 | 61 | 62 | 63 | 68 | 77 | 78 | 79 | -------------------------------------------------------------------------------- /_includes/icons/install.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | -------------------------------------------------------------------------------- /_includes/icons/key.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 19 | 21 | 39 | 41 | 42 | 44 | image/svg+xml 45 | 47 | 48 | 49 | 50 | 51 | 56 | 60 | key-stroke 62 | 67 | 68 | 69 | 70 | -------------------------------------------------------------------------------- /_includes/icons/mail.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | -------------------------------------------------------------------------------- /_includes/icons/shield.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 20 | 22 | 24 | security-high-symbolic 26 | 31 | 36 | 37 | 38 | 57 | 59 | 60 | 62 | image/svg+xml 63 | 65 | 66 | 67 | 68 | 69 | 74 | 83 | 84 | 85 | -------------------------------------------------------------------------------- /_includes/icons/spanner.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | -------------------------------------------------------------------------------- /_includes/icons/update.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 20 | 22 | 24 | Lightbulb 26 | 31 | 32 | 34 | Sun 36 | 41 | 42 | 44 | Share Square 46 | 51 | 52 | 53 | 71 | 73 | 74 | 76 | image/svg+xml 77 | 79 | 80 | 81 | 82 | 83 | 88 | 97 | 98 | 99 | -------------------------------------------------------------------------------- /_includes/icons/work.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 20 | 22 | 24 | system-run-symbolic 26 | 31 | 36 | 37 | 38 | 57 | 59 | 60 | 62 | image/svg+xml 63 | 65 | 66 | 67 | 68 | 69 | 74 | 83 | 84 | 85 | -------------------------------------------------------------------------------- /assets/css/app.css: -------------------------------------------------------------------------------- 1 | @import "{{ site.theme }}"; 2 | 3 | h1 svg.bi { 4 | color: var(--green); 5 | -------------------------------------------------------------------------------- /assets/images/ARM_Logo.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kubic-project/kubic-o-o/79d1a7c4fa009a8cc5a92340a438da5f084fab70/assets/images/ARM_Logo.jpg -------------------------------------------------------------------------------- /assets/images/FullyAutomated.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kubic-project/kubic-o-o/79d1a7c4fa009a8cc5a92340a438da5f084fab70/assets/images/FullyAutomated.png -------------------------------------------------------------------------------- /assets/images/MicroOS_booted.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kubic-project/kubic-o-o/79d1a7c4fa009a8cc5a92340a438da5f084fab70/assets/images/MicroOS_booted.png -------------------------------------------------------------------------------- /assets/images/ShorterRoleName.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kubic-project/kubic-o-o/79d1a7c4fa009a8cc5a92340a438da5f084fab70/assets/images/ShorterRoleName.png -------------------------------------------------------------------------------- /assets/images/TransactionalRole.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kubic-project/kubic-o-o/79d1a7c4fa009a8cc5a92340a438da5f084fab70/assets/images/TransactionalRole.png -------------------------------------------------------------------------------- /assets/images/TransactionalScrenshot.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kubic-project/kubic-o-o/79d1a7c4fa009a8cc5a92340a438da5f084fab70/assets/images/TransactionalScrenshot.png -------------------------------------------------------------------------------- /assets/images/cdfrdb-plot.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kubic-project/kubic-o-o/79d1a7c4fa009a8cc5a92340a438da5f084fab70/assets/images/cdfrdb-plot.png -------------------------------------------------------------------------------- /assets/images/criologo.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /assets/images/kata-horz-onwhite.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kubic-project/kubic-o-o/79d1a7c4fa009a8cc5a92340a438da5f084fab70/assets/images/kata-horz-onwhite.png -------------------------------------------------------------------------------- /assets/images/kubeadm-intro/master-cni.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kubic-project/kubic-o-o/79d1a7c4fa009a8cc5a92340a438da5f084fab70/assets/images/kubeadm-intro/master-cni.png -------------------------------------------------------------------------------- /assets/images/kubeadm-intro/master-firstrun-errors.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kubic-project/kubic-o-o/79d1a7c4fa009a8cc5a92340a438da5f084fab70/assets/images/kubeadm-intro/master-firstrun-errors.png -------------------------------------------------------------------------------- /assets/images/kubeadm-intro/master-initcomplete.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kubic-project/kubic-o-o/79d1a7c4fa009a8cc5a92340a438da5f084fab70/assets/images/kubeadm-intro/master-initcomplete.png -------------------------------------------------------------------------------- /assets/images/kubeadm-intro/master-login.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kubic-project/kubic-o-o/79d1a7c4fa009a8cc5a92340a438da5f084fab70/assets/images/kubeadm-intro/master-login.png -------------------------------------------------------------------------------- /assets/images/kubeadm-intro/master-nodes.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kubic-project/kubic-o-o/79d1a7c4fa009a8cc5a92340a438da5f084fab70/assets/images/kubeadm-intro/master-nodes.png -------------------------------------------------------------------------------- /assets/images/kubeadm-intro/master-secondrun.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kubic-project/kubic-o-o/79d1a7c4fa009a8cc5a92340a438da5f084fab70/assets/images/kubeadm-intro/master-secondrun.png -------------------------------------------------------------------------------- /assets/images/kubeadm-intro/node-join.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kubic-project/kubic-o-o/79d1a7c4fa009a8cc5a92340a438da5f084fab70/assets/images/kubeadm-intro/node-join.png -------------------------------------------------------------------------------- /assets/images/kubeadm-intro/node-joined.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kubic-project/kubic-o-o/79d1a7c4fa009a8cc5a92340a438da5f084fab70/assets/images/kubeadm-intro/node-joined.png -------------------------------------------------------------------------------- /assets/images/kubeadm-intro/system-role.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kubic-project/kubic-o-o/79d1a7c4fa009a8cc5a92340a438da5f084fab70/assets/images/kubeadm-intro/system-role.png -------------------------------------------------------------------------------- /assets/images/logo.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 21 | 23 | 24 | 26 | image/svg+xml 27 | 29 | 30 | 31 | 32 | 33 | 57 | 59 | 64 | 69 | 74 | 79 | 84 | 89 | 94 | 99 | 104 | 109 | 114 | 119 | 124 | 129 | 134 | 135 | -------------------------------------------------------------------------------- /assets/images/microos-logo.svg: -------------------------------------------------------------------------------- 1 | 2 | 18 | 20 | 21 | 23 | image/svg+xml 24 | 26 | 27 | 28 | 29 | 30 | 32 | 56 | 61 | 62 | -------------------------------------------------------------------------------- /assets/images/symbolic.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 21 | 23 | 24 | 26 | image/svg+xml 27 | 29 | 30 | 31 | 32 | 33 | 60 | 62 | 69 | 70 | 76 | 82 | 88 | 94 | 100 | 106 | 112 | 118 | 124 | 130 | 136 | 142 | 148 | 154 | 160 | 161 | -------------------------------------------------------------------------------- /assets/images/traefik_webui.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kubic-project/kubic-o-o/79d1a7c4fa009a8cc5a92340a438da5f084fab70/assets/images/traefik_webui.jpeg -------------------------------------------------------------------------------- /blog/_posts/2018-03-22-introduction.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Introduction to Kubic" 4 | date: 2018-03-22 13:33:00 +0000 5 | author: The Kubic Team 6 | --- 7 | Welcome to the webpage and inaugural blog post of the Kubic Project. This post should serve as a basic introduction to Kubic for anyone interested in what we're doing. 8 | 9 | 10 | 11 | # What is Kubic? 12 | 13 | The Kubic Project is a sub-project of the broader [openSUSE Project](https://www.opensuse.org). 14 | We're focused on new and emerging technologies surrounding containers. We're exploring, developing, adapting and integrating these technologies, helping bring them to the world of openSUSE and helping to improve them directly in their respective upstream projects. 15 | 16 | Many of these technologies also serve as upstreams for [SUSE's CaaS Platform](https://www.suse.com/products/caas-platform/) Product. 17 | 18 | # Why? 19 | 20 | To put it simply, because these technologies are *fun*. 21 | 22 | But to try and be a little serious, the ongoing trends with _Containers_, _Micro-Services_, and alternative methods of application delivery are disruptive and changing peoples' expectations. Instead of complicated manual setups, a growing number of apps & services are just a simple 'pull' away, and this changes what users need and expect from their operating systems & surrounding tooling. 23 | 24 | The Kubic Project aims to be at the forefront of these trends, taking the best of these new concepts and bringing them to openSUSE while also helping adjust openSUSE to best support these new technologies. 25 | 26 | # What are we working on? 27 | 28 | As of March 2018 we're currently working on: 29 | 30 | * Transactional Updates 31 | * MicroOS 32 | * Tumbleweed Kubic 33 | * Velum 34 | * Alternative Container Runtimes (CRI-O, Podman) 35 | * Rootless Containers 36 | 37 | As the world of containers moves very quickly, this list is bound to be incomplete and incorrect for readers in the future, but below is a brief summary of each to give a flavour of what we're working on. 38 | 39 | ## Transactional Updates 40 | 41 | [transactional-update](https://github.com/openSUSE/transactional-update) is a command-line tool that brings **atomic updates** to openSUSE & SUSE distributions. 42 | 43 | It leverages our long experience with `btrfs`, `zypper` and `snapper` to update a system _without touching the running system_. 44 | 45 | All package updates are prepared as a single operation in a btrfs snapshot. This snapshot is not used until the next reboot. 46 | Any problems can be _immediately rolled back_ by discarding this transactional snapshot and rebooting again, instantly returning the system to its working order. 47 | 48 | When coupled with a **read-only root filesystem**, users are left with a robust running operating system that they can be confident will not change in any way at all while it's running, and can be confidently returned to working order if updates have unintended side-effects. 49 | 50 | Transactional Updates with read-only root filesystem are currently available by default in Tumbleweed Kubic and will soon be available as an installation option in both [openSUSE Tumbleweed](https://en.opensuse.org/Portal:Tumbleweed) and [openSUSE Leap 15](https://en.opensuse.org/Portal:Leap). 51 | 52 | ## MicroOS 53 | 54 | [MicroOS](https://en.opensuse.org/Kubic:MicroOS) is the base system for Tumbleweed Kubic. 55 | It is an [openSUSE Tumbleweed](https://en.opensuse.org/Portal:Tumbleweed) derivative designed to run **containers** and optimised for **large deployments**. 56 | 57 | It includes both a read-only root filesystem and _fully automated_ transactional updates out of the box. Its development and release is fully aligned and tested as part of Tumbleweed, meaning any new Tumbleweed release automatically includes updates to Kubic's MicroOS. 58 | 59 | MicroOS can currently be installed as by selecting the _System Role_ when installing Tumbleweed Kubic. 60 | In the future we also intend to offer VM images. 61 | 62 | ## Tumbleweed Kubic 63 | 64 | [Tumbleweed Kubic](http://download.opensuse.org/tumbleweed/iso/openSUSE-Tumbleweed-Kubic-DVD-x86_64-Current.iso) is our **Container-as-a-Service Platform** using **Kubernetes** atop MicroOS. 65 | 66 | In addition to the _MicroOS System Role_, Tumbleweed Kubic currently offers the _Unconfigured Cluster Node_ role, allowing users to get started with setting up their own [Kubernetes Cluster](https://kubernetes.io/docs/getting-started-guides/scratch/#bootstrapping-the-cluster). 67 | 68 | In the future Tumbleweed Kubic will also offer a further streamlined and automated cluster configuration workflow based on _Velum_. 69 | 70 | ## Velum 71 | 72 | [Velum](https://github.com/kubic-project/velum) is our **Cluster Dashboard & Bootstrap Tool** which will allow you to: 73 | 74 | * Bootstrap a Kubernetes Cluster in a simple WebUI 75 | * Manage your cluster, including adding & removing nodes, monitor faulty nodes, etc. 76 | * Setup an update policy to help define when and how you want _Transactional Update_ to run across your cluster. 77 | 78 | Velum is under active development and we are hopeful to offer Tumbleweed Kubic images containing Velum in the near future. 79 | 80 | ## Alternative Container Runtimes 81 | 82 | We are currently investigating alternative container runtimes such as [CRI-O](http://cri-o.io/) and its companion tooling [Podman](https://github.com/projectatomic/libpod) as **more lightweight option** for running containers both within Kubernetes and as a stand-alone runtime. 83 | 84 | Both are already available in both Tumbleweed & Tumbleweed Kubic today. 85 | 86 | ## Rootless Containers 87 | 88 | This is a project that was spear-headed by our team (based on the work of the 89 | larger container community). The idea was to allow completely unprivileged 90 | users to create containers on their own machines using a standardised container 91 | runtime ([runc][runc]). We also wrote [umoci][umoci] which allows unprivileged 92 | (and privileged) users to operate easily on [OCI][oci] images. 93 | 94 | Currently the main interest being worked on (along with some of the containers 95 | community) is the ability to have unprivileged networking using TAP. This would 96 | (theoretically) push us closer to having the possibility of a rootless 97 | Kubernetes deployment. You can keep a close eye on 98 | [rootlesscontaine.rs][rootlesscontainers] if you're interested in more about 99 | this effort. 100 | 101 | Rootless containers already work flawlessly on all modern openSUSE 102 | distributions. 103 | 104 | 105 | [runc]: https://github.com/opencontainers/runc 106 | [umoci]: https://github.com/openSUSE/umoci 107 | [oci]: https://www.opencontainers.org 108 | [rootlesscontainers]: https://rootlesscontaine.rs 109 | 110 | # How can I get involved? 111 | 112 | Most importantly, like every openSUSE Project, Kubic is an open community. 113 | 114 | **We would like your help**. 115 | 116 | Our sources can be found on [GitHub](https://github.com/kubic-project). 117 | 118 | If you're interested in helping us on anything mentioned here, or have ideas on what we should be looking at, then please get in touch either on our [Mailing List](https://lists.opensuse.org/opensuse-factory/) or on IRC where you can find us in **#Kubic on Freenode**. 119 | -------------------------------------------------------------------------------- /blog/_posts/2018-03-25-podman.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Podman on openSUSE" 4 | date: 2018-03-25 07:53:00 +0000 5 | author: Valentin Rothberg 6 | --- 7 | ## Interested in the latest container technologies? 8 | 9 | Great, here is what the openSUSE community has been working on lately. 10 | 11 | Many of our users are interested in trying out alternatives to the Docker open-source engine, so we started having look at what the larger community has to offer and, in fact, there is quite some choice. In the context of Kubernetes, there are cri-containerd and CRI-O. Both projects have a vivid community and are ultimately aiming at serving the Kubelet in a more specialized and less heavy-weight way than running a feature-rich yet fat dockerd. Alternatives for a standalone container engine are, for instance, rkt and Podman. As you can see, there is a lot to talk about but in this article, I want to focus on Podman. 12 | 13 | ![CRI-O](/assets/images/criologo.svg) 14 | 15 | ## Introduction to Podman 16 | 17 | Podman, formerly known as kpod, is a comparatively young project that was introduced in mid 2017. Podman can be described in very simple terms by comparing it to the client of the Docker open-source engine. If you are familiar with the Docker command-line interface (CLI), then playing around with Podman should be a breeze as Podman’s CLI is a nearly verbatim copy of Docker’s CLI. In fact, there are rumors about some users aliasing it. 18 | 19 | Although there are some familiarities with the Docker open-source engine, Podman’s architecture is quite different. The architecture of the Docker open-source engine follows a strict client-server paradigm, which means that each command passed to the client gets translated into a remote procedure call, which is finally passed to the dockerd daemon, which in turn is talking to another daemon, containerd, which is responsible for the run-time and low-level management of containers. 20 | 21 | In contrast to the client-server paradigm, Podman follows a more lightweight approach by not requiring any heavy-weight daemon at all, but only a tiny layer taking care of monitoring tasks, such as logging. All container processes, in fact, are direct descendants of Podman. The more traditional fork/exec model of Podman reduces some complexity in terms of the steps required to get a container running. It can be used as any other standalone binary and thereby opens doors to some interesting use-cases, for instance, to integrate Podman directly into systemd unit files. Pretty exciting, isn’t it? 22 | 23 | ## Podman on openSUSE 24 | 25 | If you’re using openSUSE and want to try out Podman, you don’t need to bother building it on your own, you can simply install the package via `zypper install podman`. It’s part of the official repositories of openSUSE Tumbleweed. If you want to try out Podman on other versions of openSUSE, feel free to install it from software.opensuse.org. 26 | 27 | As soon as Podman is installed, we are ready to go. As I’ve mentioned before, Podman is a nearly 1:1 copy of the command-line interface of the Docker open-source engine. In my opinion, this is a wise decision as Docker’s CLI is the defacto standard; users are accustomed to this CLI and do not need to learn another workflow to achieve the very same thing. In the following, I will go through a few common commands and explain how we can use Podman and also how we can do some minor tweaks to make using it a little bit more convenient. 28 | 29 | ## Pulling an Image 30 | 31 | The ones familiar with the Docker CLI will not be surprised that pulling images can be done via `podman pull`. However, Podman does not default to using the official Docker registry for unqualified images, but I am going to show how we can work around that. First, we can always use the full reference if we want to pull an image, for instance `podman pull docker.io/library/opensuse:42.3`. But this can be annoying at times or might even break existing automation as we might just want to pull opensuse:42.3. However, we can work around that by adding “docker.io/library” to the search registries in the /etc/containers/registries.conf configuration file. With this tweak, Podman will first search in the specified registry namespace when pulling an image and we can use it as we are used to from using the Docker open-source engine. Search registries are a pretty cool feature and enable users to solve common issues when automation uses unqualified references on specific images or when the desired images reside in a specific namespace on a registry. 32 | 33 | ## Running a Container 34 | 35 | Again, there should be no surprise as a simple `podman run --rm -it opensuse/tumbleweed sh` will run an openSUSE Tumbleweed image, give us a shell and will finally remove the container as soon as we exit from it. Initially, DNS resolution did not work inside Podman containers on openSUSE as IP forwarding for network bridges was blocked by default by the firewall and had to be manually enabled by adding a specific forwarding rule to iptables. The issue was already known to Podman’s upstream community and they were already working on fixing the root cause in the CNI networking plugins. Nonetheless, the Podman maintainers kindly accepted and implemented the proposal to add a workaround to Podman to make it usable by default on openSUSE without manually adding iptables rules. Due to the weekly Podman releases and the instant feedback of the Podman maintainers, it took two days until the DNS issue was resolved for openSUSE users. Thanks to everybody involved for making this such a pleasant experience! 36 | 37 | ## Mounting a Container’s RootFS 38 | 39 | While at the time of writing not at all Docker commands are yet implemented (e.g., container restart), Podman offers some interesting additions. I am particularly excited about the ability to mount and unmount a container’s root filesystem via `podman mount ID` and `podman unmount ID` respectively. This is a really great feature for automation scenarios to quickly alter the filesystem. Another scenario we are currently working on is a zypper-less and RPM-less version of openSUSE images, where packages can be installed by mounting the container’s rootFS and use the host’s package manager (i.e., zypper) to perform the packaging tasks; similar to dnf’s –installroot flag. The outcome would be an even slimmer version of openSUSE images, usable to perform specialized utility functions. 40 | 41 | If you are interested in Podman, please check it out and let us and the upstream community know about your experience. Currently, we are evaluating ways to extend the concept of rootless containers (see [https://rootlesscontaine.rs](https://rootlesscontaine.rs)) to Podman and related tools and libraries, which would enable unprivileged users to build, run and modify containers and thereby cover more use-cases. There is plenty of fun ahead! -------------------------------------------------------------------------------- /blog/_posts/2018-04-20-transactionalupdates2.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Transactional Updates: Refinements & FAQ" 4 | date: 2018-04-20 17:04:00 +0200 5 | author: Richard Brown 6 | --- 7 | After our post a few weeks ago [announcing the availability of transactional updates in openSUSE Tumbleweed & Leap 15]({{ site.baseurl }}{% post_url blog/2018-04-04-transactionalupdates %}) we received a bunch of questions and feedback about this exciting feature. 8 | 9 | And of course we didn't rest on our laurels, and we've reacted by implementing as much as we can, as fast as we can. This post covers what we've done, and answers some of the common questions we got about this new feature in openSUSE. 10 | 11 | ## Renaming the system role 12 | 13 | When announcing the new system role that introduces Transactional Updates to the openSUSE distributions it was named **Server with Transactional Updates and Read-Only Root Filesystem**. 14 | 15 | ![Screenshot](/assets/images/TransactionalRole.png) 16 | *..it was quite a mouthful* 17 | 18 | The name was so long because the intent was to make it obvious that this way of patching a Server is different from the traditional `Server (Text Mode)` role. 19 | In retrospect we have realised that this was all far too long winded and have now renamed both roles in both openSUSE distributions for clarity. 20 | 21 | If you want to install a server that has a read-write root filesystem and is patched using the traditional `zypper` then you can now choose the installation option named **Server**. 22 | 23 | For a Server with a read-only root filesystem and patched with `transactional-update` you should now choose the much simpler named **Transactional Server** 24 | 25 | ![Screenshot](/assets/images/ShorterRoleName.png) 26 | *Simpler System Role Naming* 27 | 28 | ## Tuned up Package Selection 29 | 30 | Both the **Server** and **Transactional Server** roles were previously using the `Console` pattern from openSUSE as their default package selection. This pattern provides a number of useful console tools (like `emacs`) but is more than is needed for everyone who wants to use openSUSE as a server. So that has been corrected and both roles are based on the slimmer `Enhanced Base` pattern, which we're also actively working on trimming down to be as efficient as possible. We're aiming to ensure our installations have everything everyone needs to get started with an openSUSE server, but no more than is needed. 31 | 32 | ## Automatic Transactional Updates by Default 33 | 34 | In the **Transactional Server** role, we didn't plan to have `transactional-update` automatically running daily by default. Given the need for reboots to activate each update, our first thought was to avoid automatically rebooting peoples servers without their awareness. But the feedback on this topic has been very clear. Therefore on all installations by default both `transactional-update.timer` and `rebootmgr.service` are now **enabled by default**. 35 | 36 | The Transactional Server role now has **fully automated installation of updates** and will reboot between **0330 and 0500** in the morning after an update is installed by default. 37 | 38 | ![Screenshot](/assets/images/FullyAutomated.png) 39 | *Transactional Updates now automated by default* 40 | 41 | If you wish to modify the timing and behaviour of the reboots, please edit `/etc/rebootmgr.conf` accordingly. Or if you want to be wholly responsible for updating and rebooting your Transactional Servers yourself, feel free to disable the `transactional-server.timer` and `rebootmgr.service` systemd units as you see fit. 42 | 43 | ## Frequently Asked Questions 44 | 45 | **Q: Does rebooting take significantly longer when there is an update?** 46 | A: Not at all. Thanks to our use of `btrfs` and `snapper`, a system updated by `transactional-update` boots in the same time as a 'normal' openSUSE installation. Rollbacks also take only a fraction of a second to prepare and a reboot to take effect. 47 | 48 | **Q: Does transactional-update use the same repositories as zypper? Can I install any package I'd like?** 49 | A: Yes. Any packages built for your distribution of choice in both official and unofficial repositories should be installable via `transactional-update`. Repository management can be accomplished using `zypper` like regular openSUSE installations. There is the potential for a some packages to have issues installing on a read-only root filesystem. This would suggest a lack of compliance with openSUSE's established Packaging Guidelines, and if anyone discovers such package problems they should [Report a Bug](https://bugs.opensuse.org). 50 | 51 | **Q: Any current or future way of using this on a desktop system?** 52 | A: At the moment we're focusing our efforts on making sure this feature works really well for server use cases. But in practice nothing will prevent any user running `transactional-update pkg in $desktop-pattern-of-their-choice` and installing whatever desktop environment & software they would like. Some people have already done so, and we're sure openSUSE's desktop teams would consider contributions to make a Transactional openSUSE Desktop a great user experience out of the box. 53 | 54 | **Q: Can I use transactional-update without a read-only root filesystem?** 55 | A: Yes, `transactional-update` will work without a read-only root filesystem. However users who choose this approach should be aware that when they reboot their rootfs will be the one created at the time of the `transactional-update`. This potentially means losing any custom changes made in the time between the `transactional-update` and the `reboot`. Therefore the recommendation would be to immediately `reboot` after every update if you're not using a read-only filesystem. 56 | 57 | **Q: When can SUSE customers expect to see this make an appearance in a version of SUSE Linux Enterprise?** 58 | A: While this is a good question, as an openSUSE project we can't provide much of a reliable answer to that. `transactional-update` is already available in [SUSE's CaaS Platform](https://www.suse.com/products/caas-platform/) and we understand there may be some consideration for including this feature in SUSE Linux Enterprise 15 Service Pack 1. SUSE customers interested in this should contact their usual SUSE contact. 59 | 60 | **Q: How can I contribute?** 61 | A: Any changes are welcome to be suggested at the [transactional-update](https://github.com/openSUSE/transactional-update) or [rebootmgr](https://github.com/SUSE/rebootmgr) GitHub projects. If you have any other ideas or questions about Transactional Updates or the Kubic Project in general feel free to get in touch with us by joining our IRC Channel, **#kubic on irc.freenode.org** or by mailing the [openSUSE Factory Mailing list](mailto:opensuse-factory@opensuse.org). 62 | 63 | Thanks and *Have a Lot of Fun!* 64 | -------------------------------------------------------------------------------- /blog/_posts/2018-07-09-kubicatosc18.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Kubic at openSUSE Conference 2018" 4 | date: 2018-07-09 16:55:00 +0200 5 | author: Richard Brown 6 | --- 7 | A little over a month ago the openSUSE Project held its [annual main community conference](https://events.opensuse.org/conference/oSC18) in Prague. Of course Kubic project was there, and we had a number of talks covering a wide range of cool things going on with Kubic, and getting started with the Project. 8 | Thanks to the amazing work of the openSUSE Conference video team, all of these talks were recorded, so they can be shared with you all for your viewing pleasure. 9 | 10 | ## Your first steps with openSUSE Kubic 11 | 12 | Paul Gonin talked about how he is using Kubic and shares the basic steps he took to setup his system as a container host. 13 | 14 | 15 | 16 | ## Transactional Updates - Deep Dive 17 | 18 | Ignaz Forster gave a detailed deep dive of the Kubic Project's Transactional Update stack. How it works, the concepts behind it, packaging considerations required and comparisions to similar options available in other distributions. 19 | 20 | 21 | 22 | ## Atomic Bonds: openSUSE Kubic & SUSE CaaSP 23 | 24 | Richard Brown and Alexander Herzig detailed from a high level the shared concepts behind the openSUSE Kubic Project and SUSE Container as a Service Platform, and details how the open source project and SUSE's commercial product work together for mutual benefit. 25 | 26 | 27 | 28 | ## OpenFaaS 29 | 30 | And last (but by no means least) Panos Georgiadis gave a (worlds first?) 'Presentationless' presentation about Serverless & Function-as-a-Service, with a demo showing how to set up such an environment for yourself. 31 | 32 | -------------------------------------------------------------------------------- /blog/_posts/2018-09-17-crio-default.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "CRI-O is now our default container runtime interface" 4 | date: 2018-09-17 15:18:00 +0200 5 | author: Richard Brown 6 | --- 7 | 8 | ![CRI-O](/assets/images/criologo.svg) 9 | 10 | We're really excited to announce that as of today, we now officially supports the CRI-O Container Runtime Interface as our default way of interfacing with containers on your Kubic systems! 11 | 12 | ## Um that's great, but what is a Container Runtime Interface? 13 | 14 | Contrary to what you might have heard, there are more ways to run containers than just the `docker` tool. In fact there are an increasing number of options, such as `runc`, `rkt`, `frakti`, `cri-containerd` and more. Most of these follow the [OCI](https://www.opencontainers.org/) standard defining how the runtimes start and run your containers, but they lack a standard way of interfacing with an orchestrator. This makes things complicated for tools like kubernetes, which run on top of a container runtime to provide you with orchestration, high availability, and management. 15 | 16 | Kubernetes therefore introduced a standard API to be able to talk to and manage a container runtime. This API is called the [Container Runtime Interface (CRI)](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/). 17 | 18 | Existing container runtimes like Docker use a "shim" to interface between Kubernetes and the runtime, but there is another way, using an interface that was designed to work with CRI natively. And that is where CRI-O comes into the picture. 19 | 20 | ## Introduction to CRI-O 21 | 22 | Started little over a year ago, CRI-O began as a Kubernetes incubator project, implementing the CRI Interface for OCI compliant runtimes. Using the lightweight `runc` runtime to actually run the containers, the simplest way of describing CRI-O would be as a lightweight alternative to the Docker engine, especially designed for running with Kubernetes. 23 | 24 | As of [6th Sept 2018](https://twitter.com/fatherlinux/status/1037810496643244039) CRI-O is no longer an incubator project, but now an official part of the Kubernetes family of tools. 25 | 26 | ## Why CRI-O? 27 | 28 | There are a lot of reasons the Kubic project love CRI-O, but to give a **Top 4** some of the largest reasons include: 29 | 30 | - **A Truly Open Project:** As already mentioned, CRI-O is operated as part of the broader Kubernetes community. There is a [broad collection](https://github.com/kubernetes-sigs/cri-o/graphs/contributors) of contributors from companies including Red Hat, SUSE, Intel, Google, Alibaba, IBM and more. The project is run in a way that all these different stakeholders can actively propose changes and can expect to see them merged, or at least spur steps into that direction. [This is harder to say of other similar projects](https://github.com/moby/moby/pull/34319). 31 | - **Lightweight:** CRI-O is made of lots of small components, each with specific roles, working together with other pieces to give you a fully functional container experience. In comparison, the Docker Engine is a heavyweight daemon which is communicated to using the `docker` CLI tool in a client/server fashion. You need to have the Daemon running before you can use the CLI, and if that daemon is dead, so is your ability to do anything with your containers. 32 | - **More Securable:** Every container run using the Docker CLI is a 'child' of that large Docker Daemon. This complicates or outright prevents the use of tooling like cgroups & security constraints to provide an extra layer of protection to your containers. As CRI-O containers are children of the process that spawned it (not the daemon) they're fully compatible with these tools without complication. This is not only cool for Kubernetes, but also when using CRI-O with Podman, but more about that later... 33 | - **Aligned with Kubernetes:** As an official Kubernetes project, CRI-O releases in lock step with Kubernetes, with similar version numbers. ie. CRI-O 1.11.x works with Kubernetes 1.11.x. This is hugely beneficial for a project like Kubic where we're rolling and want to keep everything working together at the latest versions. On the other side of the fence, Kubernetes currently only officially supports Docker versions 17.03.x, now well over 1 year old and far behind the 18.06.x version we currently have in Kubic. 34 | 35 | ## CRI-O and Kubernetes 36 | 37 | Given one of the main roles of Kubic is to run Kubernetes, as of today, Kubic's **kubeadm system role** is now designed to use CRI-O by default. 38 | 39 | [Our documentation has been updated](https://en.opensuse.org/Kubic:kubeadm) to reflect the new CRI-O way of doing things. 40 | 41 | The simplest way of describing it would be that we now have less steps than [before]({{ site.baseurl }}{% post_url blog/2018-08-20-kubeadm-intro %}). 42 | **You can now initialise your master node with a single command immediately after installation.** 43 | But you need to remember to add `--cri-socket=/var/run/crio/crio.sock` to your `kubeadm init` and `join` commands. *(We're looking into ways to streamline this)*. 44 | 45 | ## CRI-O and MicroOS 46 | 47 | Kubic is about more than Kubernetes, and our **MicroOS system role** is a perfect platform for running containers on stand-alone machines. That too now includes CRI-O as it's default runtime interface. 48 | 49 | In order to make use of CRI-O without Kubernetes, you need a command-line tool, and that tool is known as `podman`. It is now installed by default on Kubic MicroOS. 50 | 51 | ## Podman 52 | 53 | [Podman]({{ site.baseurl }}{% post_url blog/2018-03-25-podman %}) has been available in Tumbleweed & Kubic for some time. Put simply, it is to CRI-O what the Docker CLI tool is to the Docker Engine daemon. It even has a very similar syntax. 54 | 55 | - Use `podman run` to run containers in the same way you'd expect from `docker run` 56 | - `podman pull` pulls containers from registries, just like `docker pull`, and by default our `podman` is configured to use the same Docker Hub as many users would expect. 57 | - Some `podman` commands have additional functionality compared to their `docker` equivalents, such as `podman rm --all` and `podman rmi --all` which will remove all of your containers and their images respectively. 58 | - [A full crib-sheet of podman commands and their docker equivalents is available](https://github.com/containers/libpod/blob/master/transfer.md) 59 | 60 | Podman also benefits from CRI-Os more lightweight architecture. Because every Podman container is a direct child of the `podman` command that created it, it's trivial to use `podman` as part of systemd services. This be combined with systemd features like socket activation to do really cool things like starting your container only when users try to access it! 61 | 62 | ## What about Docker? 63 | 64 | As excited as we are about CRI-O and Podman, we're not blind to the reality that many users just won't care and will be more comfortable running the well known `docker` tool. 65 | 66 | For the basic use case of running containers, both `docker` and `podman` can co-exist on a system safely. Therefore it will still be available and installed by default on Kubic **MicroOS**. 67 | If you wish to remove it, just run `transactional-update pkg rm -u docker-kubic` and reboot. 68 | 69 | The Docker Engine doesn't co-exist with CRI-O quite so well in the Kubernetes scenario, so we do not install both by default on the **kubeadm system role**. 70 | We still wish to support users wishing to use the Docker Engine with Kubernetes. Therefore to swap from CRI-O to the Docker Engine just run `transactional-update pkg in patterns-caasp-alt-container-runtime -cri-o-kubeadm-criconfig` and reboot. 71 | 72 | Alternatively if you're installing Kubic from the installation media you can deselect the "Container Runtime" and instead choose the "Alternative Container Runtime" pattern from the "Software" option as part of the installation. 73 | 74 | Regardless of which runtime you choose to use, thanks for using Kubic and please join in, send us your feedback, code, and other contributions, and remember, **have a lot of fun!**. 75 | -------------------------------------------------------------------------------- /blog/_posts/2019-01-23-certified.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Kubic is now a certified Kubernetes distribution" 4 | date: 2019-01-23 00:21:00 +0200 5 | author: Richard Brown 6 | --- 7 | 8 | Certified Kubernetes 9 | 10 | The openSUSE Kubic team is proud to announce that as of [yesterday](https://github.com/cncf/k8s-conformance/pull/445), our Kubic distribution has become a Certified Kubernetes Distribution! Notably, it is **the first open source Kubernetes distribution to be certified using the [CRI-O container runtime](https://cri-o.io/)**! 11 | 12 | # What is Kubernetes Certification? 13 | 14 | Container technologies in general, and Kubernetes in particular, are becoming increasingly common and widely adopted by enthusiasts, developers, and companies across the globe. A [large ecosystem](https://landscape.cncf.io/format=landscape) of software and solutions is evolving around these technologies. More and more developers are thinking "Cloud Native" and producing their software in containers first, often targeting Kubernetes as their intended platform for orchestrating those containers. And put bluntly, they want their software to work. 15 | 16 | But Kubernetes isn't like some other software with this sort of broad adoption. Even though it's being used in scenarios large and small, from small developer labs to large production infrastructure systems, Kubernetes is still a fast-moving project, with new versions appearing very often and a support lifespan shorter than other similar projects. This presents real challenges for people who want to download, deploy and run Kubernetes clusters and _know_ they can run the things they want on top of it. 17 | 18 | When you consider the fast moving codebase and the diverse range of solutions providing or integrating with Kubernetes, that is a lot of moving parts provided by a lot of people. That can feel risky to some people, and lead to doubt that something built for Kubernetes today might not work tomorrow. 19 | 20 | Thankfully, this a problem the Cloud Native Computing Foundation (CNCF) is tackling. The CNCF helps to build a community around open source container software, and established the [Kubernetes Software Conformance Certification](https://www.cncf.io/certification/software-conformance/) to further that goal. Certified Kubernetes solutions are validated by the CNCF. They check that versions, APIs, and such are all correct, present, and working as expected so users and developers can be assured their Kubernetes-based solutions will work with ease, now and into the future. 21 | 22 | # Why Certify Kubic? 23 | 24 | The openSUSE Project has a long history of tackling the problem of distributing fast-moving software. 25 | 26 | Tumbleweed and Kubic are simultaneously both two of the fastest **and** most stable rolling release distributions available. 27 | 28 | With the [Open Build Service](https://openbuildservice.org) and [openQA](http://open.qa) we have an established pipeline that guarantees we only release software when it is built and tested both collectively and reproducibly. 29 | 30 | Our experience with btrfs and [snapper](http://snapper.io) means that even in the event of an unwanted (or heaven forbid, broken) change to a system, users can immediately rollback to a system state that works the way they want it to. 31 | 32 | With Transactional Updates, we ensure that no change ever happens to a running system. This futher guarantees that any rollback can return a system to a clean state in a single atomic operation. 33 | 34 | In [Kubic](https://kubic.opensuse.org), we leverage all of this to build an excellent container operating system, providing users with the latest versions of exciting new tools like [Podman]({{ site.baseurl }}{% post_url blog/2018-03-25-podman %}), [CRI-O]({{ site.baseurl }}{% post_url blog/2018-09-17-crio-default %}), Buildah, and (of course) Kubernetes. 35 | 36 | We're keeping up with all of those fast moving upstream projects, often releasing our packages within days or sometimes even hours of an upstream release. 37 | 38 | But we're careful not to put users at risk, releasing Kubic in sync with the larger openSUSE Tumbleweed distribution, sharing the same test and release pipeline, so we can be sure if either distribution makes changes that breaks the other, neither ships anything to users. 39 | 40 | So we've solved all the problems with fast moving software, so why certify? 😉 41 | 42 | Well, as much as it pains me to write this, no matter how great we are with code review, building, testing and releasing we're never going to catch **everything**. Even if we did, at the end of the day, all we can really say is **"we do awesome stuff, trust us"** 43 | 44 | And when you consider how we work in openSUSE, things can seem even more complicated to newcomers. 45 | We're not like other open source projects with a corporate backer holding the reigns and tightly controlling what we do. 46 | 47 | openSUSE is a **truly open source community project** where anyone and everyone can contribute, taking what we're doing in Kubic, and directly changing it to fit what they want to see. 48 | 49 | These contributions are on an equal playing field, with SUSE and other [Sponsors](https://en.opensuse.org/Sponsors) of openSUSE having to contribute in just the same way as any other community member. 50 | 51 | **And we want more contributions.** We will keep Kubic open and welcoming to whatever crazy (or smart, or crazy-smart) ideas you might have for our container distribution. 52 | 53 | But we also want everyone else to know that whatever we end up doing, people can rely on Kubic to get stuff done. 54 | 55 | By certifying Kubic with the CNCF, there is now an impartial third party who has looked over what we do, checked what we're distributing, checked our documentation, and conferred to us their seal of approval. 56 | 57 | So, to everyone who has contributed to Kubic so far and made this possible, **THANK YOU**. 58 | 59 | To all of the upstream projects without whom Kubic wouldn't have anything to distribute and get certified, **THANK YOU** and see you soon on your issue trackers and pull request queues. 60 | 61 | And to anyone and everyone else, **THANK YOU**, and we hope you *have a lot of fun* downloading, using, and hopefully contributing back our window into the container world. 62 | 63 | -------------------------------------------------------------------------------- /blog/_posts/2019-08-14-kata-in-tumbleweed.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Kata Containers now available in Tumbleweed" 4 | date: 2019-08-15 11:00:00 +0200 5 | author: Marco Vedovati 6 | --- 7 | 8 | ![Kata](/assets/images/kata-horz-onwhite.png) 9 | 10 | Kata Containers is an open source container runtime that is crafted to seamlessly 11 | plug into the containers ecosystem. 12 | 13 | We are now excited to announce that the Kata Containers packages are finally available 14 | in the official openSUSE Tumbleweed repository. 15 | 16 | It is worthwhile to spend few words explaining why this is a great news, considering 17 | the role of Kata Containers (a.k.a. Kata) in fulfilling the need for security in the 18 | containers ecosystem, and given its importance for openSUSE and Kubic. 19 | 20 | 21 | ## What is Kata 22 | As already mentioned, Kata is a container runtime focusing on security and on ease of 23 | integration with the existing containers ecosystem. If you are wondering what's a 24 | container runtime, [this blog post by Sascha](https://www.suse.com/c/demystifying-containers-part-ii-container-runtimes/) 25 | will give you a clear introduction about the topic. 26 | 27 | Kata should be used when running container images whose source is not fully trusted, 28 | or when allowing other users to run their own containers on your platform. 29 | 30 | Traditionally, containers share the same physical and operating system (OS) resources 31 | with host processes, and specific kernel features such as namespaces are used to provide 32 | an isolation layer between host and container processes. 33 | By contrast, Kata containers run inside lightweight virtual machines, adding an 34 | extra isolation and security layer, that minimizes the host attack surface and mitigates 35 | the consequences of containers breakout. 36 | Despite this extra layer, Kata achieves impressive runtime performances thanks to 37 | KVM hardware virtualization, and when configured to use a minimalist virtual machine 38 | manager (VMM) like Firecracker, a high density of microVM can be packed on a single host. 39 | 40 | If you want to know more about Kata features and performances: 41 | - katacontainers.io is a great starting point. 42 | - For something more SUSE oriented, Flavio [gave a interesting talk about Kata](https://youtu.be/EmOcxtCYzjk) at SUSECON 2019, 43 | - Kata folks hang out on katacontainers.slack.com, and will be happy to answer any quesitons. 44 | 45 | ## Why is it important for Kubic and openSUSE 46 | SUSE has been an early and relevant open source contributor to containers projects, 47 | believing that this technology is the future way of deploying and running software. 48 | 49 | The most relevant example is the [openSUSE Kubic project](https://kubic.opensuse.org/), 50 | that's a certified Kubernetes distribution and a set of container-related technologies 51 | built by the openSUSE community. 52 | 53 | We have also been working for some time in well known container projects, like runC, 54 | libpod and CRI-O, and since a year we also collaborate with Kata. 55 | 56 | Kata complements other more popular ways to run containers, so it makes sense for 57 | us to work on improving it and to assure it can smoothly plug with our products. 58 | 59 | ## How to use 60 | While Kata may be used as a standalone piece of software, it's intended use is serve 61 | as a runtime when integrated in a container engine like [Podman](https://podman.io/) or [CRI-O](https://cri-o.io/). 62 | 63 | This section shows a quick and easy way to spin up a Kata container using Podman 64 | on openSUSE Tumbleweed. 65 | 66 | First, install the Kata packages: 67 | ``` 68 | $ sudo zypper in katacontainers 69 | ``` 70 | 71 | Make sure your system is providing the needed set of hardware virtualization features 72 | required by Kata: 73 | ``` 74 | $ sudo kata-runtime kata-check 75 | ``` 76 | If no errors are reported, great! Your system is now ready to run Kata Containers. 77 | 78 | If you haven't already, install podman with: 79 | ``` 80 | $ sudo zypper in podman 81 | ``` 82 | 83 | That' all. Try running a your first Kata container with: 84 | ``` 85 | $ sudo podman run -it --rm --runtime=/usr/bin/kata-runtime opensuse/leap uname -a 86 | Linux ab511687b1ed 5.2.5-1-kvmsmall #1 SMP Wed Jul 31 10:41:36 UTC 2019 (79b6a9c) x86_64 x86_64 x86_64 GNU/Linux 87 | ``` 88 | 89 | ### Differences with runC 90 | Now that you have Kata up and running, let's see some of the differences between 91 | Kata and runC, the most popular container runtime. 92 | 93 | When starting a container with runC, container processes can be seen in the host 94 | processes tree: 95 | ``` 96 | ... 97 | 10212 ? Ssl 0:00 /usr/lib/podman/bin/conmon -s -c -u 98 | 10236 ? Ss 0:00 \_ nginx: master process nginx -g daemon off; 99 | 10255 ? S 0:00 \_ nginx: worker process 100 | 10256 ? S 0:00 \_ nginx: worker process 101 | 10257 ? S 0:00 \_ nginx: worker process 102 | 10258 ? S 0:00 \_ nginx: worker process 103 | ... 104 | ``` 105 | 106 | With Kata, container processes are instead running in a dedicated VM, so they are 107 | not sharing OS resources with the host: 108 | ``` 109 | ... 110 | 10651 ? Ssl 0:00 /home/marco/go/src/github.com/containers/conmon/bin/conmon -s -c -u 111 | 10703 ? Sl 0:01 \_ /usr/bin/qemu-system-x86_64 -name sandbox- -uuid e54ee910-2927-456e-a180-836b92ce5e7a -machine pc,accel=kvm,kernel_ir 112 | 10709 ? Ssl 0:00 \_ /usr/lib/kata-containers/kata-proxy -listen-socket unix:///run/vc/sbs//proxy.sock -mux-socket /run/vc/vm/829d8fe0680b 113 | 10729 ? Sl 0:00 \_ /usr/lib/kata-containers/kata-shim -agent unix:///run/vc/sbs//proxy.sock -container 114 | ... 115 | ``` 116 | 117 | ## Future plans 118 | We are continuing to work to offer you a great user experience when using Kata on openSUSE by: 119 | - improving packages quality and stability, 120 | - delivering periodic releases, 121 | - making sure that Kata well integrates with the other container projects, like Podman and CRI-O. 122 | 123 | As a longer term goal, we will integrate Kata in the Kubic distribution and in CaaSP, 124 | to make them some of the most complete and secure solutions to manage containers. 125 | 126 | -------------------------------------------------------------------------------- /blog/_posts/2019-10-22-toolbox.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "toolbox - bring your own (debugging) utilities with you" 4 | date: 2019-10-22 09:12:00 +0200 5 | author: Thorsten Kukuk 6 | --- 7 | 8 | ## Intro 9 | 10 | Our Container Host OS [openSUSE MicroOS](https://en.opensuse.org/Kubic:MicroOS) 11 | and our Kubernetes platform [openSUSE Kubic](https://kubic.opensuse.org) are 12 | both using 13 | [transactional-update](https://kubic.opensuse.org/documentation/transactional-update-guide/tu-introduction.html) 14 | to apply patches to the system. This implies that a read-only root filesystem 15 | is used. While this has big advantages, like it allows to update a cluster 16 | automatically in a safe way, this has one drawback: you need to reboot to 17 | activate new installed packages. 18 | But what if you want to debug a problem and the utility you need is not 19 | installed? Who says, that the problem is still debuggable after a reboot? 20 | 21 | For this, we introduced now the `toolbox` utilitiy with a `toolbox container`. 22 | 23 | ## toolbox - bring your own tools with you 24 | 25 | `toolbox` is a small script that launches a privileged container to let you 26 | bring in your favorite debugging or admin tools in such a system. If the 27 | container does not contain the utility you need, you can install whatever you 28 | want with `zypper`. `toolbox` is stateful, if you quit the script and start it 29 | later again, the environment is in the exactly same state as when you left 30 | it. To reset it, the container image needs to be deleted: 31 | `podman rm toolbox-`. 32 | The root filesystem can be found at `/media/root`. 33 | 34 | ### Usage 35 | 36 | ``` 37 | $ /usr/bin/toolbox 38 | Spawning a container 'toolbox-root' with image 'registry.opensuse.org/opensuse/toolbox' 39 | 51e475f05d8bb8a5bf110bbecd960383bf8cfade1569587edef92076215f0eba 40 | toolbox-root 41 | Container started successfully. To exit, type 'exit'. 42 | toolbox:/ # ls -alF /media/root 43 | ... 44 | toolbox:/ # tcpdump -i ens3 45 | tcpdump: verbose output suppressed, use -v or -vv for full protocol decode 46 | listening on ens3, link-type EN10MB (Ethernet), capture size 65535 bytes 47 | ... 48 | toolbox:/ # zypper in vim 49 | Loading repository data... 50 | Reading installed packages... 51 | Resolving package dependencies... 52 | 53 | The following 5 NEW packages are going to be installed: 54 | libgdbm6 libgdbm_compat4 perl vim vim-data-common 55 | 56 | 5 new packages to install. 57 | Overall download size: 9.0 MiB. Already cached: 0 B. After the operation, 58 | additional 49.4 MiB will be used. 59 | Continue? [y/n/v/...? shows all options] (y): 60 | ... 61 | toolbox:/ # vi /media/root/etc/passwd 62 | ``` 63 | 64 | ### Advanced Usage 65 | 66 | #### Use a custom image 67 | 68 | toolbox uses an openSUSE-based userspace environment called `opensuse/toolbox` 69 | by default, but this can be changed to any container image. Simply override 70 | environment variables in `$HOME/.toolboxrc`, where every entry is optional: 71 | 72 | ##### toolbox configuration file 73 | 74 | ``` 75 | # cat ~/.toolboxrc 76 | REGISTRY=registry.opensuse.org 77 | IMAGE=opensuse/toolbox:latest 78 | TOOLBOX_NAME=special-debug-container 79 | TOOLBOX_SHELL="/bin/bash" 80 | ``` 81 | 82 | #### Root container as normal user 83 | 84 | toolbox called by a normal user will start the toolbox container, too, but the root filesystem cannot be modified. Running toolbox with sudo has the disadvantage, that the .toolboxrc from root and not the user is used. To run the toolbox container with root rights, `toolbox --root` has to be used. 85 | 86 | #### Automatically enter toolbox on login 87 | 88 | Set an `/etc/passwd` entry for one of the users to `/usr/bin/toolbox`: 89 | 90 | ``` 91 | useradd bob -m -s /usr/bin/toolbox 92 | ``` 93 | 94 | Now when SSHing into the system as that user, toolbox will automatically be started: 95 | 96 | ``` 97 | # ssh bob@hostname.example.com 98 | Last login: Thu Oct 3 16:52:16 2019 from 192.168.107.1 99 | .toolboxrc file detected, overriding defaults... 100 | Container 'toolbox-bob' already exists. Trying to start... 101 | (To remove the container and start with a fresh toolbox, run: podman rm 'toolbox-bob') 102 | toolbox-bob 103 | Container started successfully. To exit, type 'exit'. 104 | toolbox:/ # 105 | ``` 106 | -------------------------------------------------------------------------------- /blog/_posts/2019-12-05-usr-etc.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Configuration files in /etc and /usr/etc" 4 | date: 2019-12-05 12:47:00 +0100 5 | author: Thorsten Kukuk 6 | --- 7 | 8 | ## Intro 9 | 10 | As some may have already noticed, openSUSE MicroOS introduced a `/usr/etc` 11 | directory and some configuration files are already moved to this 12 | directory. 13 | 14 | What's behind this move? For a better understanding, let's first look how 15 | configuration files are handled by RPM today: 16 | 17 | ### RPM and Configuration Files 18 | 19 | RPM has limited support for updating configuration files. In the end 20 | this consist of two simple choices: 21 | * modified configuration files are moved away during upgrade and the admin has to redo the changes (`.rpmsave` files). 22 | * modfied configuration files are kept and changes done by the distribution are ignored (`.rpmnew` files). In the end the service may not work or could even be insecure! 23 | 24 | Both options are not really user friendly and will most likely lead to a broken 25 | or insecure service after an upgrade, which requires manual work by the 26 | admin. On desktop systems or a simple server this may be tolerable, but 27 | for big clusters this can lead to a huge amount of work. 28 | 29 | There are several alternative solutions for this like Three-Way-Diff or doing 30 | the update interactively, but the first one does not solve the problem if 31 | conflicting changes are done, and the second one is no solution for fully 32 | automated updates. 33 | 34 | ### Atomic Updates 35 | 36 | For atomic systems another layer of complexity is added, because 37 | different states may contain different versions of a configuration file. 38 | So how can this happen? An atomic update is a kind of update that: 39 | 40 | * Is atomic 41 | * The update is either fully applied or not applied at all 42 | * The update does not influence your running system 43 | * Can be rolled back 44 | * If the update fails or if the update is not compatible, you can quickly restore the situation as it was before the update 45 | 46 | The update will be activated by rebooting into the new state, so after an 47 | update, before the reboot, the changes done by the update are not visible. If 48 | an admin or configuration management software changes the configuration files 49 | in the runnung system during this time, this will create conflicts, and needs 50 | manual interaction again. 51 | 52 | ## Goal 53 | 54 | The goal is to provide a concept working for most packages and their 55 | configuration files, which makes automatic updates much easier and 56 | robust. For that a new way to store and manage configuration files is needed. 57 | 58 | ## Requirements for a Solution 59 | 60 | The new solution should make sure that: 61 | * It's visible to the admin that something got updated 62 | * It's visible which changes the admin made 63 | * Package and admin changes should be merged automatically 64 | * There should be only one directory to search for default configuration files 65 | 66 | ## Solutions 67 | 68 | As a longterm solution no package should install anything into `/etc` any 69 | more, this directory should only contain host specific configuration files 70 | created during installation and changes made by the system administrator. 71 | Packages are supposed to install their default configuration files to 72 | another directory instead. 73 | 74 | For SUSE/openSUSE the decision was made to use `/usr/etc` as the directory 75 | for the distribution provided configuration files. 76 | 77 | For merging the package and admin configuration files there will have to be 78 | different strategies depending on the file type; the files can be categorized 79 | as follows: 80 | 1. Configuration files for applications 81 | 2. Configuration files for the system (network, hardware, ...) 82 | 3. "Databases" like files (`/etc/rpc`, `/etc/services`, `/etc/protocols`) 83 | 4. System and user accounts (`/etc/passwd`, `/etc/group`, `/etc/shadow`) 84 | 85 | ### Application Configuration Files 86 | 87 | For application configuration files there is already a good solution used 88 | by systemd, which could be adopted for most applications: 89 | * `/usr/etc/app.conf` is the distribution provided configuration file. 90 | * If it exists, `/etc/app.conf` replaces `/usr/etc/app.conf`. 91 | * `/etc/app.conf.d/*.conf` contains snippets overiding single entries from `/usr/etc/app.conf` or `/etc/app.conf`. 92 | 93 | The workflow for the application to load the configuration file would be: 94 | * Application looks for `/etc/app.conf`. 95 | * If this file does not exist, load `/usr/etc/app.conf`. 96 | * Look for overides in `/etc/app.conf.d` and merge them. 97 | 98 | See https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Examples, 99 | "Overriding vendor settings" for more details and examples. 100 | A C library which provides a simple interface and implements above loading 101 | mechanism transparently for the application is [libeconf](https://github.com/openSUSE/libeconf). 102 | 103 | Depending on the configuration file format above patterns may not work for 104 | all applications. For those applications a solution following the above 105 | guidelines as closely as possible should be found. 106 | 107 | ### System Configuration Files (network, hardware, ...) 108 | 109 | As these configuration files are system specific and only created during 110 | or after installation and not provided by the distribution, these files 111 | will stay in `/etc`. 112 | 113 | ### System Databases (rpc, services, protocols) 114 | 115 | There are files in `/etc` which, strictly speaking, are no configuration files, 116 | such as `/etc/rpc`, `/etc/services` and `/etc/protocols`. They are changed 117 | very rarely, but sometimes new system applications or third party software 118 | need to make additions. 119 | These files will be moved to `/usr/etc`; `/etc/nsswitch.conf` has to be changed 120 | to search in `/etc` first and in `/usr/etc` second. A glibc NSS plugin 121 | [usrfiles](https://github.com/kubic-project/libnss_usrfiles) will be used 122 | for this. `/etc` will contain only the changes done by the admin and third 123 | party software. 124 | 125 | ### /etc/passwd, /etc/group and /etc/shadow 126 | 127 | There is no solution yet for these configuration files which would really solve 128 | the problems. Ideas are welcome! 129 | 130 | ## Further Documentation 131 | 132 | * The original, full proposal with many more ideas and background information on the reasoning behind the decisions: [Atomic Updates and /etc](https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md) 133 | * The openSUSE wiki page tracking all changes: [Packaging /usr/etc](https://en.opensuse.org/openSUSE:Packaging_UsrEtc) 134 | -------------------------------------------------------------------------------- /blog/_posts/2020-01-15-k8s-117.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Kubic with Kubernetes 1.17.0 released" 4 | date: 2020-01-15 16:00:00 +0100 5 | author: Richard Brown 6 | --- 7 | 8 | ## Announcement 9 | 10 | The Kubic Project is proud to announce that Snapshot 20200113 has just been released containing Kubernetes 1.17.0. 11 | 12 | This is a particually exciting release with Cloud Provider Labels becoming a GA-status feature, and Volume Snapshotting now reaching Beta-status. 13 | 14 | Release Notes are avaialble [HERE](https://kubernetes.io/docs/setup/release/notes/#changes). 15 | 16 | ## Special Thanks 17 | 18 | Special thanks to **Sascha Grunert**, **Ralf Haferkamp** and **Michal Rostecki** who all contributed to this release, either through debugging issues or by picking up other open Kubic tasks so other contributors could focus on this release. 19 | 20 | Please look at our [github projects board](https://github.com/orgs/kubic-project/projects/3) for an incomplete list of open tasks, everyone is free to help out so please join in! 21 | 22 | ## Upgrade Steps 23 | 24 | All newly deployed Kubic clusters will automatically be Kubernetes 1.17.0 from this point. 25 | 26 | For existing clusters, you will need to follow the following steps after your nodes have transactionally-updated to 20200113 or later. 27 | 28 | For a kubic-control cluster please run `kubicctl upgrade`. 29 | 30 | For a kubeadm cluster you need to follow the following steps on your master node: 31 | `kubectl drain --ignore-daemonsets`. 32 | 33 | Then run `kubeadm upgrade plan` to show the planned upgrade from your current v1.16.x cluster to v1.17.0. 34 | 35 | `kubeadm upgrade apply v1.17.0` will then upgrade the cluster. 36 | 37 | `kubectl uncordon ` will then make the node functional in your cluster again. 38 | 39 | For then for all other nodes please repeat the above steps but using `kubeadm upgrade node` instead of `kubeadm upgrade apply`, starting with any additional master nodes if you have a multi-master cluster. 40 | 41 | Thanks and have a lot of fun! 42 | 43 | **The Kubic Team** 44 | -------------------------------------------------------------------------------- /blog/_posts/2020-04-03-k8s-118.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Kubic with Kubernetes 1.18.0 released" 4 | date: 2020-04-03 19:19:00 +0100 5 | author: Richard Brown 6 | --- 7 | 8 | ## Announcement 9 | 10 | The Kubic Project is proud to announce that Snapshot 20200331 has been released containing Kubernetes 1.18.0. 11 | 12 | Release Notes are avaialble [HERE](https://kubernetes.io/docs/setup/release/notes/#changes). 13 | 14 | ## Upgrade Steps 15 | 16 | All newly deployed Kubic clusters will automatically be Kubernetes 1.18.0 from this point. 17 | 18 | For existing clusters, please follow our new documentation our wiki [HERE](https://en.opensuse.org/Kubic:Upgrading_kubeadm_clusters) 19 | 20 | Thanks and have a lot of fun! 21 | 22 | **The Kubic Team** 23 | -------------------------------------------------------------------------------- /blog/_posts/2020-07-27-tmp_on_tmpfs.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "New default: tmpfs on /tmp" 4 | date: 2020-07-27 15:39:00 +0200 5 | author: Thorsten Kukuk 6 | --- 7 | 8 | ## Intro 9 | 10 | We made an important change for our Container Host OS [openSUSE 11 | MicroOS](https://en.opensuse.org/Portal:MicroOS), which our Kubernetes 12 | platform [openSUSE Kubic](https://kubic.opensuse.org) will inherit since it is 13 | based on openSUSE MicroOS: we use now `tmpfs` for `/tmp`. 14 | 15 | 16 | `tmpfs` is a temporary filesystem that resides in memory. Mounting directories 17 | as `tmpfs` can be an effective way of speeding up accesses to their files and 18 | to ensure that their contents are automatically cleared upon reboot. 19 | 20 | A fresh installation will use `tmpfs` for `/tmp` by default. Old installations 21 | needs to be converted to this manually, but it is still possible to switch 22 | back to use disk space for `/tmp`. This is especially useful and important, if 23 | big files are stored in `/tmp`. 24 | 25 | If temporary files or directories are needed below `/tmp`, this can be created 26 | at boot by using `tmpfiles.d`. 27 | But never store important files in `/tmp`, they will not survive the next 28 | reboot. 29 | 30 | ### Converting old installations to use tmpfs 31 | 32 | As `tmpfs` will be mounted on top of `/tmp`, existing files will be no longer 33 | accessible. The following steps will cleanup `/tmp` and enable `/tmpfs`: 34 | 35 | 1. Backup all important files currently stored in `/tmp`! 36 | 2. Remove the line for `/tmp` from /etc/fstab 37 | 3. Remove all files in `/tmp` 38 | 4. Reboot 39 | 40 | After reboot, `tmpfs` should be used for `/tmp`. 41 | 42 | ### Using disk space for `/tmp` 43 | 44 | After creating a new btrfs subvolume for `/tmp` and adding this to 45 | `/etc/fstab`, tmpfs will no longer be used for `/tmp`. 46 | 47 | The easierst way to archive this is to use mksubvolume from snapper 0.8.12 or 48 | newer: 49 | 50 | ``` 51 | # transactional-update shell 52 | transactional update # mksubvolume /tmp 53 | transactional update # exit 54 | # systemctl reboot 55 | ``` 56 | 57 | Afterwards, all files are stored again on the disk and will survive a reboot. 58 | 59 | ## Future plans 60 | 61 | In the future we plan to harden the system by default even more, e.g. by 62 | marking `/tmp` and other write-able parts of the filesystem with `noexec`. 63 | -------------------------------------------------------------------------------- /blog/_posts/2020-09-09-k8s-119.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Kubic with Kubernetes 1.19.0 released" 4 | date: 2020-09-09 13:36:00 +0100 5 | author: Richard Brown 6 | --- 7 | 8 | ## Announcement 9 | 10 | The Kubic Project is proud to announce that Snapshot 20200907 has been released containing Kubernetes 1.19.0. 11 | 12 | Release Notes are avaialble [HERE](https://kubernetes.io/docs/setup/release/notes/#changes). 13 | 14 | ## Upgrade Steps 15 | 16 | All newly deployed Kubic clusters will automatically be Kubernetes 1.19.0 from this point. 17 | 18 | For existing clusters, please follow our new documentation our wiki [HERE](https://en.opensuse.org/Kubic:Upgrading_kubeadm_clusters) 19 | 20 | Thanks and have a lot of fun! 21 | 22 | **The Kubic Team** 23 | -------------------------------------------------------------------------------- /blog/_posts/2020-11-23-requirements.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "MicroOS & Kubic: New Lighter Minimum Hardware Requirements" 4 | date: 2020-11-23 12:15:10 +0100 5 | author: Richard Brown 6 | --- 7 | 8 | ## You Spoke, We Heard 9 | 10 | openSUSE MicroOS has been getting a [significant](https://hackaday.com/2020/11/14/microos-is-immutable-linux) [amount](https://news.ycombinator.com/item?id=25094753) of [great](https://www.youtube.com/watch?v=Ve6ygUYobCw&feature=emb_title) attention lately. 11 | We'd like to thank everyone who has reviewed and commented on what we are doing lately. One bit of clear feedback we received *loud and clear* was that the Minimum Hardware requirement of 20 GB disk space was surprisingly large for an Operating System calling itself **MicroOS**. We agree! And so we've reviewed and retuned that requirement. 12 | 13 | ## New Minimum Storage Requirements 14 | 15 | The New Minimum Supported Storage Requirements for MicroOS are 16 | 17 | * `5 GB` for the read-only `/ (root)` partition, with 20GB as the recommended maximum size. 18 | * `5 GB` for the read-write `/var` partition, with 40GB as the recommended size, or however large you require for your workloads. 19 | 20 | Please Note, a standard installation of the minimal `MicroOS system role` currently uses no more than 21 | 22 | * `450 MB` with bare metal hardware support. 23 | * `285 MB` without bare metal hardware support. 24 | 25 | Therefore these new lighter requirements still ensure that your MicroOS installations have plenty of room for many automated snapshots from `transactional-updates`. These changes will not compromise the promise that MicroOS can be updated and rolled back atomically without worry. 26 | 27 | ## MicroOS Desktop Differences 28 | 29 | The [MicroOS Desktop](https://www.youtube.com/watch?v=cZLckDUDYjw), which is currently in Alpha and being actively developed, has a subtly different minimum requirement, as a result of its different use case. 30 | 31 | * `5 GB` for the read-only `/ (root)` partition, with at least 40GB recommended, or however large you require for your desktop. 32 | * `/var` and `/home` are provided as read-write `noCoW` sub-volumes as part of the `/ (root)` partition for the storage of containers, flatpaks and user-data. 33 | 34 | ## Available Now 35 | 36 | These changes have all been submitted to openSUSE:Factory, tested in openQA, and will soon be released as part of Snapshot version 20201121. They will soon be available for both [MicroOS](https://en.opensuse.org/Portal:MicroOS/Downloads) and [Kubic](https://en.opensuse.org/Portal:Kubic/Downloads) across all ISO, Cloud, and VM Images. 37 | 38 | Thanks and have a lot of fun! 39 | 40 | **The MicroOS & Kubic Team** 41 | -------------------------------------------------------------------------------- /blog/_posts/2020-12-12-k8s-120.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Kubic with Kubernetes 1.20.0 released" 4 | date: 2020-12-12 18:50:00 +0100 5 | author: Richard Brown 6 | --- 7 | 8 | ## Announcement 9 | 10 | The Kubic Project is proud to announce that Snapshot 20201211 has been released containing Kubernetes 1.20.0. 11 | 12 | Release Notes are avaialble [HERE](https://kubernetes.io/docs/setup/release/notes/#changes). 13 | 14 | ## Upgrade Steps 15 | 16 | All newly deployed Kubic clusters will automatically be Kubernetes 1.20.0 from this point. 17 | 18 | For existing clusters, please follow our new documentation our wiki [HERE](https://en.opensuse.org/Kubic:Upgrading_kubeadm_clusters) 19 | 20 | Thanks and have a lot of fun! 21 | 22 | **The Kubic Team** 23 | -------------------------------------------------------------------------------- /blog/_posts/2021-02-21-MicroOS-Kubic-Rancher-RKE.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Using Rancher and RKE with MicroOS and Kubic" 4 | date: 2021-02-08 13:20:00 +0100 5 | author: Thorsten Kukuk 6 | --- 7 | 8 | ## Intro 9 | 10 | Since [SUSE acquired Rancher Labs](https://www.suse.com/en-en/news/suse-completes-rancher-acquisition/), 11 | it's time to explain how to run Rancher on MicroOS and how to import a Kubic cluster. 12 | 13 | I used Rancher 2.5.5 for this, newer versions my have different requirements. 14 | 15 | ### Rancher with MicroOS 16 | 17 | The good news is: Rancher works out of the box on MicroOS. 18 | 19 | The necessary steps are: 20 | 21 | 1. Install MicroOS as base OS (no Container Host system role is necessary) 22 | 2. Install docker: `transactional-update pkg install docker` 23 | 3. Reboot: `systemctl reboot` 24 | 4. Enable and start docker: `systemctl enable --now docker` 25 | 26 | From here you can follow the standard [Rancher documentation](https://rancher.com/docs/rancher/v2.x/en/quick-start-guide/deployment/quickstart-manual-setup/) 27 | and install Rancher: `docker run -d --restart=unless-stopped -p 80:80 -p 443:443 --privileged rancher/rancher` 28 | 29 | ### Rancher with RKE and MicroOS 30 | 31 | Rancher offers the possibility to setup a new kubernetes cluster using 32 | RKE on an existing, running OS. This section explains how to do that using 33 | MicroOS as the host OS. 34 | 35 | While in general, RKE works fine on MicroOS, there could be two pitfalls: 36 | 1. MicroOS is using a read-only root filesystem while RKE tries to write to /usr/libexec/kubernetes 37 | 2. Rancher reports an error that the API is not reacheable. 38 | 39 | The second problem is most likely a docker problem. I suggest to start with 40 | openSUSE MicroOS Build 20210205 or newer, I have never seen this problem with 41 | docker 20.10.3ce introduced with this build. In my case, the reason for the 42 | error message was that IP forwarding didn't got fully enabled by 43 | docker. Please make sure that IP forwarding is enabled for all devices: 44 | 45 | ``` 46 | # sysctl -a |grep \\.forward 47 | net.ipv4.conf.all.forwarding = 1 48 | net.ipv4.conf.default.forwarding = 1 49 | net.ipv4.conf.docker0.forwarding = 1 50 | net.ipv4.conf.eth0.forwarding = 1 51 | net.ipv4.conf.lo.forwarding = 1 52 | ``` 53 | 54 | There are the steps to setup MicroOS for this: 55 | 56 | 1. Install MicroOS as base OS (no Container Host system role is necessary) 57 | 2. Install docker: `transactional-update pkg install docker` 58 | 3. Reboot: `systemctl reboot` 59 | 4. Enable and start docker: `systemctl enable --now docker` 60 | 61 | On the Rancher GUI select "Existing Nodes" of "Create a new Kubernetes cluster 62 | With RKE and existing bare-metal servers or virtual machines" and follow the 63 | documentation for [Flatcar Container Linux](https://rancher.com/docs/rke/latest/en/os/#flatcar-container-linux). 64 | 65 | ### Rancher with Kubic 66 | 67 | Importing an openSUSE Kubic cluster can be simple or difficult, depending 68 | on which kubernetes version your cluster is running. 69 | openSUSE Kubic currently comes with kuberenetes 1.20.2 as default. Rancher 70 | only works with kuberenetes up to 1.19.7, it does not work with 1.20.2 as of 71 | today. So if you haven't updated your cluster yet to 1.20.x, you can go to 72 | `Register an existing Kubernetes cluster`, select `Other Cluster` and follow 73 | the workflow. 74 | 75 | At the end, Rancher will come up with two errors: 76 | 1. Alert: Component controller-manager is unhealthy. 77 | 2. Alert: Component scheduler is unhealthy. 78 | 79 | You can ignore this errors: Rancher uses a deprecated interface, which kubeadm disables by default. 80 | -------------------------------------------------------------------------------- /blog/_posts/2021-04-28-k8s-121.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Kubic with Kubernetes 1.21.0 released" 4 | date: 2021-04-28 15:50:00 +0100 5 | author: Richard Brown 6 | --- 7 | 8 | ## Announcement 9 | 10 | The Kubic Project is proud to announce that Snapshot 20210426 has been released containing Kubernetes 1.21.0. 11 | 12 | Release Notes are avaialble [HERE](https://kubernetes.io/docs/setup/release/notes/#changes). 13 | 14 | ## Upgrade Steps 15 | 16 | All newly deployed Kubic clusters will automatically be Kubernetes 1.21.0 from this point. 17 | 18 | For existing clusters, please follow our new documentation our wiki [HERE](https://en.opensuse.org/Kubic:Upgrading_kubeadm_clusters) 19 | 20 | Thanks and have a lot of fun! 21 | 22 | **The Kubic Team** 23 | -------------------------------------------------------------------------------- /blog/_posts/2021-09-06-k8s-122.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Kubic with Kubernetes 1.22.1 released" 4 | date: 2021-09-06 15:50:00 +0100 5 | author: Richard Brown 6 | --- 7 | 8 | ## Announcement 9 | 10 | The Kubic Project is proud to announce that snapshot 20210901 has been released containing Kubernetes 1.22.1. 11 | 12 | Release Notes are avaialble [HERE](https://kubernetes.io/docs/setup/release/notes/#changes). 13 | 14 | ## Upgrade Steps 15 | 16 | All newly deployed Kubic clusters will automatically be Kubernetes 1.22.1 from this point. 17 | 18 | For existing clusters, please follow our new documentation our wiki [HERE](https://en.opensuse.org/Kubic:Upgrading_kubeadm_clusters) 19 | 20 | Thanks and have a lot of fun! 21 | 22 | **The Kubic Team** 23 | -------------------------------------------------------------------------------- /blog/_posts/2022-05-05-NetworkManager-Wicked.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Switching from wicked to NetworkManager" 4 | date: 2022-05-05 16:10:00 +0100 5 | author: Thorsten Kukuk 6 | --- 7 | 8 | ## Intro 9 | 10 | NetworkManager was used already a long time for the majority of openSUSE 11 | Tumbleweed installations, except for server, MicroOS and Kubic. 12 | But more and more users requested NetworkManager also for this flavours, since 13 | wicked is missing some functionality (like 5G modem support) or there are k8s 14 | network plugins, which only support NetworkManager. And since MicroOS Desktop 15 | was already using Networking, it was a logical choice to switch completly. 16 | So openSUSE MicroOS and openSUSE Kubic are now using NetworkManager as default 17 | instead of wicked since quite some time. 18 | 19 | 20 | ## Configuration files 21 | 22 | As of today there are no plans to automatically switch a system from wicked to 23 | NetworkManager. The reason is: depending on the configuration, it may be as 24 | easy as just replacing wicked with NetworkManager and everything will continue 25 | to work, or, in worst case, everything needs to be re-created from scratch for 26 | NetworkManager. There is no feature parity between this tools, so an automatic 27 | conversation may not work in all cases. 28 | 29 | The `/etc/sysconfig/network/ifcfg-*` files should be compatible, but it's not 30 | clear if there are no corner cases where they are incompatible. A migratoin 31 | should be pretty easy in this case. But if a native wicked xml configuration 32 | is in use, a manual migration of the configuration has to be done. 33 | 34 | ## Migration 35 | 36 | If the network configuration got created during installation or if only 37 | `ifcfg-*` files are used, the switch to NetworkManager should be very 38 | simple. Just replace wicked with NetworkManager: 39 | 40 | ``` 41 | # transactional-update shell 42 | -> zypper in --no-recommends NetworkManager 43 | -> rpm -e wicked wicked-service 44 | -> systemctl enable --now NetworkManager 45 | -> exit 46 | # reboot 47 | ``` 48 | -------------------------------------------------------------------------------- /blog/_posts/2022-06-10-kubic-retired.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Kubic Project Wound Down" 4 | date: 2022-06-10 11:00:00 +0100 5 | author: Richard Brown 6 | --- 7 | 8 | ## Announcement 9 | 10 | As [previously discussed](https://lists.opensuse.org/archives/list/kubic@lists.opensuse.org/thread/23ODJTP4PLGC3HWFQNA2MD4ETFSNW4KV/) on the Kubic Project mailing lists, the Kubic Project is now officially wound down. 11 | 12 | Kubic is no longer available for download, and will no longer be maintained. 13 | 14 | openSUSE MicroOS, once an offshoot of the Kubic Project, will now take more of a prominent role for those of us contributing who previously needed to split our attention between them. 15 | 16 | Users wishing to run kubernetes workloads atop of an openSUSE base are recommended to install [openSUSE MicroOS](https://microos.opensuse.org) and then install [k3s](https://rancher.com/docs/k3s/latest/en/installation/install-options/#options-for-installation-with-script). 17 | 18 | Users who prefer the kubernetes RPM packages and containers formerly offered by the Kubic Project may continue to use them, as they will be maintained by a new community maintainer going forward. Please understand this effort is entirely voluntary and on a 'best effort'. It is not expected to be as polished an experience as previously offered under Kubic. Exact details regarding any installation/migration/upgrade steps using those packages will be communicated via the Kubic mailing list and openSUSE wiki. 19 | 20 | All of the 'non-kubernetes' official openSUSE containers that were jointly maintained by the MicroOS and Kubic Project teams will continue to be maintained and supported for MicroOS. You can get them, as always, direct from [registry.opensuse.org](https://registry.opensuse.org/cgi-bin/cooverview?srch_term=project%3D%5EopenSUSE%3AContainers%3A+container%3Dopensuse%5C%2F%2F*) 21 | 22 | Thanks for everyones contributions over the years, and we look forward to seeing where we can take MicroOS with this more focused approach. 23 | 24 | **The Kubic/MicroOS Team** 25 | -------------------------------------------------------------------------------- /blog/_posts/_2018-03-20-template.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Template" 4 | date: 2018-03-20 00:00:00 +0000 5 | --- 6 | Your markdown here :D 7 | -------------------------------------------------------------------------------- /blog/index.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: "Blog" 4 | --- 5 |
    6 |
  1. {{ site.title_short }}
    2. 7 |
  2. Blog
    3. 8 |
9 |
10 |
11 |
12 | {% for post in paginator.posts %} 13 | {% include single-post.html %} 14 | {% endfor %} 15 | {% include pagination.html %} 16 |
17 |
18 |
19 | -------------------------------------------------------------------------------- /check.txt: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kubic-project/kubic-o-o/79d1a7c4fa009a8cc5a92340a438da5f084fab70/check.txt -------------------------------------------------------------------------------- /documentation/man-pages/90-issue-generator.rules.8.html: -------------------------------------------------------------------------------- 1 | issue-generator.8.html -------------------------------------------------------------------------------- /documentation/man-pages/create_autoyast_profile.1.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | -------------------------------------------------------------------------------- /documentation/man-pages/index.html: -------------------------------------------------------------------------------- 1 | indexIndex openSUSE Kubic

Name

Index — List of 19 | openSUSE Kubic 20 | helper application man pages

9

90-issue-generator.rules(8) — Creates a volatile and temporary issue file

C

create_autoyast_profile(1) — Create autoyast profile

I

issue-add-ssh-keys.service(8) — Creates a volatile and temporary issue file
issue-generator(8) — Creates a volatile and temporary issue file
issue-generator.conf(8) — Creates a volatile and temporary issue file
issue-generator.service(8) — Creates a volatile and temporary issue file
issue.d(5) — Configuration for creating an issue file

O

org.opensuse.RebootMgr.conf(8) — Reboot the machine during a maintenance window.

R

rebootmgr.conf(5) — Reboot Manager configuration files
rebootmgr.service(8) — Reboot the machine during a maintenance window.
rebootmgrctl(1) — Tool to control and configure the reboot manager daemon.
rebootmgrd(8) — Reboot the machine during a maintenance window.

T

transactional-update(8) — Apply updates to the system in an atomic way via transactional updates.
transactional-update.conf(5) — transactional-update configuration files
transactional-update.service(8) — Apply updates to the system in an atomic way via transactional updates.
transactional-update.timer(8) — Apply updates to the system in an atomic way via transactional updates.
tukit.conf(5) — tukit configuration file

This index contains 17 entries, referring to 9 individual manual pages.

21 | -------------------------------------------------------------------------------- /documentation/man-pages/issue-add-ssh-keys.service.8.html: -------------------------------------------------------------------------------- 1 | issue-generator.8.html -------------------------------------------------------------------------------- /documentation/man-pages/issue-generator.8.html: -------------------------------------------------------------------------------- 1 | issue-generatorIndex issue-generator 1.13

Name

issue-generator, issue-add-ssh-keys.service, issue-generator.service, 90-issue-generator.rules, issue-generator.conf — Creates a volatile and temporary issue file

Synopsis

/usr/sbin/issue-generator [--prefix path] [--help]

/usr/sbin/issue-generator network add | remove 19 | interface

/usr/sbin/issue-generator ssh add | remove

/usr/sbin/issue-generator --version

issue-add-ssh-keys.service

issue-generator.service

DESCRIPTION

issue-generator 20 | creates a volatile and temporary 21 | issue(5) 22 | file based on the input files and location specified in 23 | issue.d(5). 24 |

If invoked with no arguments, it applies all valid input files and 25 | creates a temporary issue file as 26 | /run/issue. 27 | /etc/issue should be symlink to this file.

Backup files ending on *.bak, 28 | *~ or *.rpm* will be ignored. Like 29 | files ending on *.issue, as this are directly shown by 30 | agetty(8). 31 |

OPTIONS

--prefix path

Add the prefix path to all used directories and files.

network add|remove interface

Creates a deletes files of the format 32 | /run/issue.d/70-interface.conf. This 33 | files contains the name of the interface and 34 | the escape codes for 35 | agetty(8) 36 | to insert the IPv4 and IPv6 addresses.

By default, only network interfaces where the name starts with 'b' 37 | or 'e' are added. Which interfaces are shown is configureable via a 38 | regex expression in in the variable 39 | NETWORK_INTERFACE_REGEX in 40 | /etc/sysconfig/issue-generator. 41 |

ssh add|remove

Creates or deletes the file 42 | /run/issue.d/60-ssh_host_keys.conf which contains 43 | fingerprints of the public ssh keys of the host.

SEE ALSO

issue(5), 44 | issue.d(5), 45 | agetty(8)

46 | -------------------------------------------------------------------------------- /documentation/man-pages/issue-generator.conf.8.html: -------------------------------------------------------------------------------- 1 | issue-generator.8.html -------------------------------------------------------------------------------- /documentation/man-pages/issue-generator.service.8.html: -------------------------------------------------------------------------------- 1 | issue-generator.8.html -------------------------------------------------------------------------------- /documentation/man-pages/issue.d.5.html: -------------------------------------------------------------------------------- 1 | issue.dIndex issue-generator 1.13

Name

issue.d — Configuration for creating an issue file

Synopsis

/etc/issue.d/*

/run/issue.d/*

/usr/lib/issue.d/*

DESCRIPTION

19 | The file /etc/issue is read from 20 | agetty(8) 21 | and similar tools and shown above the login prompt. While some of the 22 | informations can be adjusted with variables, the file itself is static. To 23 | display dynamic content, 24 | issue-generator(1) 25 | generates a /run/issue file from different files. 26 |

27 | Files in /etc/issue.d override files with the same 28 | name in /usr/lib/issue.d and 29 | /run/issue.d. Files in 30 | /run/issue.d override files with the same name in 31 | /usr/lib/issue.d. Packages should install their 32 | configuration files in /usr/lib/issue.d. Files in 33 | /etc/issue.d are reserved for the local 34 | administrator, who may use this logic to override the files installed by 35 | vendor packages. All configuration files are sorted by their filename 36 | in lexicographic order, regardless of which of the directories they reside in. 37 |

SEE ALSO

38 | agetty(8), 39 | issue-generator(1) 40 |

AUTHOR

41 | issue-generator 42 | was written by Thorsten Kukuk <kukuk@suse.com>. 43 |

44 | -------------------------------------------------------------------------------- /documentation/man-pages/org.opensuse.RebootMgr.conf.8.html: -------------------------------------------------------------------------------- 1 | rebootmgrd.8.html -------------------------------------------------------------------------------- /documentation/man-pages/rebootmgr.conf.5.html: -------------------------------------------------------------------------------- 1 | rebootmgr.confIndex rebootmgr 2.2

Name

rebootmgr.conf — Reboot Manager configuration files

Synopsis

/etc/rebootmgr.conf

Description

These configuration file controls and defines the reboot policy for 19 | rebootmgrd(8).

Options

The following options are available in the "rebootmgr" 20 | section:

window-start=

21 | The format of window-start is the same as 22 | described in systemd.time(7). 23 |

window-duration=

24 | The format of window-duration is 25 | "[XXh][YYm]". 26 |

strategy=

27 | This entry specifies the reboot strategy. For a list of valid 28 | strategies and their meaning look at the 29 | rebootmgrd(8) 30 | manual page. 31 |

Example

Example 1. Example configuration file

32 | In this example, the machine will reboot between 03:30 and 05:00 33 | o'clock in the morning. 34 |

/etc/rebootmgr.conf:

35 | 	[rebootmgr]
36 | 	window-start=03:30
37 | 	window-duration=1h30m
38 | 	strategy=best-effort
39 |

See Also

40 | rebootmgrd(8), 41 | systemd.time(7) 42 |

43 | -------------------------------------------------------------------------------- /documentation/man-pages/rebootmgr.index.html: -------------------------------------------------------------------------------- 1 | rebootmgr.indexIndex rebootmgr 2.2

Name

rebootmgr.index — List all manpages from the rebootmgr project

O

org.opensuse.RebootMgr.conf(8) — Reboot the machine during a maintenance window.

R

rebootmgr.conf(5) — Reboot Manager configuration files
rebootmgr.service(8) — Reboot the machine during a maintenance window.
rebootmgrctl(1) — Tool to control and configure the reboot manager daemon.
rebootmgrd(8) — Reboot the machine during a maintenance window.

This index contains 5 entries, referring to 3 individual manual pages.

19 | -------------------------------------------------------------------------------- /documentation/man-pages/rebootmgr.service.8.html: -------------------------------------------------------------------------------- 1 | rebootmgrd.8.html -------------------------------------------------------------------------------- /documentation/man-pages/rebootmgrd.8.html: -------------------------------------------------------------------------------- 1 | rebootmgrdIndex rebootmgr 2.2

Name

rebootmgrd, rebootmgr.service, org.opensuse.RebootMgr.conf — Reboot the machine during a maintenance window.

Synopsis

/usr/sbin/rebootmgrd [ --debug | --help | --version ]

/usr/lib/systemd/system/rebootmgr.service

/etc/dbus-1/system.d/org.opensuse.RebootMgr.conf

Description

To avoid that a whole cluster or a set of machines with the same task 19 | reboot at the same there, rebootmgrd reboots 20 | the machine following configured policies.

Reboot Strategies

21 | rebootmgr supports different strategies, when a reboot should be done: 22 |

instantly

23 | When the signal arrives other services will be informed 24 | that we plan to reboot and do the reboot without waiting 25 | for a maintenance window. 26 |

maint-window

27 | Reboot only during a specified maintenance window. If no window is 28 | specified, reboot immediately. 29 |

best-effort

30 | This is the default. IF a maintenance window is specified, 31 | use maint-window. If no maintenance window is specified, 32 | reboot immediately (instantly). 33 |

off

34 | rebootmgr continues to run, but ignores all signals to 35 | reboot. Setting the strategy to off does not clear the maintenance 36 | window. If rebootmgr is enabled again, it will continue to use the 37 | old specified maintenance window. 38 |

39 | The reboot strategy can be configured via 40 | rebootmgr.conf(5) 41 | and adjusted at runtime via 42 | rebootmgrctl(1). 43 | These changes will be written to the configuration file and survive the 44 | next reboot. 45 |

Options

--debug

Log additional informations during runtime. A real reboot is not 46 | done in debug mode.

--help

Display help text and exit

--version

Output version information and exit

See Also

47 | rebootmgrctl(1), 48 | rebootmgr.conf(5), 49 | systemd.time(7) 50 |

51 | -------------------------------------------------------------------------------- /documentation/man-pages/transactional-update.index.html: -------------------------------------------------------------------------------- 1 | transactional-update.indexIndex transactional-update 4.5.0

Name

transactional-update.index — List all manpages from the transactional-update project

T

transactional-update(8) — Apply updates to the system in an atomic way via transactional updates.
transactional-update.conf(5) — transactional-update configuration files
transactional-update.service(8) — Apply updates to the system in an atomic way via transactional updates.
transactional-update.timer(8) — Apply updates to the system in an atomic way via transactional updates.
tukit.conf(5) — tukit configuration file

This index contains 5 entries, referring to 3 individual manual pages.

19 | -------------------------------------------------------------------------------- /documentation/man-pages/transactional-update.service.8.html: -------------------------------------------------------------------------------- 1 | transactional-update.8.html -------------------------------------------------------------------------------- /documentation/man-pages/transactional-update.timer.8.html: -------------------------------------------------------------------------------- 1 | transactional-update.8.html -------------------------------------------------------------------------------- /documentation/man-pages/tukit.conf.5.html: -------------------------------------------------------------------------------- 1 | tukit.confIndex transactional-update 4.5.0

Name

tukit.conf — tukit configuration file

Synopsis

/etc/tukit.conf

Description

This configuration file controls and defines the behaviour of 19 | tukit(8).

The tukit.conf file uses INI 20 | style assignments, e.g. PARAMETER=value.

A reference file (also used for reading the default values) can be 21 | found in 22 | /usr/etc/tukit.conf.

Options

The following options are available in the 23 | "tukit" section: 24 |

DRACUT_SYSROOT

25 | Directory where "dracut" will mount the 26 | "sysroot". The current default value is 27 | "/sysroot". 28 |

LOCKFILE

29 | Lock file path for tukit. By default it is 30 | "/var/run/tukit.lock". 31 |

OVERLAY_DIR

32 | Directory where the "/etc" overlays are 33 | stored. By default it is "/var/lib/overlay". 34 |

BINDDIRS

35 | Bind mount additional directories into the update 36 | environment; to add multiple directories add a separate 37 | entry with a different id between the brackets for each. 38 |

39 | Be aware that only the root file system is managed in a 40 | transactional way, i.e. any additional mounts added here 41 | will *not* get a seperate snapshot (so their contents 42 | cannot be rolled back) and the changes will be visible to 43 | the running system immediately (breaking the transactional 44 | concept and possibly resulting in a mix between old and 45 | new files if there are also changes to the root file 46 | system until the next reboot). 47 |

48 | By default only /opt will be bind-mounted, as this 49 | directory is often used by third-party packages, but the 50 | applications in there are usually self-contained. 51 |

52 | Example: To mount additional directories such as 53 | "/usr/local" or 54 | "/var/lib/images" into the update 55 | environment, add the following lines to the configuration 56 | file: 57 | 

58 |               BINDDIRS[0]="/opt"
59 |               BINDDIRS[1]="/usr/local"
60 |               BINDDIRS[2]="/var/lib/images"
61 |

62 | If a directory contains submounts, these have to be 63 | mounted separately. For example if for some reason 64 | "/usr/local" should contain 65 | "/usr/local/extra" that is located on a 66 | different partition, both mounts will have to be listed: 67 | 

68 |               BINDDIRS[0]="/opt"
69 |               BINDDIRS[1]="/usr/local"
70 |               BINDDIRS[2]="/usr/local/extra"
71 |               BINDDIRS[3]="/var/lib/images"
72 |

73 |

74 | Note that in some situations one may be tempted to expose 75 | "/var/lib" directly, but this can be 76 | dangerous. 77 |

78 | "/var/lib" contains a lot of data, 79 | including databases, docker images or sssd data. That data 80 | is often bound to a specific version of the 81 | software. Exposing it during an upgrade can make that an 82 | RPM post-script will make changes in place that will touch 83 | the live system, that will be directly visible to the 84 | user, breaking the guarantees that transactional-update 85 | provides. 86 |

See Also

87 | transactional-update.conf(5) 88 |

89 | -------------------------------------------------------------------------------- /documentation/png/Workflow-After-Reboot.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kubic-project/kubic-o-o/79d1a7c4fa009a8cc5a92340a438da5f084fab70/documentation/png/Workflow-After-Reboot.png -------------------------------------------------------------------------------- /documentation/png/Workflow-Start.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kubic-project/kubic-o-o/79d1a7c4fa009a8cc5a92340a438da5f084fab70/documentation/png/Workflow-Start.png -------------------------------------------------------------------------------- /documentation/png/Workflow-Step2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kubic-project/kubic-o-o/79d1a7c4fa009a8cc5a92340a438da5f084fab70/documentation/png/Workflow-Step2.png -------------------------------------------------------------------------------- /documentation/png/Workflow-Step3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kubic-project/kubic-o-o/79d1a7c4fa009a8cc5a92340a438da5f084fab70/documentation/png/Workflow-Step3.png -------------------------------------------------------------------------------- /documentation/png/Workflow-Step4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kubic-project/kubic-o-o/79d1a7c4fa009a8cc5a92340a438da5f084fab70/documentation/png/Workflow-Step4.png -------------------------------------------------------------------------------- /documentation/png/Workflow-Step5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kubic-project/kubic-o-o/79d1a7c4fa009a8cc5a92340a438da5f084fab70/documentation/png/Workflow-Step5.png -------------------------------------------------------------------------------- /documentation/png/Workflow-Without-Reboot.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kubic-project/kubic-o-o/79d1a7c4fa009a8cc5a92340a438da5f084fab70/documentation/png/Workflow-Without-Reboot.png -------------------------------------------------------------------------------- /documentation/transactional-update-guide/transactional-update.html: -------------------------------------------------------------------------------- 1 | The Transactional Update Guide
The Transactional Update Guide
   Next

The Transactional Update Guide

Thorsten Kukuk

Ignaz Forster

Version 0.4, 28. September 2021

Abstract

2 | This is the documentation for transactional-update and is intended for 3 | users, administrators and packagers. 4 |

It describes how transactional-update with Btrfs works by giving 5 | an overview of the design, what an administrator needs to know about 6 | setting up and operating such a system and what a packager needs to 7 | know for creating compatible packages. 8 |

9 | For specific usage see the 10 | transactional-update man page 11 | or the 12 | list of Kubic related commands. 13 |

Table of Contents

1. Introduction
1.1. Description
1.2. Definition
1.3. Use Cases
2. Components
2.1. libtukit.so
2.2. tukit
2.3. D-Bus Bindings
2.4. transactional-update
3. High Level Concept
3.1. The root file system
3.2. Updating the correct snapshot
3.3. Workflow
3.4. Simplified workflow
4. System setup
4.1. Read-only file system
4.2. /var
4.3. /etc
5. Files
6. Porting to other systems
7. Author/acknowledgments
8. Copyright information for this document

List of Examples

4.1. /etc layers
   Next
   Chapter 1. Introduction
14 | -------------------------------------------------------------------------------- /documentation/transactional-update-guide/tu-author.html: -------------------------------------------------------------------------------- 1 | Chapter 7. Author/acknowledgments
Chapter 7. Author/acknowledgments
Prev   Next

Chapter 7. Author/acknowledgments

2 | This document was written by Thorsten Kukuk <kukuk@suse.com> 3 | with many contributions from Ignaz Forster <iforster@suse.com>. 4 |

Prev   Next
Chapter 6. Porting to other systems Home Chapter 8. Copyright information for this document
5 | -------------------------------------------------------------------------------- /documentation/transactional-update-guide/tu-components.html: -------------------------------------------------------------------------------- 1 | Chapter 2. Components
Chapter 2. Components
Prev   Next

Chapter 2. Components

Table of Contents

2.1. libtukit.so
2.2. tukit
2.3. D-Bus Bindings
2.4. transactional-update

2 | transactional-update is split into two parts: the (open)SUSE specific 3 | transactional-update shell script, and the 4 | generic tukit (including libtukit, the tukit 5 | command line application and the D-Bus bindings). 6 |

2.1. libtukit.so

7 | libtukit is a C++ library implementing the core functionality of 8 | transactional-update. It is responsible 9 | for snapshot management, preparing the environment (including 10 | overlay handling, see Section 4.3, “/etc”) and executing 11 | the command to run within the update environment. 12 |

13 | The library is designed to be a general purpose library for handling 14 | transactional systems. It provides methods to create, modify and close 15 | transactions as well as execute commands within a transaction. 16 | Currently snapper is the only implemented snapshot 17 | management option. 18 |

19 | Applications such as package managers are expected to use this library 20 | for easily supporting transactional systems. DNF for example is 21 | supporting transactional systems via the 22 | libdnf-plugin-txnupd 23 | plugin. 24 |

25 | The library also provides C bindings with the same functionality as the 26 | C++ library. 27 |

2.2. tukit

28 | tukit is a utility application to call libtukit 29 | functionality from the command line. Applications which do not support 30 | libtukit directly may use this application as 31 | a wrapper. This command is not yet intended to be called by the user 32 | directly, as it does not perform maintenance tasks such as marking a 33 | snapshot for deletion for now. 34 |

2.3. D-Bus Bindings

35 | The libtukit functionality is also available via 36 | D-Bus interface org.opensuse.tukit. Commands are 37 | executed asynchronously, returning a signal when the command execution 38 | is finished. 39 |

2.4. transactional-update

40 | This shell script is an (open)SUSE specific wrapper for handling the 41 | tasks typical on a transactional system, e.g. installing packages, 42 | updating the system or updating the bootloader. To do so it is using 43 | the tukit wrapper to call applications such as 44 | zypper for package management. 45 |

Prev   Next
Chapter 1. Introduction Home Chapter 3. High Level Concept
46 | -------------------------------------------------------------------------------- /documentation/transactional-update-guide/tu-copyright.html: -------------------------------------------------------------------------------- 1 | Chapter 8. Copyright information for this document
Chapter 8. Copyright information for this document
Prev   

Chapter 8. Copyright information for this document

2 |

Prev   
Chapter 7. Author/acknowledgments Home 
3 | -------------------------------------------------------------------------------- /documentation/transactional-update-guide/tu-files.html: -------------------------------------------------------------------------------- 1 | Chapter 5. Files
Chapter 5. Files
Prev   Next

Chapter 5. Files

/usr/etc/transactional-update.conf

2 | This is the reference configuration file for 3 | transactional-update, containing distribution 4 | default values. This file should not be changed by the 5 | administrator. 6 |

/etc/transactional-update.conf

7 | To change the default configuration for 8 | transactional-update copy or create this file 9 | and change the options accordingly. See 10 | transactional-update.conf(5) 11 | for a description of the configuration options. Values from this 12 | file will overwride the distribution default values. 13 |

/var/lib/overlay/

14 | See Section 4.3, “/etc” for an explanation of this 15 | directory's contents. 16 |

Prev   Next
Chapter 4. System setup Home Chapter 6. Porting to other systems
17 | -------------------------------------------------------------------------------- /documentation/transactional-update-guide/tu-porting.html: -------------------------------------------------------------------------------- 1 | Chapter 6. Porting to other systems
Chapter 6. Porting to other systems
Prev   Next

Chapter 6. Porting to other systems

2 | Currently snapper is the only supported snapshot 3 | implementation, however the code base is prepared to support other 4 | (file) systems 5 | as long as they provide snapshot functionality and the ability to boot 6 | from specific snapshots. 7 |

Prev   Next
Chapter 5. Files Home Chapter 7. Author/acknowledgments
8 | -------------------------------------------------------------------------------- /index.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | --- 4 |
5 |
6 |
7 |
8 | 9 |

{{ site.title }}

10 |

{{ site.description }}

11 |
12 |
13 | 14 |
15 |
16 |
17 |
18 |
19 |
20 | 21 |
22 |

23 | {{ site.name }} Blog 24 |

25 |
26 | {% for post in site.posts limit:2 %} 27 | {% include single-post.html %} 28 | {% endfor %} 29 |
30 |
31 |
32 |
33 | 34 | -------------------------------------------------------------------------------- /release/latest-1.18.txt: -------------------------------------------------------------------------------- 1 | 1.18.20 2 | -------------------------------------------------------------------------------- /release/latest-1.19.txt: -------------------------------------------------------------------------------- 1 | v1.19.15 2 | -------------------------------------------------------------------------------- /release/latest-1.20.txt: -------------------------------------------------------------------------------- 1 | 1.20.15 2 | -------------------------------------------------------------------------------- /release/latest-1.21.txt: -------------------------------------------------------------------------------- 1 | 1.21.14 2 | -------------------------------------------------------------------------------- /release/latest-1.22.txt: -------------------------------------------------------------------------------- 1 | 1.22.17 2 | -------------------------------------------------------------------------------- /release/latest-1.23.txt: -------------------------------------------------------------------------------- 1 | 1.23.17 2 | -------------------------------------------------------------------------------- /release/latest-1.24.txt: -------------------------------------------------------------------------------- 1 | 1.24.17 2 | -------------------------------------------------------------------------------- /release/latest-1.25.txt: -------------------------------------------------------------------------------- 1 | 1.25.16 2 | -------------------------------------------------------------------------------- /release/latest-1.26.txt: -------------------------------------------------------------------------------- 1 | 1.26.14 2 | -------------------------------------------------------------------------------- /release/latest-1.27.txt: -------------------------------------------------------------------------------- 1 | 1.27.16 2 | -------------------------------------------------------------------------------- /release/latest-1.28.txt: -------------------------------------------------------------------------------- 1 | 1.28.15 2 | -------------------------------------------------------------------------------- /release/latest-1.29.txt: -------------------------------------------------------------------------------- 1 | 1.29.15 2 | -------------------------------------------------------------------------------- /release/latest-1.30.txt: -------------------------------------------------------------------------------- 1 | 1.30.13 2 | -------------------------------------------------------------------------------- /release/latest-1.31.txt: -------------------------------------------------------------------------------- 1 | 1.31.9 2 | -------------------------------------------------------------------------------- /release/latest-1.32.txt: -------------------------------------------------------------------------------- 1 | 1.32.5 2 | -------------------------------------------------------------------------------- /release/latest-1.33.txt: -------------------------------------------------------------------------------- 1 | latest.txt -------------------------------------------------------------------------------- /release/latest-1.txt: -------------------------------------------------------------------------------- 1 | latest.txt -------------------------------------------------------------------------------- /release/latest.txt: -------------------------------------------------------------------------------- 1 | 1.33.1 2 | -------------------------------------------------------------------------------- /release/stable-1.18.txt: -------------------------------------------------------------------------------- 1 | latest-1.18.txt -------------------------------------------------------------------------------- /release/stable-1.19.txt: -------------------------------------------------------------------------------- 1 | latest-1.19.txt -------------------------------------------------------------------------------- /release/stable-1.20.txt: -------------------------------------------------------------------------------- 1 | latest-1.20.txt -------------------------------------------------------------------------------- /release/stable-1.21.txt: -------------------------------------------------------------------------------- 1 | latest-1.21.txt -------------------------------------------------------------------------------- /release/stable-1.22.txt: -------------------------------------------------------------------------------- 1 | latest-1.22.txt -------------------------------------------------------------------------------- /release/stable-1.23.txt: -------------------------------------------------------------------------------- 1 | latest-1.23.txt -------------------------------------------------------------------------------- /release/stable-1.24.txt: -------------------------------------------------------------------------------- 1 | latest-1.24.txt -------------------------------------------------------------------------------- /release/stable-1.25.txt: -------------------------------------------------------------------------------- 1 | latest-1.25.txt -------------------------------------------------------------------------------- /release/stable-1.26.txt: -------------------------------------------------------------------------------- 1 | latest-1.26.txt -------------------------------------------------------------------------------- /release/stable-1.27.txt: -------------------------------------------------------------------------------- 1 | latest-1.27.txt -------------------------------------------------------------------------------- /release/stable-1.28.txt: -------------------------------------------------------------------------------- 1 | latest-1.28.txt -------------------------------------------------------------------------------- /release/stable-1.29.txt: -------------------------------------------------------------------------------- 1 | latest-1.29.txt -------------------------------------------------------------------------------- /release/stable-1.30.txt: -------------------------------------------------------------------------------- 1 | latest-1.30.txt -------------------------------------------------------------------------------- /release/stable-1.31.txt: -------------------------------------------------------------------------------- 1 | latest-1.31.txt -------------------------------------------------------------------------------- /release/stable-1.32.txt: -------------------------------------------------------------------------------- 1 | latest-1.32.txt -------------------------------------------------------------------------------- /release/stable-1.33.txt: -------------------------------------------------------------------------------- 1 | latest-1.33.txt -------------------------------------------------------------------------------- /release/stable-1.txt: -------------------------------------------------------------------------------- 1 | stable.txt -------------------------------------------------------------------------------- /release/stable.txt: -------------------------------------------------------------------------------- 1 | latest.txt --------------------------------------------------------------------------------