Archive for the ‘Distribution’ Category
It took a bit but I am happy to report that all openSUSE 13.1 images in Amazon EC2, Google Compute Engine and Microsoft Azure public cloud environments have been refreshed. After the latest round of the GNU-TLS and OpenSSL fixes the security was, as usual, extremely efficient in providing fixed packages and these have been available in all cloud images via zypper up since last Friday. As of today the base images available in the public cloud frameworks contain the fixes by default.
In Amazon the new images are as follows:
- ap-northeast-1: ami-79296078
- ap-southeast-1: ami-84a7fbd6
- ap-southeast-2: ami-41cbae7b
- eu-west-1: ami-b56aa4c2
- sa-east-1: ami-bffb54a2
- us-east-1: ami-5e708d36
- us-west-1: ami-16f2f553
- us-west-2: ami-b7097487
In Google compute engine the image name is: opensuse-13-1-v20140609
The old image (opensuse131-v20140417) has been deprecated. To access the image you will need to add –image=opensuse-cloud/global/images/opensuse-13-1-v20140609 as the openSUSE images are not yet fully integrated into the GCE framework. Still working on that part with Google. This image also has upgrades to the google-cloud-sdk package and enable the bq (big-query) command. The gcloud command is still a bit rough around the edges, but the gcutil command should work as expected. Eventually gcutil is going to be deprecated by Google thus there is work to be done to fix the integration issues with the gcloud command. If anyone has time to work on that please send submit request to the google-cloud-sdk package in the Cloud:Tools project in OBS. Unfortunately Google still hasn’t posted the source anywhere for open collaboration . They’ll get there eventually. I will try and push any changes upstream.
In Azure just search for openSUSE in the Gallery, it’s more of a point an click thing
And that’s a wrap. Not certain we will be able to improve on the speed of such fire drill updates, but we’ll try to keep refreshing images as quickly as time allows when critical vulnerabilities in the core libraries get exposed.
Have a lot of fun….
Considering that My sCool Server will be deployed in many schools, some in remote places and Linux system administration knowledge is quite rare, and users quite new to this whole Linux way of doing thing, there are bound to be instances where some bug between chair and the keyboard, online update gone haywire, or may be “it just happened on it’s own” kind of thing, will make something stop working as configured. We needed a way to get the system in it’s original “Factory” setting easily and quickly. Enter recovery-kit.
Couple of days back went to a school here to demonstrate what openSUSE Education Li-f-e with KIWI-LTSP can bring to their lab. We have created a product based on Li-f-e called My sCool Server. It brings together all the goodies that a modern operating system must have and all the softwares required by the state board curriculum in one seamless package.
Here is more goodness from openSUSE Education team, get openSUSE Edu Li-f-e in Gnome Classic flavor.
As of May 2nd, a bunch of new rpm for FGLRX has been released for openSUSE 11.4 to 13.1 including Tumbleweed
This release concern only owners of radeon HD5xxx or above.
For older gpu, the fglrx-legacy is still 13.1, and thus didn’t work with openSUSE 12.3 or above.
Beware of that, and prefer the free open-source radeon driver which came out of the box from your openSUSE distribution.
For 12.3 and especially 13.1 the free radeon often offer a better experience than the old fglrx-legacy, especially for HD2xxx-HD4xxx range.
Help for spreading the word
Dear fellow I’m counting on you to spread the word, in the different social media you’re subscribed, and also on Mailing list, forums.
Feel free also to translate it into your native language
Release note about 14.4
The following section provides a summary of new features in this driver version.
Support for the AMD Radeon R9 295X Ubuntu 12.04.4 support Full support for OpenGL 4.4 OpenGL 4.4 supports the following extensions: ARB_buffer_storage ARB_enhanced_layouts ARB_query_buffer_object ARB_clear_texture ARB_texture_mirror_clamp_to_edge ARB_texture_stencil8 ARB_vertex_type_10f_11f_11f_rev ARB_multi_bind ARB_bindless_texture ARB_spare_texture ARB_seamless_cubemap_per_texture ARB_indirect_parameters ARB_shader_group_vote
This section provides information on resolved known issues in this release of the AMD Catalyst Linux Software Suite.
Corruption and system hang observed while running Sanctuary BM with Tear Free Desktop enabled Memory leak about hardware context EGL create context error for glesx GPU hand in CrossFire Mode [Piglit] Test "spec/arb_vertex_array_object" failed [Piglit] Test "glx/GLX_EXT_import_context/free context" failed [Piglit] Test "spec/ARB_seamless_cube_map" failed Piglit] Test "texture swizzle with border color" failed Glxtest failures observed in log file Blank screen observed while running steam games with Big picture 4ms delay observed in the glxSwapBuffers when vsync is enabled RBDoom3BFG the game auto quit when use the security camera terminal ETQW segmentation fault
The following section provides a summary of open issues that may be experienced with the AMD Catalyst Linux Software Suite.
Performance on some Steam OS games is lower on 1GB graphics memory cards, compared with 2GB graphics memory cards Some Piglit tests cause a system hang under Ubuntu
This Catalyst fglrx version support openSUSE version from 11.4 to 13.1 plus Tumbleweed (thus covering kernel from 3.11 to 3.14 series).
A special thanks to Sebastian Siebert for his effort on making this driver working under openSUSE and latest kernel.
If a kind German geeko can take the time to translate his article, put the result in comments below, you will understand that getting it working,
is not just Fun.
Last blog was about how to compile openSUSE kernel from GIT. Now we see how to get it up and running in your system. Again word of warning: Changing kernel is always bit of a hardcore trick! Even if it comes from trusted and tested binary from openSUSE (sorry I’m server admin). If you do it by yourself then you are also on your own if your machine won’t boot anymore! (more…)
Are you bored or seeking something to do? Do you want to do something that your friends will call just waste of time but it is so highly nerdy and most cool? Do you want to know what makes openSUSE or Linux in general tick? (more…)
Finally there is some news regarding our public cloud presence and openSUSE 13.1. We now have openSUSE 13.1 images published in Amazon EC2, Google Compute Engine, and Windows Azure.
Well, that’s the announcement, but would make for a rather short blog. Thus, let me talk a bit about how this all works and speculate a bit why we’ve not been all that good with getting stuff out into the public cloud.
Let me start with the speculation part, i.e. hindrances in getting openSUSE images published. In general to get anything into a public cloud one has to have an account. This implies that you hand over your credit card number to the cloud provider and they charge you for the resources you use. Resources in the public cloud are anything and everything that has something to do with data. Compute resources, i.e. the size of an instance w.r.t. memory and number of CPUs are priced differently. Sending data across the network to and from your instances incurs network charges and of course storing stuff in the cloud is not free either. Thus, while anyone can put an image into the cloud and publish it, this service costs the person money, granted not necessarily a lot, but it is a monthly recurring out of pocket expense.
Then there always appears to be the “official” apprehension, meaning if person X publishes an openSUSE image from her/his account what makes it “official”. Well first we have the problem that the “official” stamp is really just an imaginary hurdle. An image that gets published by me is no more or less “official” than any other images. I am after all not the release manager or have any of my fingers in the openSUSE release in any way. I do have access to the SUSE accounts and can publish from there and I guess that makes the images “official”. But please do not get any ideas about “official” images, they do not exist.
Last but not least there is a technical hurdle. Building images in OBS is not necessarily for the faint of heart. Additionally there is a bunch of other stuff that goes along with cloud images. Once you have one it still has to get into the cloud of choice, which requires tools etc.
That’s enough speculation as to why or why not it may have taken us a bit longer than others, and just for the record we did have openSUSE 12.1 and openSUSE 12.2 images in Amazon. With that lets talk about what is going on.
We have a project in OBS now, actually it has been there for a while, Cloud:Images that is intended to be used to build openSUSE cloud images. The GCE image that is public and the Amazon image that is public both came from this project. The Azure image that is currently public is one built with SUSE Studio but will at some point also stem from the Cloud:Images OBS project.
Each cloud framework has it’s own set of tools. The tools are separated into two categories, initialization tools and command line tools. The initialization tools are tools that reside inside the image and these are generally services that interact with the cloud framework. For example cloud-init is such an initialization tool and it is used in OpenStack images, Amazon images, and Windows Azure images. The command line tools let you interact with the cloud framework to start and stop instances for example. All these tools get built in the Cloud:Tools project in OBS. From there you can install the command line tools into your system and interact with the cloud framework they support. I am also trying to get all these tools into openSUSE:Factory to make things a bit easier for image building and cloud interaction come 13.2.
With this lets take a brief closer look at each framework, in alphabetical order no favoritism here.
An openSUSE 13.1 image is available in all regions, the AMI (Amazon Machine Image) IDs are as follows:
sa-east-1 => ami-2101a23c
ap-northeast-1 => ami-bde999bc
ap-southeast-2 => ami-b165fc8b
ap-southeast-1 => ami-e2e7b6b0
eu-west-1 => ami-7110ec06
us-west-1 => ami-44ae9101
us-west-2 => ami-f0402ec0
us-east-1 => ami-ff0e0696
These images use cloud-init as opposed to the “suse-ami-tools” that has been used previously and is no longer available in OBS. The cloud-init package is developed in launchpad and was started by the Canonical folks. Unfortunately to contribute you have to sign the Canonical Contributor Agreement (CCA). If you do not want to sign it or cannot sign it for company reasons you can still send stuff to the package and I’ll try and get the stuff integrated upstream. For the interaction with Amazon we have the aws-cli package. The “aws” command line client supersedes all the ec2-*-tools and is an integrated package that can interact with all Amazon services, not just EC2. It is well documented fully open source and hosted on github. The aws-cli package replaces the previously maintained ec2-api-tools package which I have removed from OBS.
Google Compute Engine
In GCE things work by name and the openSUSE 13.1 image is named opensuse131-20140227 and is available in all regions. Google images use a number of tools for initialization, google-daemon and google-startup-scripts. All the Google specific tools are in the Cloud:Tools project. Interaction with GCE is handled with two commands, gcutil and gsutil, both provided by the google-cloud-sdk package. As the name suggests google-cloud-sdk has the goal to unify the various Google tools, same basic idea as aws-cli, and Google is working on the unification. Unfortunately they have decided to do this on their own and there is no public project for google-cloud-sdk which makes contributing a bit difficult to say the least. The gsutil code is hosted on github, thus at least contributing to gsutil is straight forward. Both utilities, gsutil for storage and gcutil for interacting with GCE are well documented.
In GCE we also were able to stand up openSUSE mirrors. These have been integrated into our mirrorbrain infrastructure and are already being used quite heavily. The infrastructure team is taking care of the monitoring and maintenance and that deserves a big THANK YOU from my side. The nice thing about hosting the mirrors in GCE is that when you run an openSUSE instance in GCE you will not have to pay for network charges to pull your updated packages and things are really fast as the update server is located in the same data center as your instance.
As mentioned previously the current image we have in Azure is based on a build from SUSE Studio. It does not yet contain cloud-init and only has WALinuxAgent integrated. This implies that processing of user data is not possible in the image. User data processing requires cloud-init and I just put the finishing touches on cloud-init this week. Anyway, the image in Azure works just fine, and I have no time line when we might replace it with an image that contains cloud-init in addition to WALinuxAgent.
Interacting with Azure is a bit more cumbersome than with the other cloud frameworks. Well, let me qualify this with, if you want packages. The Azure command line tools are implemented using nodejs and are integrated into the npm nodejs package system. Thus, you can use npm to install everything you need. The nodejs implementation provides a bit of a problem in that we hardly have a nodejs infrastructure in the project. I have started packaging the dependencies, but there is a large number and thus this will take a while. Who would ever implement….. but that’s a different topic.
That’s where we are today. There is plenty of work left to do. For example we should unify the “generic” OpenStack image in Cloud:Images with the HP specific one, the HP cloud is based on OpenStack, and also get an openSUSE image published in the HP cloud. There’s tons of packaging left to do for nodejs modules to support the azure-cli tool. It would be great if we could have openSUSE mirrors in EC2 and Azure to avoid network charges for those using openSUSE images in those clouds. This requires discussions with Amazon and Microsoft, basically we need to be able to run those services for free, which implies that both would become sponsors of our project just like Google has become a sponsor of our project by letting us run the openSUSE mirrors in GCE.
So if you are interested in cloud and public cloud stuff get involved, there is plenty of work and lots of opportunities. If you just want to use the images in the public cloud go ahead, that’s why they are there. If you want to build on the images we have in OBS and customize them in your own project feel free and use them as you see fit.
How-to build a initrd-virtio on a fully encrypted volume group
If like me you care about your data stored on your laptop, you certainly use a fully encrypted (excepted /boot) configuration based on lvm.
In my case I also like to create, build, fix packages locally with our tool osc. I’ve plenty of power, beefy ssd, so I dedicate a logical lvm for building cleanly package with qemu-kvm configuration, like obs does
Prepare the kvm building system
As root you create 2 lvm volume with lvcreate, one will be the build root, the other one will be the additional swap
In ~/.oscrc I enable the following parameters
build-type = kvm build-device = /dev/mapper/vg0-lvobsbuild build-swap = /dev/mapper/vg1-lvobsswap build-memory = 4096 build-vmdisk-rootsize = 16000 build-vmdisk-swapsize = 4000 build-vmdisk-filesystem = ext4
You just have to adjust the Memory quantity and the device to what you create for your own environment.