[heroes] jeos image for opensuse.org VMs
Hello, I created a jeos image [1] that can be used for the opensuse.org VMs. Inside root.tar.xz there is root/bin/initial_setup.sh that will set up networking for a VM based on the virt cluster it belongs (currently only the atreju cluster is supported there). The same image minus this script can be used in the future as template image for our cloud infrastructure. The image installs a very minimal set of packages (base pattern, kernel, grub2, less, vim, iputils, dhcp-client). The idea is that the initial_setup.sh will do the networking setup, then enable the salt-minion service, reboot the VM and on the next boot that salt will take over. Feel free to review/test/suggest. I plan to merge it and start using it on Monday if there will be no objections [1] https://build.opensuse.org/request/show/432974 -- Theo Chatzimichos <tampakrap@opensuse.org> <tchatzimichos@suse.com> System Administrator SUSE Operations and Services Team
Hello, (@Theo: sorry for sending this as a private reply first!) Am Donnerstag, 6. Oktober 2016, 14:28:56 CEST schrieb Theo Chatzimichos:
I created a jeos image [1] that can be used for the opensuse.org VMs.
Feel free to review/test/suggest. I plan to merge it and start using it on Monday if there will be no objections
42.1 is terribly old ;-) - what about using 42.2 for new VMs? I know 42.2 is still in beta, but that shouldn't stop us from using it already ;-) [1] I had a quick look at the image. Looks good, but it's indeed very minimal ;-) IIRC our guidelines say all services should be protected by an AppArmor profile, so it would probably make sense to install AppArmor by default. pattern-openSUSE-apparmor should drop in what we need. If kiwi ignores recommends, also add apparmor-utils (which is not really needed for running the server, but very helpful for translating audit.log events to profile changes). Speaking of audit.log - the audit daemon (package audit) would also be helpful. Or do you prefer to do this via salt? (Deploying and loading the service-specific AppArmor profiles would always be salt's job.) BTW: IIRC Lars said that there is a set of existing salt states [2] which is used by the existing openSUSE servers/VMs. Is this available to the public (where?), or do I need a special account somewhere? Regards, Christian Boltz [1] I already have some 42.2 beta servers running for a customer (since beta 1!) without "surprises", so I don't see a reason why openSUSE itsself shouldn't use it ;-) It might even be worth a news.o.o article (or at least a note in the RC1 announcement) saying "look how good 42.2 beta is, we are already using it on $service.o.o" ;-) [2] I'm new to salt and its terms, so I hope I grabbed the right name for the *.sls files ;-) -- Es kommt mir (auch wegen der zahlreichen PMs) so vor als ob ich der einzige bin der das noch nicht "gehört" hatte. Nächstes Mal wähle ich gleich als Subject "Sag mal schnell einer das Passwort für xyz". Besser als Brute-Force! [Rüdiger Meier in suse-linux] -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
On Mon, Oct 10, 2016 at 12:48:25AM +0200, Christian Boltz wrote:
42.1 is terribly old ;-) - what about using 42.2 for new VMs? I know 42.2 is still in beta, but that shouldn't stop us from using it already ;-) [1]
There was a reason I created 42.1: I wanted to make sure that the packages from the update channel are preferred. Now that I made sure that this behaviour is working fine, I can create the 42.2 beta as well for sure.
I had a quick look at the image. Looks good, but it's indeed very minimal ;-)
Thanks for the review! Once again, we really need the image as minimal as possible (just to be able to set its network up as a first step). It will not be used only for production machines managed via salt, but also for workers, runners, containers, testing cloud instances etc. We need just to be able to set its network as a first step.
IIRC our guidelines say all services should be protected by an AppArmor profile, so it would probably make sense to install AppArmor by default. pattern-openSUSE-apparmor should drop in what we need. If kiwi ignores recommends, also add apparmor-utils (which is not really needed for running the server, but very helpful for translating audit.log events to profile changes). Speaking of audit.log - the audit daemon (package audit) would also be helpful.
Or do you prefer to do this via salt?
That has to be done via salt afterwards
(Deploying and loading the service-specific AppArmor profiles would always be salt's job.)
BTW: IIRC Lars said that there is a set of existing salt states [2] which is used by the existing openSUSE servers/VMs. Is this available to the public (where?), or do I need a special account somewhere?
I explained the situation in a past mail, see https://lists.opensuse.org/heroes/2016-07/msg00022.html Meanwhile I started writing some salt code for opensuse, but it is in very early stages and not deployed yet. I'll keep you posted
Regards,
Christian Boltz
[1] I already have some 42.2 beta servers running for a customer (since beta 1!) without "surprises", so I don't see a reason why openSUSE itsself shouldn't use it ;-) It might even be worth a news.o.o article (or at least a note in the RC1 announcement) saying "look how good 42.2 beta is, we are already using it on $service.o.o" ;-)
[2] I'm new to salt and its terms, so I hope I grabbed the right name for the *.sls files ;-)
-- Theo Chatzimichos <tampakrap@opensuse.org> <tchatzimichos@suse.com> System Administrator SUSE Operations and Services Team
On Mon, Oct 10, 2016 at 11:20:24AM +0200, Theo Chatzimichos wrote:
On Mon, Oct 10, 2016 at 12:48:25AM +0200, Christian Boltz wrote:
42.1 is terribly old ;-) - what about using 42.2 for new VMs? I know 42.2 is still in beta, but that shouldn't stop us from using it already ;-) [1]
There was a reason I created 42.1: I wanted to make sure that the packages from the update channel are preferred. Now that I made sure that this behaviour is working fine, I can create the 42.2 beta as well for sure.
42.2 fails to build: [ 136s] Oct-10 10:35:49 <3> : Could not find valid boot image description for'oemboot/suse-leap42.2'. [ 136s] Oct-10 10:35:49 <3> : The required boot image description: 'oemboot/suse-leap42.2' for the selected build type: 'oem' does not exist. https://build.opensuse.org/package/live_build_log/openSUSE:infrastructure:Im... -- Theo Chatzimichos <tampakrap@opensuse.org> <tchatzimichos@suse.com> System Administrator SUSE Operations and Services Team
Hello, Am Montag, 10. Oktober 2016, 13:06:14 CET schrieb Theo Chatzimichos:
On Mon, Oct 10, 2016 at 11:20:24AM +0200, Theo Chatzimichos wrote:
On Mon, Oct 10, 2016 at 12:48:25AM +0200, Christian Boltz wrote:
42.1 is terribly old ;-) - what about using 42.2 for new VMs? I know 42.2 is still in beta, but that shouldn't stop us from using it already ;-) [1]
There was a reason I created 42.1: I wanted to make sure that the packages from the update channel are preferred. Now that I made sure that this behaviour is working fine, I can create the 42.2 beta as well for sure.
42.2 fails to build:
[ 136s] Oct-10 10:35:49 <3> : Could not find valid boot image description for'oemboot/suse-leap42.2'. [ 136s] Oct-10 10:35:49 <3> : The required boot image description: 'oemboot/suse-leap42.2' for the selected build type: 'oem' does not exist.
Nice :-/
https://build.opensuse.org/package/live_build_log/openSUSE:infrastruct ure:Images:openSUSE_Leap_42.2/jeos/images/x86_64
Any update on this (besides "it still fails")? Having working 42.2 images would be nice, so - did you open a bugreport and/or ask the responsible maintainer about this problem? Regards, Christian Boltz -- install by booting the rescue-cd, partition your system manually, then use the obs build script to populate the target file sytem, configure everything by hand and reboot afterwards. But it's a bit tedious to do so and if I'd file a droprequest for yast2-installation, I'm quite sure many people would be unhappy. [Stefan Seyfried in opensuse-factory] -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
Hello, Am Mittwoch, 2. November 2016, 20:33:43 CET schrieb Christian Boltz:
Am Montag, 10. Oktober 2016, 13:06:14 CET schrieb Theo Chatzimichos:
42.2 fails to build:
Any update on this (besides "it still fails")?
Having working 42.2 images would be nice, so - did you open a bugreport and/or ask the responsible maintainer about this problem?
After some IRC discussion with Theo, I opened https://github.com/openSUSE/kiwi/issues/611 Marcus responded quickly, and the short version is: - kiwi 7.x won't get support for 42.2 - kiwi 8.x supports 42.2, but wasn't accepted in the 42.2 repo yet The most interesting message is: Until the package has been accepted you can build in the buildservice as documented here: http://suse.github.io/kiwi/quickstart.html#using-kiwi-ng-from-build-service Theo, can you please give this a try? Regards, Christian Boltz -- Snapper is a fancy tool built on top of btrfs (*) [... ] * hold your stones, no need to throw them now :) [Lukas Ocilka on yast-devel] -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
participants (2)
-
Christian Boltz -
Theo Chatzimichos