Last weekend, I was at FrOSCon - a great Open Source conference in Sankt Augustin, Germany. We (Sarah, Marcel and I) ran the openSUSE booth, answered lots of questions about openSUSE and gave the visitors some goodies - serious and funny (hi OBS team!) stickers, openSUSE hats, backpacks and magazines featuring openSUSE Leap. We also had a big plush geeko, but instead of doing a boring raffle, we played openSUSE Jeopardy where the candidates had to ask the right questions about Linux and openSUSE for the answers I provided.
To avoid getting bored ;-) I did a sub-booth featuring my other two hobbies - AppArmor and PostfixAdmin. As expected, I didn't get too many questions about them, but it was a nice addition and side job while running the openSUSE booth ;-)
I also gave an updated version of my "AppArmor Crash Course" talk. You can find the slides on the right, and the video recording (in german) on media.ccc.de.
About two years ago, I wrote a mail titled "Another openSUSE Board candidate". These two years passed quickly, and I really enjoyed being part of the Board and helping the community whenever needed.
I'd like to continue this "job", and therefore decided to run for re-election.
I use openSUSE since years (it was still named „SuSE Linux“ with lowercase „u“ back then) and started annoying people in bugzilla, err, started betatesting in the 9.2 beta phase. Since then, I reported more than 1300 bugs. Nowadays, OBS ruins my bugzilla statistics by introducing the option to send a SR ;-)
One of my current activities in openSUSE is working in the Heroes team, where I started with moving and upgrading the wiki. I also help out on various *.opensuse.org servers since someone was evil enough to give me root permissions on lots of them ;-) (Transparency note: I helped to setup the elections.opensuse.org server before last year's elections - but will of course not touch it until the elections finish.)
My other openSUSE hobbies ;-) are AppArmor and PostfixAdmin, where I'm active in upstream development and as packager. AppArmor also turned out to be a good opportunity for cross-distribution collaboration.
You can find me on several mailinglists and on IRC (nickname "cboltz"), and of course I still scare people in bugzilla. I‘m also a regular visitor and speaker at the openSUSE Conference, and visit other conferences as time permits.
My day job has nothing to do with computers. I produce something you can drink that is named after a software we ship in openSUSE ;-)
Oh, and I collect funny quotes from various mailinglists, IRC, bugzilla etc. that then end up as random [1] signatures under my mails, so be careful what you write ;-)
There are some things I‘ll never do (you might remember them from two years ago):
- use a stable release on my main computer – Tumbleweed is just too good ;-)
- open a bugreport if fxing the bug and sending a SR is faster
- be too serious – hey, our motto is „Have a lot of fun...“ ;-)
- drink beer ;-) (sorry, not even openSUSE beer)
If you want to read more from or about me, have a look at
I wish all candidates good luck, and hope that we‘ll see some more candidates and lots of voters!
[1] sometimes I hand-pick signatures, and this is one of these cases with a non-random signature ;-) (yes, I know it's unusual for a blog post to have a signature at all, so this will stay a rare exception)
--
Christian, there are times you are a pain in the ass, there are times I really like you.
This is one of both of those times ;)
[Richard Brown]
There is this old quote from LKML:
Get back there in front of the computer NOW. Christmas can wait.
[Linus "the Grinch" Torvalds, 24 Dec 2000 on linux-kernel]
The AppArmor developers followed this advise - John released AppArmor 2.12 yesterday (Dec 25), and I just submitted updated packages to openSUSE Tumbleweed (SR 560017).
The most visible changes in 2.12 are support for "owner" rules in aa-logprof and upstreaming of the aa-logprof --json interface (used by YaST). Of course that's only the tip of the christmas cookie ;-) - see the Release Notes for all details.
One important change in the openSUSE packages is that I intentionally broke "systemctl stop apparmor". The reason for this is "systemctl restart apparmor" - systemd maps this to stop, followed by start. This resulted in unloading all AppArmor profiles by the "stop" part and, even if they get loaded again a second later, running processes will stay unconfined unless you restart them. The systemd developers were unwilling to implement the proposed ExecRestart= option for unit files, therefore breaking "stop" is the best thing I can do. (See boo#996520 and boo#853019 for more details.)
"systemctl reload apparmor" will continue to work and is still the recommended way to reload the AppArmor profiles, but accidently typing "restart" instead of "reload" can easily happen. Therefore I chose to break "stop" - that's annoying, but more secure than accidently removing the AppArmor confinement from running processes.
If you really want to unload all AppArmor profiles, you can use the new "aa-teardown" command which does what "systemctl stop apparmor" did before - but who would do that? ;-)
Note that the above (except the recommendation to use "reload") only applies to Tumbleweed and Leap 15.
As part of the work for the openSUSE wiki upgrade and move, I had to package a bunch of MediaWiki extensions. We'll use the MediaWiki 1.27.x LTS release, which means the extensions need to work with this version.
When it comes to packaging, there are three categories of extensions:
The Good
These extensions are hosted on phabricator.wikimedia.org, and you can easily download a tarball matching your MediaWiki version using the "Download snapshot" link on the extension page.
Packaging these extensions is easy - just unpack the tarball and copy/package everything to the extension directory.
These extensions are standardized enough to use a spec file template - usually I only had to adjust the extension name, tarball name and version. Speaking of the version - most extensions don't have explicit version numbers, so I decided to use the tarball date instead.
An example for this category is Auth_remoteuser (extension page, package) which we use to keep the "nice" wiki login form.
The Bad
These extensions are hosted on GitHub and typically only have a "master" branch. They usually still work with MediaWiki 1.27.x, but there's a small risk that they require features added in newer MediaWiki versions, and this risk will grow over time.
On the packaging side, they are as easy as the "good" extensions.
An example is the ParamProcessor extension (extension page, package) which is needed by the Maps extension
The Ugly
These extensions can be hosted on phabricator.mediawiki.org or GitHub, so there are "god ugly" and "bad ugly" extensions ;-) The thing that makes packaging really ugly is that they don't include all the code they need. Instead, you have to download the missing parts with composer.
composer works fine in a "real" system, but makes packaging hard. Running it from the spec will obviously fail because OBS doesn't allow network connections while building a package (and even if it's annoying in this case, not having network access during build is a good thing[tm]).
My solution is a little script that unpacks the extension tarball and runs "composer install --no-dev" inside the extension directory. The most important part is the "--no-dev" parameter because that avoids lots of superfluous things. Afterwards, I build a tarball from the "vendor" directory and add it to the package.
Yeah, I know that's not nice - guess why I named this section "The Ugly" ;-)
One of the packages that need a "composer install" run is the GitHub extension (extension page, package including script to run composer).
Luckily, "ugly" only applies to packaging. The extensions and their maintainers are for sure not ugly - for example, the maintainer of the GitHub extension was very fast in fixing a bug :-)
 I just released PostfixAdmin 3.0.2.
This release fixes a security bug - admins could delete protected aliases like abuse@ (CVE-2017-5930). Besides that, some non-security bugs were fixed. Read the official announcement for details.
Packages for openSUSE Tumbleweed and updates for Leap are already on their way to the official repos :-)
Some weeks ago, someone asked on the opensuse-wiki mailinglist if it's acceptable to move documentation (in this case about Icecream) from the openSUSE wiki to the upstream repo on github. One of the arguments was:
I think I should store anything I do for the openSUSE project somewhere in the openSUSE.org domain, not in a RedHat.org or Canonical.org domain or a SourceForge.net or GitHub.com domain.
While this sounds like a valid argument and for sure shows good intentions, I wrote a longish reply:
You are overlooking an important point here - collaboration.
It doesn't make sense to think of "we" vs. "them" when it comes to other distributions or upstream projects. It's quite the opposite - everybody can save time by working together with other distributions, upstream projects etc. We have more important things to do than re-inventing the wheel just because we need a green one.
As an example: You might know that I maintain AppArmor in openSUSE and also contribute upstream (OMG, the upstream mailinglist is @lists.ubuntu.com, not at a "neutral" domain!)
Some not-so-known details:
- I implemented support for new AppArmor rule types (dbus, signal etc.) in aa-logprof, but those are not yet supported in the upstream kernel (and also not in openSUSE) - so currently only Ubuntu users benefit from that
- I always send patches upstream so that everybody can benefit (no, saying "use openSUSE, it's fixed there" is not a good idea ;-)
- In 2015, I visited DebConf (I'd guess I was the only one there who had never used Debian before) and even gave a talk.
- I closely follow AppArmor-related bugreports in Debian and Ubuntu, and help them to get things fixed - even if it's distro-specific
So, tell me - am I working for the enemy? ;-)
BTW: This isn't a one way road. Quite some AppArmor contributions done by Ubuntu (some other upstream developers work for Canonical) and Debian contributors end up in openSUSE ;-)
Needless to say that AppArmor is just an example. What I said is basically valid for every package, project, whatever. Either you collaborate (and everybody wins), or you "cook your own soup" and never find out that someone else has a receipe for a much more tasty soup ;-)
Since I talked a lot about AppArmor in the above text, let's see what's new there.
You might have noticed that there were some AppArmor releases recently:
- AppArmor 2.9.4 (with several bugfixes and profile updates) was already released as an update for openSUSE 13.2 shortly before it went out of support.
- AppArmor 2.10.2 (also with several bugfixes and profile updates) is already available in Tumbleweed, and updates for Leap 42.1 and 42.2 are under review
- AppArmor 2.11 (with lots of improvements and new features - for example, I rewrote the handling of file rules in aa-logprof etc.) is on its way to Tumbleweed (SR 453537), but it seems splitting off libapparmor into its own spec file (to fix a build loop) triggered a bug in the factory-auto review bot. Given my talent to find bugs, I'm not even surprised ;-)
The rewrite of the file rule handling resulted in a nice series of 42 patches which replace 1600 lines of code using a deeply nested array with 1200 lines with the more readable and easier maintainable FileRule and FileRuleset classes (a total of 530 lines) and functions using these classes. Even with 400 lines less code, I added some small features (for example, rules with leading permissions like "r /etc/fstab," are now supported) and fixed some bugs along the way.
The old code to handle file rules had very few unittests, which made this rewrite (and especially avoiding breakage and regressions) quite challenging. On the positive side, my patch series added full test coverage for the FileRule and FileRuleset classes, and also added unittests for most of the functions using FileRule and FileRuleset. (Unfortunately full test coverage isn't always easy, especially for the interactive parts of aa-logprof.) Those unittests add about 1400 lines of code, but as long as such additions happen in the tests directory, I'm more than happy about them ;-)
Oh, and the final challenge hit the other AppArmor developers. AppArmor has the policy that all patches have to be reviewed, and reviewing the whole patch series (which summed up to +2600 -1628 lines) took some time ;-)
That all said, let's not forget to answer where the documentation should live:
To come back to the origin of this discussion: I don't care too much where the Icecream developers host their documentation as long as
- it is complete and up to date (having it at the developers' favorite place makes this more likely)
- it can be easily found (also not a problem, it's linked from the wiki, and your favorite search engine will also find it)
I see the main purpose of the openSUSE wiki to provide openSUSE-specific information.
Information about upstream projects (even if a project is done by openSUSE) is "nice to have", but it's also ok if it lives upstream. It's better have one good upstream documentation than pages at 5 distro wikis that are all incomplete and out of date ;-)
BTW: The question "Am I working for the enemy?" was mostly meant as a rhetoric question - but if you want to answer nevertheless, please add a comment ;-)
I was nominated to run for the openSUSE Board, and finally decided to run ;-)
I use openSUSE since years (actually it was still „SuSE Linux“ with lowercase „u“ back then), started annoying people in bugzilla, err, started betatesting in the 9.2 beta phase. Since then, I reported more than 1200 bugs. Later, OBS ruined my bugzilla statistics by introducing the option to send a SR ;-)
More recently, I helped in fighting the wiki spam, which also means I‘m admin on the english wiki since then, and had some fun[tm] with the current server admin. I‘m one of the founding members of the Heroes team (thanks to Sarah for getting the right people together at oSC16!) Currently, I work on the base server setup (using salt) for our new infrastructure and updating the wiki to an up-to-date MediaWiki version.
You can find me on several mailinglists and on IRC, and of course I still scare people in bugzilla. I‘m also a regular visitor and speaker at the openSUSE Conference, and visit other conferences as time permits.
Besides openSUSE, I work on AppArmor and PostfixAdmin – both upstream and as packager. Also, I‘m admin on several webservers (all running with Leap).
My day job has nothing to do with computers. I produce something you can drink that is named after a software we ship in openSUSE ;-)
Oh, and I collect funny quotes from various mailinglists, IRC, bugzilla etc. that then end up as random signatures under my mails, so be careful what you write ;-)
Issues I can see
Aims/Goals
-
speed! We have too many issues hanging around for too long, and that‘s annoying for people who suffer from them. Especially small things should (and can!) be solved quickly.
-
clear responsibilities! Part of the speed problem is that it‘s sometimes hard to find out who can fix something, and hunting down people takes time.
-
don‘t talk (too much) – do it! Sometimes we need to discuss things, but often just doing them works best. Obviously I can‘t do everything alone, so I want to encourage people to help whereever they can. „I don‘t have knownledge how to do this“ doesn‘t count – for example, updating a wiki page or reporting a bug isn‘t hard ;-) and typically people really start to report bugs once they understand that this gives them the right to complain (quoting Pascal Bleser: „Always file a bug: if it‘s not in Bugzilla, then it‘s not there“)
-
longer days! Maybe I should move to Bajor – I heard they have 26 hour days there, which would solve some of my time problems ;-))
Why you should vote for me?
Things I‘ll never do:
-
use a stable release on my main computer – Tumbleweed is just too good ;-)
-
open a bugreport if fxing it and sending a SR is faster
-
be too serious – hey, our motto is „Have a lot of fun...“ ;-)
-
drink beer ;-) (sorry, not even openSUSE beer)
Contact Details:
I wish all candidates good luck, hope that we‘ll see lots of voters – and wish everybody all the best for 2017!
PS: Non-random signature (yes, I know it's unusual for a blog post to have a signature at all, so this will stay a rare exception) – and while I have serious doubts about the second paragraph, I‘m very sure about the first ;-)
--
If you run for the Board this year and get elected, I can see my sanity would be doomed
But in a good way ;)
[Richard Brown]
I just released the long awaited PostfixAdmin 3.0.
Right. there isn't a beta label anymore :-) It's more than two years since we released the first beta for 3.0 (and even more years of working towards 3.0 - I started working on the PFAHandler class in 2011) so I think we can safely drop the beta label.
PostfixAdmin 3.0 is now officially the stable version of PostfixAdmin. I'll keep the 2.3 branch maintained for a while if someone finds critical or security bugs, but nevertheless it's probably a good idea to upgrade to 3.0 whenever you have some time.
See the official announcement for details and the changelog, and my PostfixAdmin 3.0 slides (which still wear the beta label) for a quick overview of PostfixAdmin and what's new in 3.0.
BTW: I already submitted PostfixAdmin 3.0 to openSUSE Tumbleweed and Leap 42.2. It will arrive there as soon as the submit requests get accepted.
About two weeks ago, some visitors of the openSUSE Conference enjoyed playing openSUSE Jeopardy.
You might guess that there are some free implementations of the Jeopardy game out there. This is true, but everything I found didn't match my requirements (with varying reasons for each implementation I found). Therefore I decided to improve Ryan McDevitt's JavaScript Jeopardy and added quite some features I wanted to have available for running the openSUSE Jeopardy.
Some technical details:
- the board is implemented using HTML and jQuery, so all you need is a browser (ideally in fullscreen mode)
- the answers and questions are read from JSON files (you can also mark answers as "daily doubles" there)
- everything (except selecting a tile) is done with keyboard shortcuts
- besides the obvious basic features, there are some just for fun additions like the demo runner
I'm happy to announce that I just released my Jeopardy implementation on github under the MIT licence. (Yes, I usually prefer GPL, but since both jQuery and Ryan's original implementation are MIT-licensed, I decided to keep it that way.)
If you want to run a Jeopardy show (with whatever topics) yourself, I hope you find my implementation useful!
I'd also like to thank Hakon from the Linux User Group Landau for soldering a Jeopardy controller using the controller of an old USB keyboard. If you want to do something like that yourself: Dismantle an old keyboard. You'll find a small controller board which is attached to two foils that reach out to the keys. The buzzing is done using the 1..9 keys, so find out which contacts are used for those keys and solder cables on them. Oh, and make sure the cables are long enough to reach out to your players ;-)
A week ago, the openSUSE Conference 2016 ended, so it's time to finally upload my AppArmor Crash Course slides ;-)
I enjoyed lots of good talks. There were too many to mention a favorite one, but I'll try nevertheless:
- Georgi's "MySQL firewall" - basically you could describe it as "AppArmor for MySQL", so it isn't surprising that I like it ;-)
- AJ's "Infrastructure at OpenStack" included several interesting ideas (watched on video because it happened at the same time as "MySQL Firewall")
- Reproducible Builds (both from Holger and Bernhard) - it was good to see that we have some progress on it, even if the current target is "build-compare says it's equal" and not "it's bit-for-bit equal"
- Markus' "What's that distribution" quiz with funny quotes
- Thorsten's "Btrfs, snapshots and rollbacks" with quite some btrfs insight and details
- the keysigning party - a literally hot party ;-) (back home, I found out that perl-GnuPG-Interface which is needed for caff is incompatible with the GPG version in Tumbleweed, so I'll need to setup a Leap VM to do the keysigning)
- the LinuxTag-style Hacking Content - I applied quite some evil hacks, but it also turned out playing with the PAM config can make the login hard ;-)
- Sarah's "Stress Tests and Performance Monitoring" - I already started to play with Munin which looks like a good candidate to replace some custom perl scripts I'm currently using
- the SUSE Band :-)
- Richard's "Distribute or die", even if I don't really agree that we should discourage using additional repos. Maybe I should just quote Richard himself:
I am not a Dictator, I can think of no example where I've ordered anyone to do anything. And I would expect people to stare at me funny and tell me 'no', if I tried.
I also had lots of interesting discussions on the hallway track and learned something about Nürnberg in the city tour and the cellar tour.
After the official part of oSC16 ended, we had a promising disussion about the (technical) future of the openSUSE wiki. If everything works out as planned, we'll get some shiny new hardware hosted in Provo that is only used for openSUSE - and the most important thing is that we'll have SSH access to it and can do whatever is needed without having to wait for the Provo admins.
PS: You might have noticed that I didn't mention the openSUSE Jeopardy in this post - I'll do that in a separate post next week ;-)
|
I gave a talk about PostfixAdmin 3.0 (beta) at the openSUSE conference and the LUG Landau, and finally have some time to upload the slides. Here we go:
|
|
Nachdem ich auf der openSUSE Conference und bei der LUG Landau einen Vortrag über PostfixAdmin 3.0 (beta) gehalten habe, gibt es hier die Folien:
|
|
|
|
|
|
English slides (PDF; with fancy openSUSE background)
|
|
Deutsche Folien (PDF, mit langweiligem Hintergrund ;-))
|
Happy Towel Day!
I know I'm a bit late for the people living in germany, but it's still early enough for those living on the other side of the planet ;-) - especially for the other AppArmor developers!
Yesterday and today, I sent a flood of patches to the AppArmor mailinglist. You can easily see this as a (productive) DoS attack because AppArmor has a policy that every patch must be reviewed within a week...
Including some patches from the last days that didn't get a review yet, I have the answer - 42 patches pending for the AppArmor utils :-)
The biggest patches move the handling of change_profile and rlimit rules into classes and add tests for them. Another set of patches starts to unify the code of aa-logprof and aa-mergeprof (and fixes some bugs while doing that). The patch flood also contains some small bugfix and cleanup patches.
I'm quite sure the other developers will need some time to review all those patches *g*
If you are interested what exactly I changed, have a look at the AppArmor mailinglist archive and check my mails with the [patch] prefix.
For those who are more interested in statistics, here's the diffstat of my patch flood:
/aa-mergeprof | 517 +++++++++++++---------------------
/apparmor/aa.py | 363 +++++++++--------------
/apparmor/regex.py | 7
/apparmor/rule/__init__.py | 41 ++
/apparmor/rule/capability.py | 11
/apparmor/rule/change_profile.py | 19 +
/apparmor/severity.py | 13
/apparmor/tools.py | 11
/test/minitools_test.py | 11
/test/test-aa.py | 29 +
/test/test-baserule.py | 5
/test/test-capability.py | 32 ++
/test/test-change_profile.py | 18 +
/test/test-severity.py | 25 -
utils/aa-audit | 1
utils/aa-cleanprof | 1
utils/aa-complain | 1
utils/aa-disable | 1
utils/aa-enforce | 1
utils/aa-mergeprof | 50 ++-
utils/apparmor/aa.py | 34 --
utils/apparmor/regex.py | 10
utils/apparmor/rule/__init__.py | 6
utils/apparmor/rule/capability.py | 14
utils/apparmor/rule/change_profile.py | 173 +++++++++++
utils/apparmor/rule/network.py | 16 +
utils/apparmor/rule/rlimit.py | 265 +++++++++++++++++
utils/apparmor/severity.py | 4
utils/apparmor/tools.py | 7
utils/test/common_test.py | 22 +
utils/test/minitools_test.py | 25 -
utils/test/test-aa.py | 55 +++
utils/test/test-baserule.py | 4
utils/test/test-capability.py | 46 ---
utils/test/test-change_profile.py | 443 +++++++++++++++++++++++++++++
utils/test/test-example.py | 4
utils/test/test-network.py | 17 +
utils/test/test-rlimit.py | 468 ++++++++++++++++++++++++++++++
utils/test/test-severity.py | 201 ++++---------
39 files changed, 2183 insertions(+), 788 deletions(-)
Vor gut einer Woche ging der LinuxTag zu Ende. Zeit, kurz darüber zu schreiben ;-)
Ich war drei Tage in Berlin. Neben einigen interessanten Vorträgen war ich oft am openSUSE-Stand, um die Fragen der Besucher zu beantworten und habe mit 3 Runden openSUSE Jeopardy dafür gesorgt, das openSUSE-Motto "have a lot of fun" umzusetzen.
Außerdem hatte ich mich mit PostfixAdmin am Stand "einquartiert". Das erwies sich als Vorteil, weil deutlich mehr PostfixAdmin-Benutzer und -Interessenten zu mir kamen als letztes Jahr am Project Meeting Point.
An dieser Stelle vielen Dank an Bernhard, Jos und Sascha, die mit mir den openSUSE-Stand betreut haben, und ans Travel Support Programm für die Unterstützung bei den Reisekosten.
LinuxTag ended about a week ago. Time to write about it ;-)
I was in Berlin for three days. Besides listening to several interesting talks, I often was at the openSUSE booth, answered the visitor's questions and did 3 rounds of openSUSE Jeopardy to put the openSUSE motto "have a lot of fun" into practise.
Besides that, I "accomodated" myself with PostfixAdmin at the openSUSE booth. This turned out to be an advantage because many more PostfixAdmin users and might-become-users came to me (compared to the Project Meeting Point last year).
Thanks a lot to Bernhard, Jos and Sascha who manned the openSUSE booth together with me, and the travel support program for supporting me.
Letztes Wochenende (bis Dienstag) war ich bei der openSUSE conference, die diesmal in der "goldenen Stadt" Prag stattfand. Die Konferenz war sehr interessant - zum Einen die Vorträge, zum Anderen der "hallway track", bei dem ich viele Leute persönlich traf, die ich sonst nur namentlich aus Mailinglisten oder Bugzilla kenne.
Mein Workshop zu AppArmor wurde von rund 15 Personen besucht, die jetzt mehr über AppArmor wissen. Es wurden auch Fragen zum Packaging von Profilen gestellt - mit etwas Glück bekommen also ein paar Programme ein AppArmor-Profil in ihr Paket oder das Profil wird upstream zur Aufnahme zu den Standard-Profilen vorgeschlagen. Die Folien zum Workshop gibt es am Ende dieses Eintrags.
Zum openSUSE Jeopardy kamen nur 5 Personen. Diese haben aber alle mitgespielt und hatten sichtlich Spaß, die passenden Fragen zu meinen Antworten rund um Linux und openSUSE zu finden - vor allem Jan, der beide Runden (und somit zwei Flaschen Wein) gewann. Der IRC-basierte "Buzzer" hat dabei gut funktioniert und kommt mit etwas Glück beim nächsten LinuxTag nochmal zum Einsatz.
Am Montag war ich einer der wenigen Teilnehmer der BoF zur openSUSE landing page, die wir spontan etwas verlängerten. Daher fiel die admin@-BoF mehr oder weniger aus, was mangels anwesender Admins auch nicht wirklich schlimm war. Danach wurde ich von Coolo noch zum Filmen freiwillig gemeldet ;-) - die schrecklichen Publikums-Bilder vom Montag Nachmittag (Project Meeting etc.) und Dienstag (hauptsächlich Raum Riker) stammen von mir ;-)
Vielen Dank an alle, die zur openSUSE Conference beigetragen haben, and für die Unterstützung bei den Reisekosten!
Last weekend (until tuesday) I visited the openSUSE conference which was in the "golden town" Prague this year. The conference was very interesting. One part are the talks, the other part is the "hallway track" where I met lots of people I only knew from mailinglists or bugzilla.
About 15 persons took part in my AppArmor workshop, which means they now know more about AppArmor. Some also asked about packaging of AppArmor profiles. If we are lucky, some applications will receive a profile in their package, or their profile will be proposed for inclusion the the upstream set of default profiles. The slides I used in the workshop are available for download at the end of this post.
Only 5 persons came to my openSUSE jeopardy, but they all played and had fun in finding the matching questions for my answers about Linux and openSUSE. Jan must have had most fun - he won both rounds (and two bottles of wine). The IRC based "buzzer" worked quite well and will probably be used again at next LinuxTag.
On monday, I was one of the few participants of the BoF about the openSUSE landing page, which we extended time-wise. This also means the admin@ BoF was more or less dropped, which wasn't really bad because there weren't admins around. Afterwards, Coolo volunteered me ;-) to operate a video camera. The terrible pictures of the audience on monday afternoon (project meeting etc.) and tuesday (mostly room Riker) are from me ;-)
Thanks to everybody who contributed to the openSUSE Conference, and for the travel support!
Slides:
If you missed my talk at the openSUSE conference or want to see the slides (including notes) again - here we are:
1001 bugs - or: the golden rules of bad programming as PDF
(If you need an editable LibreOffice file, just drop me a note.)
|
Kommentare