Home Home
Sign up | Login

Next: openSUSE hardening

September 15th, 2014 by

Now.

Running the rolling openSUSE Factory has been smooth so far, no problems since the last post.

I have been involved in submitting new packages (ftop, dstat, some perl modules), patching other’s existing packages (dnsmasq) and of course taking after packages that I maintain (btrfsprogs). With a very few exceptions I’ve got done everything I needed, the exceptions were my rather silly mistakes. The damage is only the first few seconds when one realizes that the submit request was ‘rejected’. Don’t get bored by it, grab a coffee or go fix it later. Need to say the rejects are backed by a reason or explanation what’s wrong and what should be fixed in the next attempt. Learn from that, take notes, read the docs again. Once this becomes common, the amount of basic mistakes is near to zero, the self-checks become a routine. This makes a happy contributor and the distro maintainers too.

I recommend to skim the factory snapshots announcements, look at the changes or scroll down to the newly added ones. One day you can see your contributions there, go for it.

Before something goes to the Factory distro, the packages are getting ready in the devel projects. I’ve asked for maintainership of filesystems and benchmark projects and did some fixing in packages I use or at least recognize. The state of the projects is not ‘all-green’, build failures exist, but without some motivation I’m not rushing to fix them.

If you are interested (as a user) in a package from those devel projects, feel free to bug me about it. I can help with fixing build failures or submitting to Factory.

Next?

All of the above is a routine. A routine of making the distro better on the core side. There’s never enough of it and it may become boring (oh it does) over time. Out of the many research projects and experimenting I do, I decided to focus on one that’s definetely related to openSUSE, is fun, is important, useful and is not there yet.

openSUSE hardening!

“No way, really? But there’s AppArmor and SElinux enabled and the compile-time hardening options.

Yeah. I won’t repeat the arguments why AppArmor and SElinux are insufficient, functionally or usability-wise. So what’s left? Grsecurity, of course. Sadly openSUSE lacks even the unofficial grsecurity-patched kernels unlike Arch, Debian or Gentoo. Sadly2, the patched kernels are unofficial and will remain at that state until grsec is upstream. I don’t dare to predict if/when this will happen.

I’m aware of only the NetSecL distribution based on openSUSE that offered the grsec kernels, but it’s discontinued.

My hardening efforts got the codename openSUSE-gardening and are hosted in my github repository of the same name. The wiki contains more comprehensive information. It’s still work in progress and does not cover all topics in detail but should be enough to get started.

Quite unexpectedly, spender found the repo and gave it a bit of publicity on twitter. Thanks man :)

My plan was to update all relevant packages, test the kernels a bit, update the wiki and then post about that here. Nah, I got the right kick to do it now.

Quick start is really simple, a pattern that installs all necessary packages for a desktop use:

One-click install for 13.1
One-click install for Factory

Note, you’ll probably need to run linux-pax-flags before the first reboot, it will apply PaX flag exceptions, some binaries may crash due to the protections (like window manager processes, browsers). Once the zypper plugin is properly installed, the flags get updated automatically.

Warning: the patched kernel has not been extensively tested, works for me, might not work for you.

To be continued …

running an openSUSE booth at KDE Akademy 2014

September 14th, 2014 by

Banner300.going

If running a booth is, for sure, an investment of time, energy and money (even if TSP contribute to help you), We often forget to say
how much it’s important for our community and project.

Booths makes openSUSE alive in all open source events! and it’s a great experience to live, for any of us.

Feel the beat!

I strongly believe that openSUSE has be to visible on events like KDE Akademy, Scale, Fosdem, Guadec.
It’s not a question of "Bang for the buck", than a simple obviousness:

  • Fosdem : the biggest open source event in Europe (perhaps in the world) with more than 5000 hackers visiting.
  • Scale : biggest event in North America with more than 3000 attendees
  • Guadec : The annual conference of Gnome Hackers with lot of worldwide attendees
  • KDE Akademy : This year with around 150 active contributors coming from all over the world.

The obviousness is: if openSUSE has no booth there, you just see Ubuntu and Redhat, and let’s add Debian, Mageia etc for Fosdem or Scale.
openSUSE-lizard0b

You all know how much I like our Geeko community. And when Akademy staff proposed us to run a booth, I said yes, great I will be there!
After comparing ways to go to Brno, the Geeko’s car was the less expensive, and allow me to pick the demo touch screen at SUSE Headquarter.
So I took a full week off and drive 2000 kilometers to make it happens.

Read the rest of this entry »

Birdfont fonteditor for the rest of us

September 12th, 2014 by

Have you ever dreamed making your own unique font set. You get on it and seek for decent cheap or open source alternatives for making Truetype fonts  and  probably you find at least Fontforge. You are very happy and make you mind I’ll do my fonts with Fontforge. After a while you realize Fontforge is a Swiss army knife for making fonts in open source but you just wanted to create TTF, EOT or SVG font set. Weep no more you can use Birdfont. Read the rest of this entry »

LSB Best Effort

August 25th, 2014 by

As it has taken an extra ordinary amount of time for LSB to move forward a predicament has developed for many distributions, including openSUSE. Many of the requirements for LSB 4.1 can no longer be met and thus while the lsb package still builds it is not installable, see . The technically correct solution would be to drop the lsb package from the distribution, Factory now and thus 13.2 when it is released) as we can no longer be LSB compliant. However, the negative side effect is that some applications we do not and cannot package will no longer install, probably most notably google-chrome. Thus, having no lsb package, or no package that provides “lsb”, is a problem and has negative effects on many users. Therefore, the only way forward is to have an “lsb” package which provides LSB on a best effort basis.

Since LSB 4.1 and previous releases is a monolithic requirement, i.e. if you depend on lsb you depend/get everything that is in the standard, whether you want it or not, it is very likely that many applications depend on lsb while needing only a subset of the features. Thus, while we do not know all of those applications and cannot provide a list of “this will work and that will not“, there is a good chance that many external packages depending on lsb will not only install, but the payload they deliver will work with an lsb best effort approach. For those applications that are broken there is pretty much nothing we can do, sorry.

At a meeting last week at LinuxCon NA the goal was set to have LSB 5.0 released by the end of October. LSB 5.0 is incompatible with LSB 4.1 and prior releases. Thus, even if we provide an lsb 5.0 compliant package in short order after LSB 5.0 is released we still have the same risk as we do with the best effort approach. Basically some application packages that depend on “lsb” will deliver a payload that is broken. Exactly the opposite of what the LSB is trying to achieve, but hey one cannot hang on to Qt3 forever. Therefore, our “lsb best effort” approach to cover the gap does not create any additional pain.

Moving forward the LSB working group decided that the current approach, while providing value, has significant drawbacks. Predominantly there are not enough fingers on the keyboard to continue releases of such extensive “accepted standard” documentation. This is what we presently experience with the non installable lsb package. A for the LSB is being worked out. As this next/new LSB develops we will have to see how application providers deal with this. Without a formal LSB specification in the future, this problem will recur in a few years if application packages depend on a package named “lsb” which at some point may need to seize to exist. We will see how this plays out as the world we create keeps evolving.

Randa meetings – August 2014 – report from a Geeko’s point of view

August 25th, 2014 by
randa-mascot

Konqi Randa Mascot

2 Weeks ago myself and Françoise had joined the [http://www.randa-meetings.ch/ Randa Meeting] in Switzerland.

This event is a full hack-week where between around fifty people, that help to change the world, met together and hack around [http://www.kde.org KDE Community] related stuff. More on
KDE sprint page

I’ve heard about Randa from years, and had seen numerous reports about how Randa hack-week has allowed lots of changes : Plasma, Software collection, etc…

This year, we decided not only to financially sponsor the event, but also be part of as simple helper, with the status of newcomers in the KDE community contributors. Just to check how it goes.
Mario Fux (the organizer) didn’t fake his involvement to make this week a success, in a full open source spirit.



We’re reporting below a number of blog post that have been made during the hackweek.
And as the icing on the cake, you could just watch the video realized during the week.

videomaker
Read the rest of this entry »

Going Factorial

August 22nd, 2014 by

After the unclear status of openSUSE direction, the news about creating a rolling distro was a surprise, but a good one. The revised development model of Factory looks better and though it’s too early to make conclusions, works for me. The transition was straightforward, following the wiki recommendations and simply pointing all repository URLs from 13.1, verifying the proposed changes.

I’m not using a clean 13.1 installation, but a mixture of base distro packages, Tumbleweed, Kernel:stable, packman, and a few devel projects. This requires careful setting of repository prorities and reviewing each zypper dup round, I’m certainly not recommending this to inexperienced users.

Besides the OBS-provided projects, I’ve been maintaining a few packages in my home project. I admit that the right way is to submit the packages to the distro, but laziness and lack of time to the rescue.

The release cycle of openSUSE suits better users that do not tweak their systems too often and expect it to just work. But there are developers who need newer version, or users who simply want to install newer versions. This is where Tumbleweed fills the gap.

One of the visible differences between Tumbleweed and the rolling Factory is number of packages. Due to a small number of packages maintained in my home project, I did not bother submitting them to Tumbleweed. Also because they do not fit very well to its intended package selection. This comprises benchmarking tools or some tweaks and experiments with random packages.

With the announcement of rolling Factory, I’ve decided to clean up all my local changes and forward them to Factory projects. This also ended the period where openSUSE was did not have a clear direction, based on my observations. And I like the new direction, I do want to use a rolling distro, and I’m going to spend more time on updating packages I use. Let’s get rolling!

Javascript tools in openSUSE round 2: js-beautify

August 18th, 2014 by

I’ve been talking about how code construction is necessary to your coding project. With Javascript obfuscation or making code shine is more important than ever. There will be many many eyes looking at your code and see if it’s worth of nothing. After getting friend with js-beautify there ain’t no excuse to keep you ugly looking code laying around. Read the rest of this entry »

BETA Proprietary AMD/ATI Catalyst fglrx 14.20 BETA v1.0 July 11 2014 rpm are released for several openSUSE version

August 17th, 2014 by

Back on line after several weeks in late, I’ve tried from my best to resolve the case of Factory rolling releases.

After some hacks on the latest Sebastian Siebert beta version (Made in June), I’ve been able to build now BETA fglrx rpm for several openSUSE version.

one day AMD will release or not a stable version. (On my side I prefer to see more efforts made on the free radeon driver.)

Notice

This release concern only owners of radeon HD5xxx or above. All owner of HD2xx and HD4xx are really encouraged to use the free radeon driver (which received a lot of improvement in 3.11+ kernels)

This is experimental & BETA software, it could fix issues you encountered (FGLRX not working for openSUSE 13.1),

What happen to Sebastian

I would like to have some news about Sebastian Siebert, he’s a essential key for future updates.
This time I was able (even with several weeks in late) to adjust the script to create a build for openSUSE Factory.
But one day something will broke in kernel or somewhere else, and we all need to find a way to fix it.

So if you’re in touch with Sebastian, could you drop me a comment or a private mail?

I would like to continue the good support we created 3.5 years ago, or at least knowning if I’m orphan :-(

Beta Repository

To make things clear about the status of the drivers, it will not be published under the normal stable repository http://geeko.ioda.net/mirror/amd-fglrx.
I’ve created some times ago a beta repository located at http://geeko.ioda.net/mirror/amd-fglrx-beta.
The FGLRX 14.20 beta1 rpm are released for openSUSE version 12.3, 13.1 (+Tumbleweed), Factory

Signer of package my generic builder gpg key at Ioda-Net. (gpg key id 65BE584C)

For those interested by contributing or patches done to last Sebastian version, the raw-src on the server contain all the material used
http://geeko.ioda.net/mirror/amd-fglrx-beta/raw-src.

Installing the new repository

Admitting you’ve the normal repository named FGLRX, (use zypper lr -d to find the number or name you give it). You have to start by disabling it
so you could fallback to it quickly when new stable version will be published. Open a root console or add sudo at your convenience and issue the following command:

zypper mr -dR FGLRX

amd-fglrx-beta

To add another repository in the same console as root issue the following command which will install normally the right repository for your distribution

zypper ar -n FGLRX-BETA -cgf http://geeko.ioda.net/mirror/amd-fglrx-beta/openSUSE_`lsb-release -r | awk '{print $2}'` FGLRX-BETA

If you are using Tumbleweed use this one

zypper ar -n FGLRX-BETA -cgf http://geeko.ioda.net/mirror/amd-fglrx-beta/openSUSE_Tumbleweed FGLRX-BETA

Now the update/upgrade process

zypper dup -r FGLRX-BETA

Let the system upgrade the package, and try to enjoy the new beta.

Read the rest of this entry »

Fosdem proposals for main track presentations and developer rooms

August 3rd, 2014 by

Fosdem now invite proposals for main track presentations and developer rooms.

FOSDEM offers open source developers a place to meet, share ideas and collaborate. Renowned for being highly developer-oriented, the event brings together some 5000+ geeks from all over the world.

The fifteenth edition will take place on Saturday 31 January and Sunday 1 February 2015 at the usual location: ULB Campus Solbosch in Brussels.

We now invite proposals for main track presentations and developer rooms.

Previous editions have featured tracks centered around security, operating system development, community building, and many other topics. Presentations are expected to be 50 minutes long and should cater to a varied technical audience. The conference covers travel expenses and arranges accommodation for accepted main track speakers.

Developer rooms are assigned to self-organizing groups to work together on open source projects, to discuss topics relevant to a broader subset of the community, etc. Content may be scheduled in any format, subject to approval. Popular formats include presentation tracks, hacking sessions and panel discussions. Proposals involving collaboration across project or domain boundaries are strongly encouraged.

Proposals for main track presentations should be submitted using Pentabarf:

https://penta.fosdem.org/submission/

Developer room proposals should be emailed to devrooms@fosdem.org and be as detailed as possible. In particular, coordinators should indicate their affinity with the topic being proposed and provide a rough idea of the content they plan to schedule.

Key dates:

15 September
deadline for developer room proposals

1 October
deadline for main track proposals
accepted developer rooms announced

https://fosdem.org/2015/news/2014-07-01-call-for-participation/

OpenStack Infra/QA Meetup

July 23rd, 2014 by

Last week, around 30 people from around the world met in Darmstadt, Germany to discuss various things about OpenStack and its automatic testing mechanisms (CI).
The meeting was well-organized by Marc Koderer from Deutsche Telekom.
We were shown plans of what the Telekom intends to do with virtualization in general and OpenStack in particular and the most interesting one to me was to run clouds in dozens of datacenters across Germany, but have a single API for users to access.
There were some introductory sessions about the use of git review and gerrit, that mostly had things I (and I guess the majority of the others) already learned over the years. It included some new parts such as tracking “specs” – specifications (.rst files) in gerrit with proper review by the core reviewers, so that proper processes could already be applied in the design phase to ensure the project is moving in the right direction.

On the second day we learned that the infra team manages servers with puppet, about jenkins-job-builder (jjb) that creates around 4000 jobs from yaml templates. We learned about nodepool that keeps some VMs ready so that jobs in need will not have to wait for them to boot. 180-800 instances is quite an impressive number.
And then we spent three days on discussing and hacking things, the topics and outcomes of which you can find in the etherpad linked from the wiki page.
I got my first infra patch merged, and a SUSE Cloud CI account setup, so that in the future we can test devstack+tempest on openSUSE and have it comment in Gerrit. And maybe some day we can even have a test to deploy crowbar+openstack from git (including the patch from an open review) to provide useful feedback, but for that we might first want to move crowbar (which is consisting of dozens of repos – one for each module) to stackforge – which is the openstack-provided Gerrit hosting.

see also: pleia2’s post

Overall for me it was a nice experience to work together with all these smart people and we certainly had a lot of fun