Planet Exherbo

April 16, 2014

Wulf C. Krueger

Miscellaneous Updates to Gerrit, Jenkins & friends

Over the last few weeks, I’ve made a few changes to Exherbo’s Gerrit and Jenkins installation:

  • Build artifacts are stored in Jenkins:

    If a build is unsuccessful, the Paludis build log, config.log (if it exists) and the cave-resolve command used are stored. Since build artifacts are associated with a project (i. e. the repository) and not individual builds, the files have the build number prepended in their file name:
    77_build.log
    77_cave-resolve.txt
    77_config.log

    If a build is successful, only the cave-resolve command and the detected dependencies are archived:

    78_cave-resolve.txt
    78_dependencies.txt

    This change is effective immediately for all exheres repositories in Jenkins. If you have further suggestions of files to archive, please let me know.

 

  • Due to the recent OpenSSL Heartbleed bug issue, I’ve re-issued the SSL certificates on my machines on April, 11th 2014. If you have a password login on galileo, now is the time to change it. For galileo.mailstation.de, the host key fingerprints are as follows:

1024 a8:8c:7d:87:3d:a6:61:78:8d:59:f5:52:d7:b1:3c:34 (DSA)
256 f1:08:b0:12:66:1c:72:af:2d:d8:c7:15:ca:13:f6:f2 (ECDSA)
256 68:1c:27:e2:8e:b5:42:62:98:8a:f3:04:45:c1:60:f9 (ED25519)
2048 37:38:6e:81:4a:53:24:4d:b0:fb:c7:3e:f0:1d:63:8c (RSA1)
2048 06:57:ff:b7:e6:6f:c8:31:76:c8:9a:7c:37:d7:f5:47 (RSA)

The web server’s certifacte has the following fingerprints:
  • SHA-256 Fingerprint:
    85 3D 47 8B A5 44 76 A0 09 96 9F 15 4A 9A F8 C5 1C 95 D1 1D 92 4E 78 06 0D F6 E5 7B 1B C5 B2 07
  • SHA-1 Fingerprint:
    0D E8 77 4F 74 67 AB 61 12 97 A5 57 84 1F B4 51 C1 1D D4 19

 

  • Gerrit was updated to version 2.8.4. There are quite a few bug fixes in the release notes but probably most important for those of you who experienced issues with the side-by-side diff view in the new change screen are the fixes they applied to it.

 

There’s more to come but that’s going into another post. :-)

by Wulf Krueger at April 16, 2014 01:18 PM

March 05, 2014

Wulf C. Krueger

Re-testing patches in Gerrit with Jenkins

A recent request concerned the possibility to re-test patches patches in Gerrit with Jenkins. I’ve now added a very simple switch for that:

In any given given change (but your own!), you can add a comment with “+1 Retest” set as a “verdict”. On the old change screen (really, change to the new one, it’s much nicer), it looks like this:

Retest: Old change screen

 

On the new change screen, it looks like this:

Retest: New change screen

It’s really, truly easy. You can even do it multiple time – just uncheck the “Retest” checkbox (new screen) or set “0 Retest” (old screen) first and then set it again.

This works for any change as long as you are a registered user – any change but your own. Unfortunately, the Jenkins’ Gerrit-Trigger plugin simply ignores the “CommentAdded” event completely for ones own changes. If you want those re-tested, just amend your commit (no need to actually change anything; the commit timestamp will be updated) and Jenkins will see the patch’s new revision and re-run the test.

 

On a side note, I’d like to apologise for the instability for about 1,5 days earlier this week. There were some really nasty hardware/software issue that I had to sort out. This is done now, though, and things are running smoothly again.

 

by Wulf Krueger at March 05, 2014 06:13 PM

February 27, 2014

Wulf C. Krueger

Automated stage building with Jenkins

For quite some time now, I’ve been working on the automatic creation of Exherbo stages for AMD64 (x86_64) and X86 using Jenkins.

Till now, Exherbo’s stages were created manually by one of us Exherbo core developers and usually basically “on-demand” or when they were major changes. This finally changed yesterday.

Using the jobs stage_amd64 and stage_x86 respectively, the stages…

  • are built using a modified stage building script – each stage is build from scratch. The latest stage gets unpacked and used to build a new one. I call this: Implicit pro-active quality assurance. No pbins are used in the entire process. Everything is fresh and new, just for you.
  • the sources are kept right next to the stages at https://galileo.mailstation.de/stages/sources. You can see right there what sources were used.
  • the XZ archive is added to the job (the most recent ten stage archives are kept on their respective job). Like this, you can always check the exact build log for the stage you want and rest assured both are right there at your fingertips.
  • next, the successfully built stage is deployed to https://galileo.mailstation.de/stages/. exherbo.org is undergoing maintenance but you really want your Exherbo? Download a stage from this alternative location, sync your repositories from Gerrit and you’re unstoppable!
  • and finally automatically transferred to our traditional http://dev.exherbo.org/stages/ where some “extra magic” is performed by Jenkins that creates the “current” symlinks, updates the checksum files, etc.

And this happens every single day. The entire process is completely scalable as well – once the cross stuff is production-ready, I’m going to build ARM stages as well and it will be done by simply copying a Jenkins job and changing a few lines. A milestone for Exherbo.

We just made major changes? Wait a few hours, get them in your stage for your new Exherbo installation.
You somehow got a broken stage? Use an older one, compare them, go nuts with them. There are always at least 10 stages per architecture to choose from.
And if a stage fails to build? Well, the next day it will be fixed because we’re watching over the entire process.

Isn’t this incredibly awesome?

And you can even play a round of Bullshit Bingo using this very post! ;-)

 

by Wulf Krueger at February 27, 2014 08:58 PM

February 23, 2014

Bryan Østergaard

So I was dox'ed yesterday

and nobody gives a fuck.

Here's the associated spam:
14:53 < ~dd0sb0ss> rip
14:53 < ~dd0sb0ss> PARTY AT Vølundsgade 31, 3. th. 2200 København N
14:53 < ~zsasz> ur unicode is broken dd0sb0ss
14:53 < ~dd0sb0ss> fuq
14:54 < ~dd0sb0ss> THE OFFICIAL FREENODE PARTYLINE IS REACHABLE AT +4533137886
14:54 -!- dd0sb0ss was kicked from #freenode by kloeri_ [dd0sb0ss]

Ignoring the broken unicode that's actually the correct information. Well done on finding this information that has been publically available (by my own choice) for several years.

It's never been hard to find me and that's not changing in the future just because of some silly kids either. Unlike these kids I'm actually proud of what I do and I'm more than happy to stand by my actions with my real name and even address widely available.

And for all those sensible people out there just shaking your heads at this sillyness - you're welcome to visit, especially if you are interested in open source software or need a consultant on some project :) I'd suggest contacting me by email first though.

PS. Thanks to GNAA for this obvious advertising opportunity.

February 23, 2014 08:49 PM

January 03, 2014

Wulf C. Krueger

Jenkins: Build-testing for every single commit

As of yesterday, I’ve drastically increased the number of testing machines in Jenkins (from two to 21!). This enables me to poll for changes in git every five minutes and automatically start a testing run for every single commit – regardless of it entering via Gerrit or not. (Note: This is in addition to the Gerrit trigger I’ve been using from day one on, not replacing it.)

Here’s an example from today:

https://galileo.mailstation.de/jenkins/job/arbor/67/

Apart from looking at Jenkins directly, you can join the #exherbo-bots channel where the jenkins-exherbo bot announces all test results. Here’s an example for that:

[03.01.2014 13:42:59] <irker657> Exherbo: pipping arbor:master * 76ec9309669d / packages/sys-apps/grep/grep-2.15.exheres-0 packages/sys-apps/grep/grep-2.16.exheres-0: grep: Bump to 2.16 http://tinyurl.com/pyfhbql
[03.01.2014 13:46:50] <jenkins-exherbo> Project arbor build #67:SUCCESS in 1 min 5 sec: https://galileo.mailstation.de/jenkins/job/arbor/67/

I hope you’ll find this useful and will actually look at the results since it will find out if you missed a dependency. And it potentially shows you automagic dependencies.

 

by Wulf Krueger at January 03, 2014 04:29 PM

Version bump to systemd-43 / Move to /usr

(This is the same as the news item but I want this to get maximum exposure.)

Read ALL of this, it’s important to everyone using systemd.

Up to systemd[=42] we installed boot-critical components to / and others to /usr. This split was causing issues with respect to tmpfiles, intrinsic dependencies and dependencies on stuff on /usr.

systemd[=43] finally removes this split and installs everything but udev and pam stuff to /usr.

This won’t matter much to you if you don’t have /usr split from / (it should not be split; cf. http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken).

Even if you don’t have /usr != /, you need to update all packages that install to /${LIBDIR}/systemd/system because that got moved, too, of course. I’ve rev-bumped all packages, that install their own custom systemd units but even after you’ve updated those, you’ll still have some in /${LIBDIR}/systemd/system. Find out which package they belong to (use cave owner) and re-install them.

Should you forget to do so, you might end up in systemd’s emergency mode. If that happens, don’t panic. Get your network connection up and continue updating/re-installing. You’ll live, I promise.

There might be orphaned systemd units left behind. Check those on your own and decide if you need to move them to /etc/systemd/system. If you do, don’t forget to systemctl disable and then enable them.

You’ll also have some broken symlinks in /etc/systemd/system pointing to /${LIBDIR}/systemd/system. To fix those, all you have to do is disable and re-enable the respective unit. Here’s how to do it quickly and easily:

for link in $(find -L /etc/systemd/system -type l); do
systemctl disable $(basename ${link});
systemctl enable $(basename ${link});
done

Final sanity checks:

1. Is /${LIBDIR/systemd gone? If so, carry on; if not, you missed a step. Go back and find out which one.

2. No broken symlinks in /etc/systemd/system anymore? (“find -L /etc/systemd/system -type l” doesn’t output anything) If so, carry on. Otherwise, you missed a step. Go back and find out which one.

If you do NOT have /usr separated from /, you’re done now and it should be safe to reboot if you so desire.

If you do have /usr separated from /, you’ll have to use an initramfs (preferrably created by dracut) for booting from systemd[=43] onwards.

The first step to using an initramfs is enabling CONFIG_BLK_DEV_INITRD in your kernel, recompiling and installing it. If you want to switch from a custom initramfs to dracut, don’t forget to empty CONFIG_INITRAMFS_SOURCE in your kernel configuration either if you have been using it before.

If you want to use dracut (sys-boot/dracut[>=14]), install it and add

add_dracutmodules+=”98usrmount”

to /etc/dracut.conf. If you have some weird configuration, you might need to add further dracut or kernel modules. In general, though, dracut is going to pick up everything you’ll need to boot.

Now run dracut to create your shiny new initramfs:

dracut -H <initramfs filename incl. path> <kernel version>

e. g.

dracut -H /boot/init-3.2.5.gz 3.2.5-00001-gf74dd96

-H (or –hostonly) tells dracut to build an initramfs for the machine it’s running on. Leaving it out should create a HUGE generic initramfs that should bascially be able to boot everything. In reality, leaving -H out usually builds something that doesn’t boot anything.

Next, update grub’s config so that it includes a root= parameter for the kernel command line and your new initramfs, e. g.:

(for grub-0.9x’s menu.lst)
title Exherbo Linux
root (hd0,1)
kernel /kernel-3.2.5-00001-gf74dd96 root=/dev/primary/uselv
initrd /init-3.2.5.gz

or

(for grub-1.9x’s grub.cfg)
menuentry “Exherbo Linux” {
set root=(hd0,1)
linux /kernel-3.2.5-00001-gf74dd96 root=/dev/primary/uselv
initrd /init-3.2.5.gz
}

Do NOT forget the root= parameter. It’s essential.

(Of course, you need to adjust paths and filenames to your setup but if I need to tell you that, you shouldn’t be using Exherbo in the first place.)

If you’re using a custom initramfs, you must make sure that you mount /usr as early as possible but definitely before systemd (/sbin/init) starts. If you’re rolling your own initramfs, you should know how to accomplish that.

After you’ve updated your grub configuration, systemd is updated and your kernel is ready, too, say a little prayer ;-) and reboot.

Best regards, Wulf

by Wulf Krueger at January 03, 2014 12:56 PM

Samba has no maintainer on Exherbo any more

After having worked with Samba for almost 20 years, I'm giving up now.

I have submitted patches upstream when Samba (and I :) ) was young,
I've proof-read books on Samba and NTLM but where they're going, I
can't follow them any more.

- Samba 4.1.0 doesn't even build for me any more and I'm too
frustrated to figure it out.

- In Samba 4.1.0, SWAT (the configuration web interface) seems to have
been removed. I might be missing something but if I'm not, that sucks.

- Samba's "new" crappy build system WAF is just horrible and I simply
don't understand it. I asked for help (and it was offered) but nothing
was ever done.

- New versions of Samba 4 try to build against already installed
versions in the live filesystem and I don't understand WAF enough to
fix that.

I've just removed myself from BUGS_TO. If you want it, take it but if
you do, do me a favour and do a better job than me and make sure
you're weird enough to understand (and ideally like) WAF.

by Wulf Krueger at January 03, 2014 12:55 PM

Exherbo’s Patch Queue

Today, on May, 5th 2012, our patch queue on Zebrapig the Ugly did the impossible; it achieved re-floration! ;-)

 

[05.05.2012 21:57:36] <Philantrop> !pl

[05.05.2012 21:57:37] [Notice] -zebrapig to #exherbo- 0 patches in queue:

 

by Wulf Krueger at January 03, 2014 12:54 PM

paste.pocoo.org is gone for good. Please re-submit your patches.

paste.pocoo.org is gone for good. Please re-submit your patches.

Here’s the list of affected patches:

[28.04.2012 17:24:28] [Notice] -zebrapig- 13 matching patches in queue:
[28.04.2012 17:24:28] [Notice] -zebrapig- http://paste.pocoo.org/raw/510003/ ::sydbox (submitted by worr 161 days and 17 hours ago): [PATCH] Fixed race condition in sydbox
[28.04.2012 17:24:28] [Notice] -zebrapig- http://paste.pocoo.org/raw/579419/ ::kde (submitted by heirecka_ 17 days and 5 hours ago): [PATCH 1/2] Move stuff from qt-creator-scm to its exlib
[28.04.2012 17:24:28] [Notice] -zebrapig- http://paste.pocoo.org/raw/582592/ ::arbor (submitted by SuperHeron 11 days and 20 hours ago): [PATCH] app-shells/bash-completion[=scm]: /etc/bash_completion.d is
[28.04.2012 17:24:28] [Notice] -zebrapig- http://paste.pocoo.org/raw/582875/ ::x11 (submitted by moben 11 days and 8 hours ago): [PATCH 1/2] mesa multilib: Use multiunpack exparam
[28.04.2012 17:24:30] [Notice] -zebrapig- http://paste.pocoo.org/raw/583000/ ::arbor (submitted by keruspe 11 days and 1 hour ago): [PATCH] llvm: allow gcc 4.7.0
[28.04.2012 17:24:32] [Notice] -zebrapig- http://paste.pocoo.org/raw/584582/ ::mawww (submitted by heirecka 8 days and 3 hours ago): [PATCH] Fix building of espeak
[28.04.2012 17:24:34] [Notice] -zebrapig- http://paste.pocoo.org/raw/585239/ ::arbor (submitted by SuperHeron 7 days and 4 minutes ago): [PATCH] dev-lang/python: Add .pc file into alternatives
[28.04.2012 17:24:36] [Notice] -zebrapig- http://paste.pocoo.org/raw/585373/ ::anderslm (submitted by Philantrop 6 days and 18 hours ago): [PATCH] dev-libs/dotconf: ::anderslm -> ::media
[28.04.2012 17:24:38] [Notice] -zebrapig- http://paste.pocoo.org/raw/586847/ ::kde (submitted by Apetrini 3 days and 13 hours ago): [PATCH] networkmanagement: bump to 0.9.0.1-r1, fix dep
[28.04.2012 17:24:40] [Notice] -zebrapig- http://paste.pocoo.org/raw/588002/ ::ingmar (submitted by nakamuray 1 day and 3 minutes ago): [PATCH 1/3] notmuch: version bump to 0.12
[28.04.2012 17:24:42] [Notice] -zebrapig- http://paste.pocoo.org/raw/588028/ ::arbor (submitted by keruspe 23 hours and 6 minutes ago): [PATCH 1/3] autoconf: bump to 2.69
[28.04.2012 17:24:44] [Notice] -zebrapig- http://paste.pocoo.org/raw/588037/ ::x11 (submitted by keruspe 22 hours and 47 minutes ago): [PATCH] xkeyboard-config-scm: fix build
[28.04.2012 17:24:46] [Notice] -zebrapig- http://paste.pocoo.org/raw/588130/ ::kde (submitted by heirecka_ 19 hours and 56 minutes ago): [PATCH] Version bump to akonadi-1.7.2

by Wulf Krueger at January 03, 2014 12:54 PM

Gerrit Code Review for Exherbo

As an experiment,  I’ve installed a Gerrit Code Review instance on my server for use with Exherbo.

Gerrit is a code review tool and allows for

 

- discussing patches and keeping the results for future reference
- get notified by email about every change (if you want)
- easily work on every official Exherbo repository (more to come later if people are interested)
- contributors to get their repositories added to Gerrit as well (optional)

 

You’ll find an introduction to Gerrit here:

 

 

 

Random thoughts:
- If Gerrit isn’t being used, it will go away. This is an experiment because I think Zebrapig (albeit its undisputed merits) has inherent limitations that can’t be easily fixed.
- Gerrit is not supposed to supersede Zebrapig but to complement it.
- There have been controversial internal discussions about this. Please keep in mind that I don’t mean to take anything away from anyone but to improve Exherbo.

 

Notes about the installation:
- The Gerrit instance fetches and pushes repository updates every 15 minutes. Gerrit now replicates merged changes pretty much immediately. This sometimes/rarely fails on the first attempt for various reason. I’ve implemented a fallback that occurs every 15 minutes.
- You need an OpenID to register. This is mostly for copyright reasons as well and probably won’t change. (I’ve evaluated a lot of other options; they all had in common that they couldn’t be used together with other methods.)
- You MUST use your real name for copyright reasons.
- In the future there might be a mailinglist that gets all notifications from Gerrit. For now, please subscribe/unsubscribe to/from notifications yourself as you see fit.

 

 

 

How to use Gerrit:

 

 

Registration and initial setup: 

 

 

2. In the upper right corner, click “Register”.
3. In the next screen, enter your full name (for copyright reasons, it must be your real name) and choose a user name.
4. Paste your ssh public key into the box at the bottom and click “Add”. If you don’t have one, there’s an explanation about creating one.
5. Click ”Continue”.
6. Click on your full name in the upper right corner (where “Register” was), and choose “Settings”.
7. Enter a git/https user name. You can use the one you chose in step 3.

 

 

Cloning a repository:

 

1. Click “Projects”, “List”, then choose a project.
2. You should see several methods for cloning the project, the easiest way is to choose the ssh method.
3. Clone, e. g. git clone ssh://<user name>@galileo.mailstation.de:29418/alip
4. Install a hook that sets a Change-Id automatically (choose one of the two alternatives):

scp -p -P 29418 <your username>@galileo.mailstation.de:hooks/commit-msg <local path to your repository>/.git/hooks/
curl -o <local path to your repository>/.git/hooks/commit-msg https://galileo.mailstation.de/gerrit/tools/hooks/commit-msg

 

 

Submitting:

 

There are several methods to upload changes. The easiest is to just push:

 

1. Work on your copy of the repository, commit.
2. Push your changes: git push origin HEAD:refs/for/master

 

 

You can use git review for easily setting up your repository clone and submitting patches, too. I haven’t tested it myself, though. It’s quite nice, use it!

 

 

by Wulf Krueger at January 03, 2014 12:54 PM

News about Gerrit, Jenkins & friends

Here are a few things I’ve updated on Gerrit, Jenkins and associated tools:

  1. Gerrit
    • The Gerrit bot, gerritwk23, has now support for !pl (and pl in a query). It’s just like zebrapig’s !pl.
    • I’ve updated Gerrit in mid-Decembre. Since then, you can switch to a newly designed “Change View” which you’ll find under your account’s settings in the “Change View” option. There’s also an associated “Diff View” option to set your preferred diff style if you switch to the new Change View.

2. Jenkins

    • In its build logs, you’ll now find the mounts, the cave resolve command and the (likely) dependencies gathered from the installed package. Dependency information might not be 100% accurate so please take it with a grain of salt but it’s usually a good indicator.
      Look out for “**************************************************************” to find that information.

 

If you have any ideas about what else to improve, please let me know.

by Wulf Krueger at January 03, 2014 12:54 PM

Another good reason to use Gerrit: Jenkins is at your service

If it’s not yet good enough for you that using Gerrit

  • is even easier and faster than using zebrapig (you just push your change and you’re done! And if you use git review it’s getting even easier.),
  • the review turn-around times are often better when using Gerrit than zebrapig,
  • discussing patches can be done both when you’re on IRC and on Gerrit,

then here’s another good reason to use it: I’ve set up Jenkins for all repositories on Gerrit to build every change in a chroot (including sydbox-1, pinktrace-1 and docs).

For now, all reports only go to me (and anyone else who wants to get an email with the result included) and Jenkins will not report back to Gerrit because the setup is quite fragile yet and I want to be sure it works properly before making it do more.

No idea how to use Gerrit? Just read my earlier posts Gerrit Code Review for Exherbo and Gerrit for Core-Devs. Of course, you can ask me, too. :-)

 

by Wulf Krueger at January 03, 2014 12:54 PM

Exherbo’s Gerrit for 3rd party repositories

Exherbo’s Gerrit has left its infancy and, thus, I can now add 3rd party repositories to our Gerrit installation. Please just let me know if you’d like that.

  • Requirements:
    • Your repository must use git.
    • You must be willing to add a Gerrit user (github: Gerrit-Exherbo) to your repository as a contributor.  Here’s the public key.
    • Your repository should be hosted on one of the big git hosting providers, e. g. github (preferred) or gitorious. Ask me if your repository is hosted elsewhere; I do make exceptions.
    • Please let me know the push URI for your repository.

Once I’ve set you up, you can immediately work on Gerrit patches for your repository. You are, of course, its sole owner and fully responsible for it.

By default, Exherbo’s core devs (but nobody else) will be able to +2 Gerrit changes for your repository, too. This is meant to potentially help you keep your repository up to date (e. g. when mass changes occur). This is entirely optional, though, and you can choose to opt-out at any time if you don’t like it; you only need to let me know.

by Wulf Krueger at January 03, 2014 12:54 PM

Gerrit installation updated to the 2.7 release, pesky “internal server error” fixed

I’ve just updated the Gerrit installation to the 2.7 release and fixed the pesky “internal server error” that occurred when entering a user name or similar.

I’ve also updated my posts on Gerrit and the FAQ-like post for core devs:

Experiment: Gerrit Code Review for Exherbo

Gerrit for Core-Devs

 

 

by Wulf Krueger at January 03, 2014 12:54 PM

Gerrit for Core-Devs

There have been a few questions and potential misunderstandings I’m going to try to address here. I’ll update this post if new stuff comes up.

  • Getting the foo Or: How do I become a Core-Dev on Gerrit?
    Simple: You register with your OpenID then you ask any other core dev to add you to the group. At least Bo “zlin” Ørsted Andresen and I know how to do it and every member has the necessary privileges.
  • Reviewing Or: +1+1 != +2
    Every registered user can comment and/or +1 a change. This is an indication said user has reviewed the patch and, ideally, tested it. It’s basically only an opinion, though.
    Only Core-Devs can +2 a change. This means they’ve reviewed and tested that change and are approving it. The change then will get merged and pushed.
    It’s important to remember, though, that +1′s do NOT add up. You can +1 a change a hundred times but it will still need one bold man (or woman) to +2 it.
    Important as well, use the “Publish and Submit” button, not the “Submit” button if you want to get a change merged.
  • What about testing (or the lack of)?
    Nothing has changed compared to Zebrapig. Everyone who +2′s a change at least (ideally, +1 would indicate you tested the thing, too!) is expected to have actually tested it. If you +2 it but didn’t test it, we’re going to slowly roast you over a scented candle. 
  • What’s the easiest way to test a patch?
    Personally, I look at the patch, at the “Downloads” line, I click on “Patch” and then click on the small clipboard icon next to the git fetch comand. That adds said line to your clipboard. Next, I cd into the respective repository, paste the line we just copied and append “| git am”. That’s it, patch applied, now test it!
  • Merging & pushing (no, not like that, you pervert!)
    Gerrit now pushes merged changes directly to our repositories. This means, once you +2 a change (cf. first point), you push it.
  • Command line tricks or How do I…
    … most easily review a change?

    git review -d -t <change number, e. g. 202>

    … merge a boat-load of patches I reviewed and tested at once?

    On your branch with the changes applied: ssh -p 29418 <username>@galileo.mailstation.de gerrit review –code-review +2 –submit $(git rev-list gerrit/master..HEAD)

    … query for a specific change?

    ssh -p 29418 <username>@galileo.mailstation.de — gerrit query –comments change:212

    …  get a list of all open changes?

    ssh -p 29418 <username>@galileo.mailstation.de — gerrit query status:open (add a “project” parameter if you want only changes for a certain repository, e. g. “project:arbor”)

    … add a comment from the command line?

    ssh -p 29418 <username>@galileo.mailstation.de — gerrit review -m “\”At the very least this commit message should explain why we have to put PWD in PYTHONPATH which can’t be quoted properly… But other than that, seems sensible at least for now.\”" $changeid

by Wulf Krueger at January 03, 2014 12:54 PM

October 13, 2013

Ciaran McCreesh

September 24, 2013

Ali Polatel

A Study in Sydbox

Due to the fact that sydbox is a low level tool which inspects system calls, debugging its bugs become cumbersome at times. GDB and Valgrind are two valuable tools which comes to rescue.

I hit this bug when I was investigating Exherbo bug 369. I wrote a small C program to reproduce the problem:

    #include <errno.h>
    #include <string.h>
    #include <stdio.h>
    #include <stdlib.h>
    #include <unistd.h>
    #include <fcntl.h>
    #include <elf.h>
    #include <sys/auxv.h>
    #include <sys/types.h>

    int main(void)
    {
        pid_t pid;
        int pfd[2];
        unsigned long val;
        char buf[1024];
        int auxfd;

        val = getauxval(AT_SECURE);
        fprintf(stderr, "getauxval(%lu) = %lu (errno:%d %s)\n",
            AT_SECURE, val, errno, strerror(errno));

        pipe(pfd);
        pid = fork();
        if (pid == 0) {
            /* 23 is AT_SECURE as defined in elf.h */
            char *const argv[] = {"sh", "-c", "od -t u8 | awk '{if ($2 == 23) print }'", NULL};
            close(pfd[1]);
            dup2(pfd[0], STDIN_FILENO);
            execvp(argv[0], argv);
        } else {
            close(pfd[0]);
            auxfd = open("/proc/self/auxv", O_RDONLY);
            while (read(auxfd, buf, 1024) > 0)
                write(pfd[1], buf, 1024);
            close(pfd[1]);
        }
    }
    

I compiled this small program with gcc and when I run it under sydbox-1 I witnessed an interesting output:

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % ./sydbox ./a.out
getauxval(23) = 0 (errno:0 Success)
sydbox@1379972151: bash[26306.0:26305] sys:4|stat| PANIC_KILL

Note there is not a prompt at the end. sydbox-1 hung right after logging PANIC_KILL. Before firing up a debugger and start to debug, let’s gather as much information as possible by checking whether verbose logging will tell us something:

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % ./sydbox -m log/console_level:511 ./a.out
...
sydbox@1379972294: [wait(-1, 0x857f) = 28848] WIFSTOPPED,sig=133|(null)|
sydbox@1379972294: [wait(-1, 0x857f) = 28848] WIFSTOPPED,sig=133|(null)|
sydbox@1379972294: [wait(-1, 0x857f) = 28848] WIFSTOPPED,sig=133|(null)|
sydbox@1379972294: bash[28848.0:28847] sys:4|stat| entering system call
sydbox@1379972294: bash[28848.0:28847] sys:4|stat| PANIC_KILL
sydbox@1379972294: bash[28848.0:28847] sys:4|stat| trace_kill(sig:9) failed (errno:3|ESRCH| No such process)
sydbox@1379972294: process 28848 ignored

After a couple of wait(2) loops the stat(2) system call handler - which takes magic commands as input paniced for some reason and called the function panic() which decided to kill the traced process.

So far so good. Although this looks unrelated to the bug at hand, it is still a good idea to fix it when you have some free time. Let’s fire up the debugger and try to do a reverse debug. I use cgdb which provides a nice curses frontend to gdb.

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % libtool --mode=execute cgdb --args ./sydbox -m log/console_level:511 ./a.out
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/alip/src/sydbox/sydbox-1/src/.libs/lt-sydbox...done.
(gdb)

First let’s break on main(), run the program and when the breakpoint is hit set another breakpoint on sys_stat (the stat(2) system call handler function) and start [recording][recording] the program instructions and continue.

(gdb) break main
Breakpoint 1 at 0x419d98: file sydbox.c, line 1255.
(gdb) run
Starting program: /home/alip/src/sydbox/sydbox-1/src/.libs/lt-sydbox -m log/console_level:511 ./a.out
warning: no loadable sections found in added symbol-file system-supplied DSO at
0x7ffff7ffa000
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?

Breakpoint 1, main (argc=4, argv=0x7fffffffd428) at sydbox.c:1255
(gdb) record
(gdb) break sys_stat
Breakpoint 2 at 0x411d58: file syscall-special.c, line 150.
(gdb) cont
Continuing.
Do you want to auto delete previous execution log entries when record/replay buffer becomes full (record full stop-at-limit)?([y] or n)

This takes some time. When the record/replay buffer is full, gdb kindly asks you whether you want to continue execution and auto-delete previous log entries or stop instantly and investigate further on. We’re not interested in the previous log entries so let’s just hit [enter] and continue.

Process record and replay target doesn't support syscall number -1
Process record: failed to record execution log.

[process 8201] #1 stopped.

This is a weird message by gdb which fortunately I have seen before. sydbox-1 makes use of some rather new system calls which gdb does not support. The newest of those are process_vm_readv and process_vm_writev which were added to Linux as of kernel version 3.2. I’ll add a small one-time tweak to the auto-generated pinktrace/system.h file telling sydbox-1 that these system calls are not supported by the system and let it use the good old ptrace(2) way of reading one long at a time:

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % cd ../pinktrace
alip@hayalet ~/src/sydbox/sydbox-1/pinktrace (git)-[master] % sed -i -e '/^#define PINK_HAVE_PROCESS_VM_\(READ\|WRITE\)V/s/1/0/' system.h
alip@hayalet ~/src/sydbox/sydbox-1/pinktrace (git)-[master] % grep PINK_HAVE_PROCESS system.h
#define PINK_HAVE_PROCESS_VM_READV      0
#define PINK_HAVE_PROCESS_VM_WRITEV     0
alip@hayalet ~/src/sydbox/sydbox-1/pinktrace (git)-[master] % make clean && make -j

Now let’s return to src/ and rebuild sydbox:

alip@hayalet ~/src/sydbox/sydbox-1/pinktrace (git)-[master] % cd ../src
alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % make clean && make -j

Let’s re-run sydbox to make sure the bug is still there:

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % ./sydbox ./a.out
getauxval(23) = 0 (errno:0 Success)
0000340                   23                    0

This is where my luck kicks in! The bug is not there anymore. Now we know the problem is actually in pinktrace, the underlying library providing thin wrappers around the ptrace(2) system call. We have also narrowed the problem down to one of process_vm_readv and process_vm_writev functions. Now let’s go back to turn the #defines on and retry with gdb:

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % cd ../pinktrace
alip@hayalet ~/src/sydbox/sydbox-1/pinktrace (git)-[master] % sed -i -e '/^#define PINK_HAVE_PROCESS_VM_\(READ\|WRITE\)V/s/0/1/' system.h
alip@hayalet ~/src/sydbox/sydbox-1/pinktrace (git)-[master] % grep PINK_HAVE_PROCESS system.h
#define PINK_HAVE_PROCESS_VM_READV      1
#define PINK_HAVE_PROCESS_VM_WRITEV     1
alip@hayalet ~/src/sydbox/sydbox-1/pinktrace (git)-[master] % make clean && make -j
alip@hayalet ~/src/sydbox/sydbox-1/pinktrace (git)-[master] % cd ../src
alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % make clean && make -j

Now we will start recording only after we enter the sys_stat() function:

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % libtool --mode=execute cgdb --args ./sydbox -m log/console_level:511 ./a.out
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/alip/src/sydbox/sydbox-1/src/.libs/lt-sydbox...done.
(gdb) break sys_stat
Breakpoint 1 at 0x411d58: file syscall-special.c, line 150.
(gdb) run
...
sydbox@1379974050: [wait(-1, 0x857f) = 31387] WIFSTOPPED,sig=133|(null)|
sydbox@1379974050: [wait(-1, 0x857f) = 31387] WIFSTOPPED,sig=133|(null)|
sydbox@1379974050: bash[31387.0:31386] sys:4|stat| entering system call 

Breakpoint 1, sys_stat (current=0x62fa00) at syscall-special.c:150
(gdb) record
(gdb) cont
Continuing.
Process record and replay target doesn't support syscall number -1
Process record: failed to record execution log.

[process 31382] #1 stopped.
0x00007ffff78fa048 in process_vm_readv () from /usr/lib/libc.so.6

Gdb kindly stopped where the bug is actually located. Let’s stop recording and single-step to see what error this function returns.

(gdb) record stop
Process record is stopped and all execution logs are deleted.
(gdb) n
Single stepping until exit from function process_vm_readv, which has no line number information.
_pink_process_vm_readv (pid=31387, local_iov=0x7fffffffbe10, liovcnt=1, remote_iov=0x7fffffffbe00, riovcnt=1, flags=0) at vm.c:199
(gdb) n
(gdb) p r
$1 = -1

The function _pink_process_vm_readv is returning -1 which is the negated errno value EPERM. This makes pink_vm_cread_nul fail with -1 which in turn makes pink_read_vm_data_nul return -1 which in turn makes syd_read_string function to call panic(). Now we have a detailed information about the panic happening.

Another valuable tool to aid in debugging system call inspection is strace. Let’s check with strace what these stat(2) system calls’ arguments are. I have not updated my strace.git tree for a while and trying to compile it I have found a problem due to an inconsistency between glibc and linux kernel headers which keruspe fixed for pinktrace with commit e1aa031 a week ago:

alip@hayalet ~/src/strace (git)-[master] % make -j1
...
gcc -DHAVE_CONFIG_H -I.  -I./linux/x86_64 -I./linux -I./linux  -Wall -Wwrite-strings -D__ALIP_WAS_HERE -g -ggdb3 -O2 -march=native -D__PINK_IS_BEHIND_THE_WALL -MT process.o -MD -MP -MF .deps/process.Tpo -c -o process.o process.c
In file included from process.c:66:0:
/usr/include/linux/ptrace.h:58:8: hata: 'struct ptrace_peeksiginfo_args' yeniden tanımlanmış
 struct ptrace_peeksiginfo_args {
        ^
In file included from defs.h:169:0,
                 from process.c:37:
/usr/include/sys/ptrace.h:191:8: bilgi: originally defined here
 struct ptrace_peeksiginfo_args
        ^

struct ptrace_peeksiginfo_args is a recent addition to ptrace.h headers and both sys/ptrace.h of glibc-2.18 and linux/ptrace.h of Linux define it. Thus defining the same struct twice fails. Fortunately we have seen this error before with the IA64 architecture where the same happens with struct pt_all_user_regs and struct ia64_fpreg.

Having hit another totally unrelated bug, I have prepared a patch and tested it:

alip@hayalet ~/src/strace (git)-[master] % make
gcc -Wall -Wwrite-strings -D__ALIP_WAS_HERE -g -ggdb3 -O2 -march=native -D__PINK_IS_BEHIND_THE_WALL   -o strace bjm.o block.o count.o desc.o file.o io.o ioctl.o ipc.o loop.o mem.o mtd.o net.o pathtrace.o process.o quota.o resource.o scsi.o signal.o sock.o strace.o stream.o syscall.o system.o term.o time.o util.o vsprintf.o  
make[2]: `/home/alip/src/strace' dizininden çıkılıyor
make[1]: `/home/alip/src/strace' dizininden çıkılıyor

It compiles and runs fine. Time to prepare a git-format-patch and send to strace-devel mailing list. These git tools make it really easy to prepare patches and submit them. Here is the link to the actual mail.

So far so good. Another bug fixed and submitted upstream. Let’s go ahead and see whether strace can make sense of those stat(2) arguments:

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % ~/src/strace/strace -f -e stat ./a.out
Process 18698 attached
[pid 18697] +++ exited with 0 +++
stat(0x9db090, {...})                   = 0
stat(0x485897, {...})                   = 0
stat(0x485897, {...})                   = 0
...

Note the -f argument. Remember our panic line started with bash[31387.0:31386] this does not happen in my small program but in bash which is spawned right after fork(2). The -f argument of strace follows forks.

Now the question is what those hex values in the first arguments are. strace usually does a good job in decoding strings so something is weird going on here. Let’s go one step ahead and try to trace strace using strace itself. One has to be careful here not to use -f with the first strace because only one process may trace a process at a time and we want the first strace to only trace strace not our small program a.out. We also use the option -e 'signal=!all' so that we filter some of the unwanted output:

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % strace -q -e 'process_vm_readv' -e 'signal=!all' -- strace -e 'signal=!all' -f -e stat ./a.out
getauxval(23) = 0 (errno:0 Success)
Process 22286 attached
[pid 22285] +++ exited with 0 +++
process_vm_readv(22286, 0x7fff71faed40, 1, 0x7fff71faed50, 1, 0) = -1 EPERM (Operation not permitted)
stat(0x1938070, process_vm_readv(22286, 0x7fff71fafce0, 1, 0x7fff71fafcf0, 1, 0) = -1 EPERM (Operation not permitted)
{...})       = 0

The output of the two strace processes are mixed but here we can also see that the system call process_vm_readv() returns the error condition EPERM. Consulting the process_vm_readv(2) manual page:

EPERM  The caller does not have permission to access the address space of the process pid.

Now, why on earth is ptrace() is permitted but process_vm_readv() is not? It is clear that they are two different APIs. It is time to dig into the kernel source. Having walked through the kernel code on lxr for a while, I figured this sydbox-1 PANIC was due to the fact that I have the sysctl kernel.yama.ptrace_scope set to 1 which is YAMA restricting ptrace(). After:

alip@hayalet ~/src/sydbox/sydbox-1/src (git)-[master] % sudo sysctl kernel.yama.ptrace_scope=0
kernel.yama.ptrace_scope = 0

Everything works OK and now I am aware of the fact that there is another way to restrict ptrace() and I will work on sydbox-1 to make it handle such errors gracefully (without hanging) but that’s for another night.

Confession: I started working at Özgür Yazılım A.Ş. as a Linux system administrator and programmer and I have been using Arch Linux for a while which means I have not been configuring/compiling my own kernel. This was a nice message to me that I should stop being a slacker and return to Exherbo now.

The Exherbo bug 369 is still not fixed, but I am working on it :-)

September 24, 2013 07:00 AM

September 21, 2013

Ali Polatel

Killing tracees on exit with sydbox-1

As I’ve written in my blog post Recent Linux changes to help sandboxing Linux has a few new features which may aid in enhancing sydbox-1.

One of these features is PTRACE_O_EXITKILL. This is a new ptrace option to kill tracees upon tracer exit. Quoting from ptrace(2)

    PTRACE_O_EXITKILL (since Linux 3.8)
        If a tracer sets this flag, a SIGKILL signal will be sent to every
        tracee if the tracer exits.  This option is useful for ptrace
        jailers  that want to ensure that tracees can never escape the
        tracer's control.

This is a simple feature providing a nice enhancement. sydbox-1 had a similar feature to prevent tracees from running upon an abnormal exit. There are two options, namely core/abort/decision and core/panic/decision, which when given the value killall sends SIGKILL to all traced processes upon abnormal exit. There is also the option core/trace/exit_wait_all to make sydbox-1 wait for all tracees to exit before exiting.

However, doing this in user-space is tricky and error-prone. Considering it’s the tracer who is dying unexpectedly, it may not always be possible to kill tracees which will then run in potentially unsafe mode. You can read this lkml thread and many more to dive into the internals of ptrace(2).

Thus, sydbox-1 learned a new magic command with the name core/trace/exit_kill to turn this functionality on with the two commits I pushed to master today:

One restriction is the option core/trace/exit_kill is only useful when it is set upon startup. It does not work with the magic stat() system call. ptrace(2) options are inherited from parent to children thus trying to set this on a per-tracee basis requires one to change the value of the option for the parent and all its children. Although this is possible in theory (sydbox-1 keeps track of parent<->children relationships) it would add some complexity to the program which I do not want unless I see a well-founded reason to do so.

September 21, 2013 07:00 AM

September 14, 2013

Alexander Færøy

Enhancing SSL Security for IRC: DANE Support

A couple of weeks ago, I had a discussion with some of the Quakenet coders on how to add SSL support to their IRC daemon, but the discussion ended up being about the false sense of security that SSL potentially can give to the user. The Quakenet hackers have an interesting article online about their thoughts on the matter and while I do understand their points, I do not agree with it being a good enough reason to completely avoid SSL on your IRC network.

We quickly changed the discussion to be about how the IRC clients should be able to verify that the SSL certificate, received from the server, is not a malicious certificate from someone doing MITM attacks. This was not the discussion I had hoped for, but nevertheless, it was an interesting discussion to participate in and made me spend a few days thinking about their concerns.

Sadly, as it is today, some IRC clients, including Irssi, only do full SSL certificate validation as an opt-in option (via the -ssl_verify option for /connect in Irssi’s case) rather than having it as an opt-out option, which would be ideal. This is simply because people in the IRC community have historically not wanted to spend money on certificates from the so called “trusted” Certificate Authorities like we have seen on the web. Changing this from opt-in to opt-out is something that I would like to see happen, but it is not something that is going to be easy. We saw how many web sites got a “proper” certificate after the Mozilla guys made it slightly harder to actually mark a self-signed certificate as trusted. This was at first a very annoying move, but these days we rarely see self signed certificates when we browse around the web.

A few days after the discussion on IRC, I was having dinner at Thomas’s place and I mentioned the discussion with the Quakenet hackers. Thomas knows a lot about security, privacy and DNS, and he is an avid Quakenet user, so it appeared more than obvious to take the discussion with him and hear what his take to the problem was. His suggestion was to take a look at DNSSEC and DANE and see if that could be used as a possible solution.

Luckily for me, it was exactly what I was looking for.

A few days after the dinner conversation, I pushed a patch to Irssi’s source code repository that enabled support for DANE validation of SSL certificates.

Let’s have a look at how DANE works. This will hopefully give you enough knowledge to understand the basics of what is going on. I will document how to compile Irssi with DANE support enabled and test whether it works or not.

What is DANE?

DANE is an acronym for “DNS-Based Authentication of Named Entities” and comes with a protocol named TLSA. DANE is an internet standard and you can read the full technical specification of DANE in RFC6698, but hopefully, this article will give you an introduction to get started using DANE for your IRC servers right away. The concepts are totally protocol agnostic so this will work for other protocols than IRC as well, but it does require modification to the client software to work.

DANE is a simple way of storing information about a certificate in the DNS system. Adding DNSSEC on top of the cake, gives you a very powerful way of validating certificates where the client relies on a trusted source (their ISP’s DNS server and DNSSEC) validating the information from the possibly eavesdropped IRC server.

DANE is implemented as a new DNS resource record named TLSA. You can see an example of such record here from our test IRC server linked to the IRCsource IRC network:

$ dig TLSA _6697._tcp.ircsource.baconsvin.org

; <<>> DiG 9.8.3-P1 <<>> TLSA _6697._tcp.ircsource.baconsvin.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38406
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 9

;; QUESTION SECTION:
;_6697._tcp.ircsource.baconsvin.org. IN TLSA

;; ANSWER SECTION:
_6697._tcp.ircsource.baconsvin.org. 3358 IN TLSA 3 0 1 9B954A014881108A9058DB80020909FFD8B4C44C6F41C8796B3A1EA4 3A444B94

;; AUTHORITY SECTION:
baconsvin.org.      50607   IN  NS  ns1.gratisdns.dk.
baconsvin.org.      50607   IN  NS  ns5.gratisdns.dk.
baconsvin.org.      50607   IN  NS  ns3.gratisdns.dk.
baconsvin.org.      50607   IN  NS  ns2.gratisdns.dk.
baconsvin.org.      50607   IN  NS  ns4.gratisdns.dk.

;; ADDITIONAL SECTION:
ns1.gratisdns.dk.   7417    IN  A       109.238.48.13
ns1.gratisdns.dk.   36319   IN  AAAA    2a02:9d0:3002:1::2
ns2.gratisdns.dk.   25447   IN  A       185.10.10.53
ns3.gratisdns.dk.   31182   IN  A       194.0.2.6
ns3.gratisdns.dk.   28269   IN  AAAA    2001:678:5::6
ns4.gratisdns.dk.   31182   IN  A       87.73.3.3
ns4.gratisdns.dk.   28269   IN  AAAA    2a01:558:4000::3
ns5.gratisdns.dk.   25447   IN  A       85.17.221.46
ns5.gratisdns.dk.   28269   IN  AAAA    2001:6f8:3ad::1

;; Query time: 55 msec
;; SERVER: 89.233.43.71#53(89.233.43.71)
;; WHEN: Sat Aug 10 13:16:23 2013
;; MSG SIZE  rcvd: 393

Note: If your version of dig doesn’t recognize the TLSA type, you can easily replace it with TYPE52 like this: dig _6697._tcp.ircsource.baconsvin.org TYPE52.

Notice how the port, 6697, and protocol, TCP, is part of the DNS query. This will be familiar for people who have worked with SRV DNS records.

The interesting part of the output is the answer section where you see the following:

3 0 1 9B954A014881108A9058DB80020909FFD8B4C44C6F41C8796B3A1EA4 3A444B94

What does all of this mean?

Let’s start out by looking at the format. The format for a TLSA reply is as following:

<certificate usage> <selector> <matching type> <certificate association data>

This means that our certificate usage field is 3, our selector is 0 and our matching type is 1. The associated data is the string "9B954A014881108A9058DB80020909FFD8B4C44C6F41C8796B3A1EA4 3A444B94".

It is important to understand the semantics of these fields, because they will dictate how and if the client is going to do further validation of the certificate once the client has received it from the IRC daemon.

Using 3 0 1 means that we are using a self-signed certificate and we will rely on DANE for validating the certificate only (3); that we are using the full certificate and not just the SubjectPublicKeyInfo part (0) and we will be using a hexadecimal encoded SHA256 hash of the DER-encoded certificate (1).

To fully understand the various options available, I suggest you take a look at RFC 6698 section 2.1.

Enable DANE Support for your IRC Server

The first step you will have to take is to ensure that whoever runs your DNS servers supports both DNSSEC and TLSA records. In Denmark, a lot of users are using the free DNS hosting provider GratisDNS. GratisDNS supports both DNSSEC and TLSA records which makes setting this up a lot easier.

Sadly, GratisDNS’ interface is currently only available in Danish, so you might have to look for other solutions available online.

Once you have a DNS provider that supports DNSSEC and TLSA records, it is fairly easy to create the records. In our example, the following assumptions are made:

  1. You already have an IRC daemon running with SSL enabled on port 6697 and you have verified that it actually works as expected.

  2. Your certificate is self-signed, so you would like to rely on DANE support only for the validation. This means that the user will not see any self-signed certificate errors when connecting with certificate validation enabled.

  3. We will create a record using a SHA-256 hash of the certificate data. Feel free to use something stronger, if you are more crypto paranoid than I am.

This means that our TLSA record will end up looking something similar to this:

_6697._tcp.irc.example.org TLSA 3 0 1 <SHA-256 hash of the certificate data>

This is basically going to be a description of the exact same setup that I am using for ircsource.baconsvin.org.

To find the SHA-256 value of your certificate, start by logging onto the server running the IRC daemon and find the directory that contains your certificate files. We are then going to find the SHA-256 value of the DER representation of our certificate:

$ openssl x509 -in ircsource.baconsvin.org.pem -outform DER | sha256sum
9b954a014881108a9058db80020909ffd8b4c44c6f41c8796b3a1ea43a444b94  -

This is the value we will be using in our final TLSA record, which now looks like the following:

_6697._tcp.irc.example.net TLSA 3 0 1 9b954a014881108a9058db80020909ffd8b4c44c6f41c8796b3a1ea43a444b94

Once you have added this record to your DNS zones, it is now time to actually test whether it works as expected.

Building Irssi with DANE Support

This part is tested on FreeBSD 9.2-PRERELEASE. Hopefully, it works for other people as well. Feel free to report any issues you may experience.

  1. Download the dnsval tarball from its download page. This is quite new software so I haven’t run into many distributions that have packages available, so we will assume that we have to compile it ourselves.

    $ mkdir dane
    $ cd dane
    $ fetch http://www.dnssec-tools.org/download/dnsval-2.0.tar.gz
    $ tar zxfv dnsval-2.0.tar.gz
    $ cd dnsval-2.0
    $ ./configure --prefix=/usr/local
    $ make
    $ sudo make install
  2. Next we will download the Irssi source code from the Git repository. We start by cloning the repository into our newly created dane directory:

    $ cd dane
    $ git clone git://git.irssi.org/irssi
    $ cd irssi
  3. We bootstrap the build system:

    $ sh autogen.sh
  4. We configure our test Irssi client:

    $ CFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" ./configure --enable-dane --with-perl=no

    Make sure that somewhere near the end of the output of the configure script contains:

    Building with DANE support ....... : yes

    Otherwise you should take a look at the config.log file and look for places where libval is mentioned and figure out why it doesn’t find the library correctly.

  5. Compile Irssi:

    $ make
  6. Fire up your new Irssi client and give it a spin:

    $ ./src/fe-text/irssi -!
  7. Try to connect to our test server, ircsource.baconsvin.org, using DANE:

    /connect -ssl -ssl_verify ircsource.baconsvin.org 6697

    If everything was done correctly, Irssi will now connect to the server, verify the signature of the certificate using TLSA and allow you to connect without seeing any self-signed certificate errors.

DANE Enabled IRC Servers

Here’s a list of IRC servers that supports DANE. If you are running a public IRC server and would like to see the server added here, feel free to drop me an email at ahf@irc6.net with information about the server.

IRCsource

IRCsource is a small network where people with a general interest in IRC hang out together to discuss and test various new concepts and ideas for IRC.

  • ircsource.baconsvin.org (SSL ports: 6697 and 9999)

I will do my best to maintain this list of servers supporting DANE in the future.

Next Stop?

The next step for me is to start securing server-to-server links within the IRC networks with DANE. This will require some modifications to the IRC daemons themselves. I plan on looking into adding support for DANE in a personal feature branch of ircd-ratbox and some of its derivatives.

Conclusion

I am unable to say if DANE support is what the IRC community will be adopting. The IRC community is very conservative in general so time will have to tell.

If you believe you have found a bug in my code or have any troubles setting DANE up for your own IRC server, I will be more than happy to help. Drop me an email and I will take a look at it whenever I have time. Otherwise, feel free to poke me on IRC. My nickname is ahf and I am available on most of the “larger” IRC networks (EFnet, Freenode, IRCnet and Quakenet).

All of this code will be available in the upcoming Irssi 0.8.16 release, but if you want to test it right away, my suggestion is to follow my guide from above and use Irssi directly from Git.

Hopefully, we will see other IRC client and server hackers implementing DANE support in the nearby future. If you like what you have read here, please help me making this happen by spreading the word about the possibilities available for enhancing the SSL support in IRC clients as well as other SSL based online services.

This is too easily implementable to be ignored.

Credits

I would like to thank Thomas Steen Ramussen for being the originator of the idea and setting up the initial DNS server for testing purpose; Peter Larsen for expeditiously implementing TLSA support for GratisDNS; the IRC6.net guys for late night discussions about DANE; Mickey Fischer for testing the Irssi patches on Gentoo Linux with various options enabled and disabled; the DNSSEC-Tools Project for creating the libraries used and finally the rest of the Irssi team for reviewing the patches and coming with recommendations for my code.

September 14, 2013 07:00 AM

September 13, 2013

Wulf C. Krueger

You all suck at working on patches, my fellow Exherbo devs!

I originally posted this in 2011. Unfortunately, hardly any significantly changed since then. I decided to add !pd statistics this time, though:

Philantrop: 557
sepek: 271
ar: 207
keruspe: 180
SardemFF7: 105
zlin: 98
compnerd: 94
sepek_: 88
SuperHeron: 67
heirecka: 53
moben: 43
mrothe: 37
woutershep: 33
pipping: 33
Bruners: 33
virkony: 30
arnej: 27
nicoo: 24
tgurr: 22
freeedrich|: 22

 

 

What really annoys me lately is the unwillingness of my fellow Exherbo core developers to act on user-contributed patches. While it’s certainly true that some patches need extensive testing and, thus, require a lot of time, there are usually a lot of trivial patches or patches that can be tested with moderate effort.

Let’s look at an example:

From 2a11f609e8be4f61a545112f1fceda6f8c40bfeb Mon Sep 17 00:00:00 2001

From: Johannes Nixdorf <mixi@user-helfen-usern.de>

Date: Thu, 24 Mar 2011 16:26:59 +0100

Subject: [PATCH] revive agg in ::mixi

drizzt.graveyard | 7 ——-

1 files changed, 0 insertions(+), 7 deletions(-)

diff –git a/drizzt.graveyard b/drizzt.graveyard

index 98979b9..92ed79a 100644

— a/drizzt.graveyard

+++ b/drizzt.graveyard

@@ -287,10 +287,3 @@ www-servers/

homepage = http://nginx.net

removed-by = Wulf C. Krueger <philantrop@exherbo.org>

removed-from = drizzt

-x11-libs/

- agg/

- :0 2.5

- description = A High Quality Rendering Engine for C++

- homepage = http://antigrain.com/

- removed-by = Wulf C. Krueger <philantrop@exherbo.org>

- removed-from = drizzt

1.7.4.1

This patch was for ::graveyard. It simply removes a single entry for a package that found a new home since I removed it. Great!

Anyone with push access could have verified and pushed it with minimal effort and, yet, nobody did for about two days and I’m pretty sure it would still be rotting on zebrapig if I hadn’t done so today.

Unfortunately, it’s by far not the only example. At the time of writing, zebrapig keeps 16 patches. A week ago, it were over 30. Nobody gave a shit.

There are patches that have been on zebrapig for months now (Ruby comes to mind!) and help with them is rejected because some people have worked on them and instead of submitting improved patches, they keep them to themselves, effectively stopping anyone from doing anything. And hardly anyone gives a shit.

Now, why is that situation so bad:

  1. Patches are submitted to improve Exherbo. You’re impeding improvement by ignoring them.
  2. Patches are submitted by our contributors/non-core developers. If you ignore their patches, they will become frustrated and stop submitting patches but create their own repositories, duplicating our work and making things harder for all of us. Or they will just go away. The latter is the worst possible outcome for Exherbo as a whole because with hardly more than a handful of active core developers, we will fail if we drive contributors away.
  3. You’re putting more workload on the even fewer people with push access that actually work on patches. This takes away from our time working on more interesting stuff and, at least in my case, really alienates people from Exherbo.

Effectively, I’m handling most of the contributed patches myself. Either by reviewing, discussing and pushing them myself or by asking people to work on them (and usually getting stupid answers…).

Another thing that annoys me greatly are the answers I’m getting from people I’m asking to review patches; here are some examples (in no particular order) and what I think about them (which is usually not what I say):

  • “I prefer playing SC2.” / “I’m watching Star Trek!” – Well, yes, fine but I’m sure you could really dedicate at least one or two hours per week to work on patches.
  • “Exherbo is just something nice to play with. I don’t really want to really work on it or be professional about it.” – (I really hate that one.) If you take up responsibility for something, even as a hobby or so, then live up to it or leave it be. Get used to behaving professionally now while you can afford it not to be. Once you get a job, people won’t be so forgiving.
  • “I don’t really care about that package anymore.” – Well, I don’t either but there’s a patch so other people obviously do care. If you really want to get rid of a package, mail the exherbo-dev mailinglist and tell people. If there’s no taker, use Dexter to bury the package if need be.
  • “I prefer vodka over patches.” – …
  • “I’m working! Not a student anymore.” / “I’m so tired!” – So am I. And I’m married, have three kids and two rabbits. I’m working hard myself so you have my sympathy but, really, are one or two hours per week too much to ask? I usually invest much more time myself.
  • “I’ve been busy slacking for a year!” (or longer) – Then please make it official and resign as a core developer. At least I’m going to know whom not to ask and it’ll become more obvious we’re under-staffed.
  • “I said I’d do it but now I can’t be arsed.” – Great, you could at least have told me right from the start you’re not going to do anything. I could have acted accordingly then.

And sometimes, the very same people who just refused to even look at a patch will ask me to review their patches seconds later…

All of this is really annoying and it’s the most likely reason for me to quit working on Exherbo and switching all my machines to another Linux distribution at some point if we don’t find a solution.

by Wulf Krueger at September 13, 2013 05:14 PM

September 02, 2013

Ciaran McCreesh

Paludis 1.4.1 Released

Paludis 1.4.1 has been released:

  • Compatibility with newer Boost.
  • Minor bug fixes and UI tweaks.

Filed under: paludis releases Tagged: paludis

by Ciaran McCreesh at September 02, 2013 01:00 PM

June 27, 2013

Ali Polatel

Sandboxing Skype with sydbox-1

There are various tools to provide enhanced restriction mechanisms under Linux. In case security is the major concern, these mechanisms need to be in the kernel level which in turn means specific configurations or in some cases modifications (in forms of patches etc.) to the Linux kernel. Some examples are AppArmor, Security Enhanced Linux, Tomoyo Linux, and Grsecurity. User space solutions are either not as flexible or not as secure depending on the use case scenario.

We, at Exherbo, need a sandbox for misbehaving package builds. One should note that such misbehaviours can sometimes be rather fun (or not safe for work at times). I used the term misbehaving on purpose because this does not mean the sandbox itself can make the build environment totally secure. Linux has good old UNIX goodies like separate permissions for users, chroots and new shiny stuff like per-process namespaces to implement further restrictions.

Exherbo’s practical solution to this issue is sydbox. With the upcoming version sydbox-1 - which is yet to be released - this solution can easily be adapted to different use cases.

As I was browsing through Arch Linux Wiki pages I stumbled upon the Skype page which describes different approaches to restrict such close sourced applications.

I am not claiming using sydbox-1 for this purpose is secure but it is most certainly practical. Here is my proof-of-concept attempt at sandboxing Skype using sydbox-1. Below is a sample sydbox-1 profile for use with Skype. You can also find it in sydbox-1.git under examples/ directory.

    # sydbox profile for Skype4

    #
    # Sandboxing
    #
    core/sandbox/exec:deny
    core/sandbox/read:deny
    core/sandbox/write:deny
    core/sandbox/network:deny

    core/whitelist/per_process_directories:true
    core/whitelist/successful_bind:true
    core/whitelist/unsupported_socket_families:true

    core/abort/decision:killall
    core/panic/decision:kill
    core/panic/exit_code:-1
    core/violation/decision:deny
    core/violation/exit_code:-1
    core/violation/raise_fail:false
    core/violation/raise_safe:false

    core/trace/follow_fork:true
    core/trace/exit_wait_all:true
    core/trace/magic_lock:off
    core/trace/interrupt:while_wait
    core/trace/use_seccomp:true
    core/trace/use_seize:true
    core/trace/use_toolong_hack:true

    core/match/case_sensitive:true
    core/match/no_wildcard:literal

    #
    # Logging
    #
    log/file:
    log/level:511
    log/console_fd:2
    log/console_level:3

    #
    # /dev
    #
    whitelist/read+/dev
    whitelist/read+/dev/urandom
    whitelist/read+/dev/stdout
    whitelist/read+/dev/stderr
    whitelist/write+/dev/tty*
    whitelist/write+/dev/pts/***
    whitelist/read+/dev/snd/***
    whitelist/write+/dev/snd/***
    whitelist/read+/dev/video*
    whitelist/write+/dev/video*

    #
    # /proc & /sys
    #
    whitelist/read+/proc/cpuinfo
    whitelist/read+/proc/meminfo
    whitelist/read+/proc/stat
    whitelist/read+/proc/net
    whitelist/read+/proc/net/arp
    whitelist/read+/proc/net/route
    whitelist/read+/proc/net/unix
    whitelist/read+/proc/sys/vm/overcommit_memory
    whitelist/read+/proc/sys/kernel/osrelease
    whitelist/read+/proc/sys/kernel/ostype
    whitelist/read+/sys/devices/system/cpu/online
    whitelist/read+/sys/devices/system/cpu
    whitelist/read+/sys/devices/system/cpu/cpu?/cpufreq/scaling_cur_freq
    whitelist/read+/sys/devices/system/cpu/cpu?/cpufreq/scaling_max_freq
    whitelist/read+/sys/devices/virtual/dmi/id/board_name
    whitelist/read+/sys/devices/virtual/dmi/id/board_version
    whitelist/read+/sys/devices/virtual/dmi/id/board_vendor
    whitelist/read+/sys/devices/virtual/dmi/id/product_name
    whitelist/read+/sys/devices/virtual/dmi/id/product_version
    whitelist/read+/sys/devices/virtual/dmi/id/sys_vendor
    whitelist/read+/sys/devices/*/*/*/power_supply/ACAD/***
    whitelist/read+/sys/devices/*/*/*/*/*/*/modalias
    whitelist/read+/sys/devices/*/*/*/*/*/*/video4linux/video?/dev
    whitelist/read+/sys/devices/*/*/*/*/*/idProduct
    whitelist/read+/sys/devices/*/*/*/*/*/idVendor
    whitelist/read+/sys/devices/*/*/*/*/*/speed

    #
    # nscd (glibc)
    #
    whitelist/network/connect+unix:/var/run/nscd/socket
    whitelist/network/connect+unix:/run/nscd/socket

    #
    # /etc
    #
    whitelist/read+/etc/asound.conf
    whitelist/read+/etc/group
    whitelist/read+/etc/hosts
    whitelist/read+/etc/host.conf
    whitelist/read+/etc/ld.so.cache
    whitelist/read+/etc/ld.so.preload
    whitelist/read+/etc/nsswitch.conf
    whitelist/read+/etc/resolv.conf
    whitelist/read+/etc/ssl/certs/***
    whitelist/read+/etc/fonts/***
    whitelist/read+/etc/gtk-2.0/***
    whitelist/read+/etc/pango/***

    #
    # Libraries
    #
    whitelist/read+/lib*/***
    whitelist/read+/usr/lib*/***

    #
    # Share dirs
    #
    whitelist/read+/usr/share/alsa/***
    whitelist/read+/usr/share/ca-certificates/***
    whitelist/read+/usr/share/locale/***
    whitelist/read+/usr/share/zoneinfo/***
    whitelist/read+/usr/share/fonts/***
    whitelist/read+/usr/share/icons/***
    whitelist/read+/usr/share/pixmaps/***
    whitelist/read+/usr/share/texmf-dist/fonts/***
    whitelist/read+/usr/share/X11/***

    #
    # Xorg/X11 & dbus
    #
    whitelist/network/connect+unix-abstract:/tmp/.X11-unix/**
    whitelist/network/connect+unix-abstract:/tmp/.ICE-unix/**
    whitelist/network/connect+unix-abstract:/tmp/dbus-*
    whitelist/network/connect+unix:/run/dbus/system_bus_socket
    whitelist/network/connect+unix:/var/run/dbus/system_bus_socket

    #
    # /tmp
    #
    whitelist/read+/tmp/qtsingleapp-*
    whitelist/write+/tmp/qtsingleapp-*
    whitelist/network/bind+unix:/tmp/qtsingleapp-*
    whitelist/network/connect+unix:/tmp/qtsingleapp-*

    #
    # Skype
    #
    whitelist/read+/etc/Skype.conf
    whitelist/read+/etc/Skype/***
    whitelist/read+/usr/*bin/skype
    whitelist/exec+/usr/*bin/skype
    whitelist/exec+/usr/lib*/skype/skype
    whitelist/exec+/opt/skype/skype
    whitelist/read+/opt/skype/***
    whitelist/read+/usr/share/skype/***

    #
    # Host specific configuration under /home
    #
    whitelist/read+/home/*/.Xauthority
    whitelist/read+/home/*/.ICEauthority
    whitelist/read+/home/*/.gtkrc*
    whitelist/read+/home/*/.config/Trolltech.conf
    whitelist/write+/home/*/.icons/***

    #
    # Skype specific configuration
    #
    whitelist/read+/home/*/.asoundrc
    whitelist/read+/home/*/.config/Skype/***
    whitelist/write+/home/*/.config/Skype/***
    whitelist/read+/home/*/.Skype/***
    whitelist/write+/home/*/.Skype/***

    #
    # Temporary files & caches
    #
    whitelist/read+/home/*/.cache/fontconfig/***
    whitelist/write+/home/*/.cache/fontconfig/***
    whitelist/read+/home/*/.compose-cache/***
    whitelist/write+/home/*/.compose-cache/***

    #
    # Networking
    #
    # note: allow IPv4 and IPv6 by default since Skype operates on a P2P model.
    #       You may further restrict access by only allowing access to SKYPENET,
    #       Akamai and Microsoft Corporation together with your contact's IP
    #       address.
    #
    whitelist/network/bind+LOOPBACK@0
    whitelist/network/connect+inet:0.0.0.0/0@0-65000
    whitelist/network/connect+inet6:::0/0@0-65000

    #
    # Allow some external programs
    #
    whitelist/exec+/usr/*bin/xdg-open
    exec/resume_if_match+/usr/*bin/xdg-open

A couple of things to note:

  1. sydbox-1 is still in heavy development and the file format may change.
  2. This approach is not secure. Author claims no responsibility if Skype kills your goats.
  3. Three is the loneliest number since number two which is the loneliest number since the number one.

Happy hacking!

June 27, 2013 07:00 AM

June 13, 2013

Ali Polatel

I Can Not Tell

As the Garip poet Orhan Veli once wrote,

Can you hear me if I cry,
In my verses;
Can you touch,
My tears, with your hands?

I hadn't known how songs were so lovely,
And yet the words so inadequate
Before I had fallen into this suffering.

I know there is somewhere
To say anything about which is possible;
I am very close, I can hear;
I can not tell...

in his poem Anlatamıyorum (I Can Not Tell, translated by myself on 2013-06-13). Sometimes a photo may describe what we can’t describe with a thousand words.

You know your government has failed, when your grandma starts to riot!

Long story short, you know your government has failed, when your grandma starts to riot

Occupy Gezi! Diren Gezi!

Update

  • 2013-06-14: Translation of the first quatrain was slightly modified.
  • 2013-06-16: More translation fixes.

June 13, 2013 07:00 AM

May 16, 2013

Ciaran McCreesh

Paludis 1.4.0 Released

Paludis 1.4.0 has been released:

  • Tweaked ‘cave resolve’ output to add blank lines.
  • Support for libarchive 3.1.2.
  • Compatibility fixes for GCC 4.8.

Filed under: paludis releases Tagged: paludis

by Ciaran McCreesh at May 16, 2013 01:29 PM

April 02, 2013

Ali Polatel

Tragedy of a Trachian Soldier

Here is a brief attempt to translate the nervous breakdown of a Trachian soldier after 6 hours of sentry-duty… As a show of respect to the soldier, the f-word has been substituted with the word love on all occurences.

That’s it, love it! That’s it, love it!
I’ve had enough of this duty!
I’ve been here for 6 hours, love it!
Love who put me here, love who made him put me here! Love ‘em all!
Lovers trusting me to secure this huge company!
What is this? That tears it! Love it!
What is this? Love it!
What is this? Am I an animal? Love it!
Are my parents cows?!!
No more of this loving duty!
No more I am no part of it! Love it!
Cameraman: Yeah, lie down, chill!
What is this? Who the love does he think he is? Love him too!
Cameraman: Enough already!

April 02, 2013 07:00 AM

March 25, 2013

Ciaran McCreesh

Paludis 1.2.0 Released

Paludis 1.2.0 has been released:

  • Bug fixes.
  • Dep specs can now use ‘[.key!=value]‘. The behaviour of ‘<’ and ‘>’ has changed: for key types where order comparisons don’t make sense, the match now always fails.
  • Various compiler-compatibility fixes.

Filed under: paludis releases Tagged: paludis

by Ciaran McCreesh at March 25, 2013 06:51 PM

March 08, 2013

Wulf C. Krueger

HowTo: systemd on Exherbo

This comes up all too often, so here’s a HowTo for systemd on Exherbo:

  • You have to run a Linux kernel >=2.6.39. The new kernel is only needed at runtime, not for building systemd.
  • You should run a Linux kernel >=3.8. The new kernel is only needed at runtime, not for building systemd.
  • Kernel options for systemd: cf. systemd’s README, here’s an excerpt:

CONFIG_DEVTMPFS
CONFIG_CGROUPS (it’s OK to disable all controllers)
CONFIG_INOTIFY_USER
CONFIG_SIGNALFD
CONFIG_TIMERFD
CONFIG_EPOLL
CONFIG_NET
CONFIG_SYSFS

Linux kernel >= 3.8 for Smack support

Udev will fail to work with the legacy layout:
CONFIG_SYSFS_DEPRECATED=n

Legacy hotplug slows down the system and confuses udev:
CONFIG_UEVENT_HELPER_PATH=”"

Userspace firmware loading is deprecated, will go away, and
sometimes causes problems:
CONFIG_FW_LOADER_USER_HELPER=n

Some udev rules and virtualization detection relies on it:
CONFIG_DMIID

Mount and bind mount handling might require it:
CONFIG_FHANDLE

Optional but strongly recommended:
CONFIG_IPV6
CONFIG_AUTOFS4_FS
CONFIG_TMPFS_POSIX_ACL
CONFIG_TMPFS_XATTR
CONFIG_SECCOMP

For systemd-bootchart a kernel with procfs support and several
proc output options enabled is required:
CONFIG_PROC_FS
CONFIG_SCHEDSTATS
CONFIG_SCHED_DEBUG

For UEFI systems:

CONFIG_EFI_VARS
CONFIG_EFI_PARTITION

Furthermore:
CONFIG_FANOTIFY=y (only used for readahead stuff which is not enabled by default.)

CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y (only used for readahead stuff which is not enabled by default.)

 

  • Set the “systemd” option globally in /etc/paludis/options.conf: */* systemd
  • Install systemd: cave resolve -x sys-apps/systemd (Read what cave tells you. If in doubt, read Paludis’ documentation.)
  • Reinstall every package with the new option set: cave resolve world -cx
  • Switch to systemd as your init system: eclectic init set systemd
  • Set the desired hostname in /etc/hostname.
  • Optional: Edit /etc/vconsole.conf to your liking. (If you delete it, empty it or comment out everything, systemd will use the kernel’s defaults.)
  • Optional: Edit /etc/machine-info to your liking.
  • Read Lennart’s blog post about the other configuration files.
  • Install a Linux kernel >=2.6.39. (see above for kernel options, etc.)
  • Reboot.

After that reboot, you’ll be in a console with a minimal set of services started, hopefully ready to log in. Log in as root (the keyboard layout is set to US in vconsole.conf (see above) by default!). Then you can enable whatever services (found in /lib/systemd/system) you like, suggested ones are:

  • dhcpcd.service or NetworkManager.service
  • sshd.socket (it doesn’t start? Missing host keys? man sshd or http://tinyurl.com/24jwxjd)

As an extremely simple and limited alternative to NetworkManager.service, there’s network.service and network.conf which get installed if you set the “simple-net” option for systemd. network.service only allows for static network setups with IPv4.

Alternatively, you can use dhcpcd.service.

If I were you, I’d not enable your display manager’s service (either kdm.service, gdm.service, xdm.service or slim.service) until your basic system has at least booted properly once and you can reach your system using ssh because in case things go wrong, it’s easier not to have to wrestle with a GUI.

To actually enable a service, run “systemctl enable <foo.service>”. More details can be found in systemd’s man page.

If you need help, it’s available in #exherbo, as usual, but if you didn’t read this before asking, grumpy me will bite your head off unless you prove you read this by saying “I have furuncles on my arse.”. Yes, I’m being serious.

 

FAQ section:

  • “How/where do you specify extra modules to be loaded?” – You put the module name into /etc/modules-load.d/foo.conf and it will get loaded. Unless systemd-udev has already loaded it for you. Check that first.
  • “My hostname is set to something funny, e. g. ’08′!” – If you’re using NetworkManager, you need to set your hostname in /etc/NetworkManager/NetworkManager.conf, too.
  • “I’m getting messages about failing services, e. g. dev-hugepages.mount or sys-kernel-debug.automount. What’s up with that?” – You can either enable the corresponding kernel options, delete the symlink (e. g. /lib/systemd/system/basic.target.wants/sys-kernel-debug.automount) or just ignore those messages. They’re harmless.
  • “When sshd.socket is enabled, every closed ssh connection leaves a failed service around, e. g. sshd@192…:55140.service.” – Harmless as well. There are no ressources used by those so ignore them. (This should be fixed anyway.)
  • “Where can I learn more about the usual administration tasks? – Read Lennart’s series of blog posts about systemd for administrators: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, Part 8
  • “How do I debug problems with systemd?” – Read this page http://fedoraproject.org/wiki/How_to_debug_Systemd_problems
  • “I’m completely lost. What do I do?” – Please remember there’s always a friend around. It’s called “man”. ;-)

by Wulf Krueger at March 08, 2013 04:06 PM

March 04, 2013

Bryan Østergaard

Looking for a few more volunteers

It's that time of the year.. Only four days left before the big danish Open Source Days conference starts and we're tying up all the loose ends as quickly as possible.

Things are looking great from my point of view but one of the things we need to sort out before the conference opens is all the different helper roles. And we're still looking for good wanting to be an active part of Open Source Days and get to know all the other great people involved.

If you would like to take part in this you can sign up at Join Us and in return for helping out you get free entrance to the conference including the social event saturday night.

March 04, 2013 11:09 PM

March 03, 2013

Wulf C. Krueger

Multilib migration after The Great Merge (optional)

Disclaimer: The entire migration procedure as described below is completely optional. If you don’t need or want multilib/multibuild/multiple C targets support, you can ignore this email.
We won’t force anyone to use it. I’m only going to use it on my desktop myself. :-)

 

We’ve now merged all multilib branches into master (this will go down into history books as “The Great Merge”!).

Thus, we don’t have any separate branches in our official and dev repositories anymore and if you still have a multilib branch  in your repository, please merge it, too.

Now is a good time to write an updated multilib migration guide so, without further ado, here we go:

  • Switch to the multibuild profile in arbor.conf (${location}/profiles/amd64/multilib)
  • Ensure that CHOST is not set in bashrc, and note that CFLAGS will apply to all C targets. You can use MULTIBUILD_C_{32,64}_USER_C{,XX}FLAGS for individual C targets.
  • Re-install/update sys-apps/skeleton-filesystem-layout
  • Install sys-libs/glibc[bootstrap], note that this should pull in sys-devel/bootstrap-gcc, too. (This is going to take a long time.)
  • Install sys-devel/gcc[-openmp] (This is potentially going to take a long time, especially if you have the java option set.)
  • Use eclectic gcc to switch to the freshly compiled multilib gcc
  • Install sys-libs/glibc[-bootstrap], you can let Paludis purge sys-devel/bootstrap-gcc while doing so.
  • Adjust your options to include the C targets you want and re-install any packages accordingly. You might have to re-install lots of package dependencies to fulfill a newly selected target’s requirements. (I simply did a cave resolve -e world)

Best regards, Wulf

by Wulf Krueger at March 03, 2013 02:08 PM

February 22, 2013

Ali Polatel

Recent Linux changes to help sandboxing

Linux kernel 3.8 has been released this week which reminded me to write about recent Linux kernel changes which may help in improving sydbox. Below is a short summary of new, and not so new, features merely to get myself to stop slacking and start coding again.

Per-process namespace support

Per-process namespace support is completed with linux-3.8. This feature provides a nice way to separate resources on a per-process basis, for example a process might see a set mountpoints, PID numbers, and network stack state, and a process in other namespace might see others. For more information see the Linux-3.8 Changes page on kernelnewbies and the Namespaces in Operation articles on LWN.

PTRACE_O_EXITKILL

New in linux-3.8, this ptrace(2) option makes the tracer send SIGKILL to tracees on exit. This is useful for ptrace(2) based sandboxes for which a resumed tracee is a security risk. See the related commit for more information.

SECCOMP_MODE_FILTER

This is by far my favourite feature. Introduced with Linux kernel 3.5 and also known as seccomp mode 2 or user filters this feature lets you add basic system call filters expressed as Berkeley Packet Filter programs. Even though sydbox still has to use ptrace(2) to do more sophisticated argument checking, this feature removes the need to stop the tracee on every system call entry and exit which is a PITA especially when tracing multithreaded programs. sydbox-1 takes advantage of this feature using SECCOMP_RET_TRACE which signals the tracer with the new ptrace(2) event PTRACE_EVENT_SECCOMP.

Here are some useful links:

PTRACE_SEIZE & PTRACE_INTERRUPT

Probably even older than seccomp user filters, these ptrace requests allow the tracer to attach to tracee without trapping it or affecting its job control states. See, http://thread.gmane.org/gmane.linux.kernel/1136930 for more information.

February 22, 2013 08:00 AM

February 21, 2013

Bryan Østergaard

20.000 minutes

20.000 minutes sounds like a lot but for sufficiently large projects with sharp deadlines it really isn't.

Converted to a more manageable time scale it's roughly two weeks or roughly how much time until the Open Source Days conference opens. As some of you might know this is the second year I'm involved in organising this big open source conference.

And just like last year it's an awesome experience but also very stressful with all the small things needing to fall into place for the conference to run smoothly. And unlike last year I haven't been sick so I'm getting to enjoy the full experience :)

Having only two weeks left means really long hours every day while we scramble to close all the outstanding issues. But it also means we get to see a huge amount of things fall into place each day.

Some of the things I'm excited about today:

  • Most of the talks are now announced on the website

  • The keynote talks are all confirmed. More on that later.

  • We've added several more sponsors

The next two weeks should be very exciting and I'm sure the conference is going to be even better this year.

See you all at the conference!

February 21, 2013 11:13 PM

February 15, 2013

Ali Polatel

The Wall

As I took a sip from my tea, the room felt a bit different. Different in such a way that it enabled me to let my unconscious take over.

The wall I was leaning against seemed to change. It was turning into a door. A door made of small curved mirrors… All paintings on the wall faded away slowly. There I was, left alone with a door to enter. Was this a question of bravery? “Temptation, temptation…” So I heard the voices sing. I must admit, I felt kind of scared. Like a baby felt giving birth to her first mother. Before I could change my mind, I quickly grabbed my book and opened the door. I was expecting a divine forest, green and huge. Quite the contrary, the door led me to another room with mirrors on all of its walls, ceiling and floor. I could see the reflection of everything in the room but not myself. The door had vanished and my book looked a lot different to me. What was it that I was to do here? What exactly did I leave behind? This thought made me smile, like a mother smiled while giving birth to her own mother

Leaving my book in a corner of the room, I observed the mirrors. Why was my reflection not there? In a room like this, how could I see what differences this journey might have made in me? After a couple of minutes, I was surprised to discover that I couldn’t see the reflections of the things that “touched” me. My clothes, my shoes, my earring… All became visible as I took them off. “The book!” I said, “where is it?” turning into the corner where I left it. Its reflection was still there. Looking at me and smiling like my mother smiled, giving birth to my grandmother

Somehow, I knew the cure was in this room but where? The endlessness, which the mirrors have formed, gave me an idea. Why was I thinking that the other side of the mirror was inaccessible to me? “Temptation, temptation…” So I heard the voices sing. I must admit, I felt kind of scared. Like a warrior felt, being slain by his new-born baby… Feeling I might have found the cure, I took a step into the mirror. There I saw my “other” self sitting in that room, looking at the wall, writing a truly odd story… I can’t say he was astonished though, seeing me standing against him, naked.

February 15, 2013 08:00 AM

February 02, 2013

Ciaran McCreesh

Paludis 1.0.0 Released

Paludis 1.0.0 has been released:

  • EAPI 5 style subslot specs are allowed in user dependency specs.
  • We now support DWARF compression.

Filed under: paludis releases Tagged: paludis

by Ciaran McCreesh at February 02, 2013 03:14 PM

November 16, 2012

Ciaran McCreesh

Paludis 0.82.0 Released

Paludis 0.82.0 has been released:

  • Various EAPI 5 related fixes.

Filed under: paludis Tagged: paludis

by Ciaran McCreesh at November 16, 2012 11:46 PM

October 23, 2012

Ali Polatel

Easy on the Eyes

Writing with the intention to grow up:

Rule 1: Stay out of the magical world. This your subconscious speaking.

Rule 2: Never underestimate the power of goats.

Rule 3: Pink Floyd after midnight is easy on the eyes.

Rule ?: Numbers are bad.

Rule: Actually they have no reason whatsoever to even exist.

?: No rule, no pain.

Love: You are on the right path, Watson.

Do not define sizeof(void *). Because in what you would call a primitive world you would only need love, pure, endless love.

Ooomray!

Now look at the sky, look at the river. Isn’t it good?

If not, return to rule 3.

October 23, 2012 07:00 AM

October 19, 2012

Ciaran McCreesh

Paludis 0.80.2 Released

Paludis 0.80.2 has been released:

  • Bug fixes.
  • Added ‘cave print-unmanaged-files’.

Filed under: paludis releases Tagged: paludis

by Ciaran McCreesh at October 19, 2012 02:17 PM

October 13, 2012

Ciaran McCreesh

October 04, 2012

Wulf C. Krueger

systemd and the Linux kernel

This comes up all too often, so here’s a HowTo for systemd on Exherbo:

  • You have to run a Linux kernel >=2.6.39. The new kernel is only needed at runtime, not for building systemd.
  • You should run a Linux kernel >=3.0. The new kernel is only needed at runtime, not for building systemd.
  • Kernel options for systemd: In your kernel config, enable autofs4, devtmpfs and cgroups. Do not enable autofs3. Here’s what I’m using (I enable more kernel options than strictly necessary, though.):

CONFIG_DEVTMPFS=y (Strictly required!)

CONFIG_DEVTMPFS_MOUNT=y (unless you're using an initramfs that's mounting it for you, e. g. one created by Dracut)

# CONFIG_AUTOFS_FS is not set (Strictly required!)

CONFIG_AUTOFS4_FS=y (Strictly required!)

CONFIG_CGROUPS=y (Strictly required!)

# CONFIG_CGROUP_DEBUG is not set

CONFIG_CGROUP_NS=y

CONFIG_CGROUP_FREEZER=y

CONFIG_CGROUP_DEVICE=y

CONFIG_CGROUP_CPUACCT=y

# CONFIG_CGROUP_MEM_RES_CTLR is not set

CONFIG_CGROUP_SCHED=y

CONFIG_BLK_CGROUP=y

# CONFIG_DEBUG_BLK_CGROUP is not set

CONFIG_FANOTIFY=y (only used for readahead stuff which is not enabled by default.)

CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y (only used for readahead stuff which is not enabled by default.)

by Wulf Krueger at October 04, 2012 08:33 AM

September 29, 2012

Ali Polatel

sydbox-1 is nearly there

After nearly two years I began working on a sydbox replacement1 she is finally nearing completion. This post is meant both as a preliminary announcement and help request.

sydbox-1 has been in ::arbor for sometime as sydbox-scm2 and paludis supports it since version 0.78.1. The git repository is hosted on exherbo.org3. Before going on to tell you about her I want to kindly ask you to help me with some tasks:

  • Proof read the manual page4. I am still unsure about the configuration file format and the magic command API so now is the time to share your ideas and views to help make sydbox-1 better.

  • For brave souls, unmask it and install it. Especially important is to run its tests. To do that you have to set the environment variable PALUDIS_DO_NOTHING_SANDBOXY5. You will notice that it doesn’t depend on pinktrace anymore. This is because sydbox-1 includes a rewrite of pinktrace which will eventually be released as pinktrace-1.

  • Once again for brave souls, use it on your system. I am especially interested in how it performs during the src_test phase of exhereseses so please make sure tests are enabled if you do so and report back any issues (accompanied with a poem of your choosing!). It is always a good idea to have a pbin of the package in question to easily rollback changes in case you hit a severe bug6.

If you are bored, you can stop reading now. I will go on to introduce sydbox-1.

Why?

I am not a professional programmer. However, I have gained many experiences after writing sydbox-0 and watching it perform as the default sandbox of Exherbo. sydbox-0 has many shortcomings and drawbacks which made it rather hard to maintain. Such as:

  • sydbox-0 was based on the now unmaintained catbox initially. There are many design issues which didn’t fit with our use cases for Exherbo.
  • Being GPL-2 licensed it was problematic to share code with the well-established ptrace(2) based projects like strace and truss (of FreeBSD). I have partially solved this problem by writing pinktrace - a BSD3 licensed library providing thin wrappers around certain ptrace(2) calls but this was not enough. (See below about pinktrace-easy)
  • Being a crucial part of the system set, dependencies like GLib was obviously a bad idea.
  • Over the years as sydbox-0 codebase grew there were unforeseen code maintenance problems making it difficult to add new features.

Features of sydbox-1

Below are main features of sydbox-1. You may consult the manual page³ for more information.

  • No external dependencies. GLib dependency is gone for good among with the ini-format configuration file. sydbox-1 uses JSON format for configuration.
  • Most of the ptrace(2) work is now abstracted by a callback-driven higher-level BSD3 licensed library called pinktrace-easy. This makes both the maintenance easier and code sharing with strace less problematic.
  • Well designed, well documented magic command API which fits in with the configuration file format and provides an easier experience during command line invocation.
  • Process dump can be obtained by sending sydbox-1 the SIGUSR1 signal (or SIGUSR2 for a more verbose dump). This makes it easier to debug sydbox hangs.
  • Better signal handling to make sydbox more immune to interrupts.
  • More powerful and configurable rsync-like pattern matching.
  • Support for secure computing mode aka seccomp7. This requires Linux-3.5 or newer and CONFIG_SECCOMP=y and CONFIG_SECCOMP_FILTER=y kernel configuration options. sydbox-scm exheres has a seccomp option to pass --enable-seccomp to econf. This is one of the key features which may make sydbox-1 faster compared to sydbox-0 because in this mode sydbox only traces the sandboxed system calls. Tracing other commonly used system calls - think threaded applications calling sched_yield() - is therefore avoided.
  • Logging is easier to filter. This still needs some work though.
  • Port numbers can now be entered as service names which will be queried from the services(5) database.
  • Unsupported socket families can be whitelisted/blacklisted.
  • New magic commands exec/resume_if_match and exec/kill_if_match are added. These commands may be used to resume or kill matching binaries upon successful execution. Paludis has esandbox resume and esandbox kill commands as an interface for exheres-0 (Make sure esandbox api returns 1 before using them). See systemd.exlib as an example on how we can now restart services from within exhereseses without worrying about sandboxing.
  • Read sandboxing to prevent unwanted filesytem reads.
  • Black listing is now also supported in addition to white listing. This may be used to make an “allow by default and black list unwanted accesses” sandboxing policy.
  • Many bugs fixed, some new system calls are sandboxed.

How can I thank you?

Send me poems8!


  1. She used to be called pandora in the early days.

  2. Not sydbox-0-scm which is the old one.

  3. http://git.exherbo.org/sydbox-1.git/

  4. http://dev.exherbo.org/~alip/sydbox/sydbox.html

  5. Eventually sydbox-1 will install its tests so this phase is going to be more convenient.

  6. sydbox-1 has been tested for some time by kind people and I have heard about only one such issue so far but it is always a good idea to be cautious.

  7. http://lwn.net/Articles/475043/

  8. http://dev.exherbo.org/~alip/sydbox/poems.txt

September 29, 2012 07:00 AM

September 22, 2012

Ciaran McCreesh

Paludis 0.80.0 Released

Paludis 0.80.0 has been released:

  • EAPI 5 is supported.

Filed under: paludis releases Tagged: paludis

by Ciaran McCreesh at September 22, 2012 06:50 PM

September 07, 2012

Ciaran McCreesh

Paludis 0.78.2 Released

Paludis 0.78.2 has been released:

  • Bug fix: || ( ) dependencies under a non-enabled label are now handled sensibly.
  • Bug fix: the resolver no longer attempts to create binaries for accounts.
  • Bug fix: 0-scm is now ordered correctly.

Filed under: paludis releases Tagged: paludis

by Ciaran McCreesh at September 07, 2012 09:02 PM

August 13, 2012

Ciaran McCreesh

Paludis 0.78.1 Released

Paludis 0.78.1 has been released:

  • sydbox-1 is now supported.
  • Bug fix.

Filed under: paludis releases Tagged: paludis

by Ciaran McCreesh at August 13, 2012 10:44 AM

June 08, 2012

Mike Kelly

Exherbo: Myths and Facts

So, some people seem to have gotten all in a tizzy about Exherbo. While I don't personally think the wording on the front page is necessarily the best, here's the deal:

  • We don't hate you. We just know we don't quite have something ready for general use. Rather than deal with many users wanting to try out something that most likely will not work for them, we have attempted to dissuade people from trying Exherbo until we think it's ready for them to.
    • "Then why announce it?" Because Bryan is going to discuss it at an upcoming conference, so we decided we should have some sort of web page up. We didn't put it up on Slashdot, though.
  • This isn't Ciaran's brainchild. It's Bryan Østergaard's (aka kloeri). Yes, Ciaran is involved in the project, along with a number of other former Gentoo developers, but he isn't the "lead" (though I don't think we really formal roles at this point).
  • "Why don't you use...?" We've already looked at many existing projects to fill some of the spots we've decided to fill ourselves instead. For example, we took a look at upstart, Gentoo's baselayout 1.x, openrc, etc. However, none of them seemed to do quite what we wanted. That's why we're working on projects like genesis, why we're writing our package tree from scratch, and using our own package format.

So, I hope this helps to clarify things for some people who still seem to be confused as to what Exherbo is all about.

Update: fix links.

by Mike Kelly at June 08, 2012 08:16 PM

Encrypting your /home

I was inspired by a post on the Command Line Warriors blog to encrypt my /home directory. Unfortunately, the directions given in that post don't quite work. Here is the process I followed to set everything up.

We're setting up a basic LUKS volume encrypted with AES with a 256-bit key. This means we make a special "filesystem" on the disk partition which encrypts our real filesystem on disk, and makes it available unencrypted via the device-mapper interface (/dev/mapper/).

First, you need to have a partition available for your /home directory. In my case, I decided to nuke my Windows install, but most people will probably need to use parted to resize some existing partitions. If you're resizing your root ("/") partition, you'll need to run it from a LiveCD. For the partition, I chose the "Linux" type, but I'm not sure that really matters.

Once you've allocated the partition, you'll need to create the LUKS partition. You do this with the cryptsetup command. But, before you can use this, you'll need to make sure you've compiled these settings into your kernel: CONFIG_DM_CRYPT, CONFIG_CRYPTO_CBC, CONFIG_CRYPTO_SHA256, and CONFIG_CRYPTO_AES.

After configuring your kernel and you've rebooting, if need be, you'll need to install sys-fs/cryptsetup. Don't install sys-fs/cryptsetup-luks... it's old. The newest (>1.0) versions of cryptsetup are based on the -luks version, and are what you should be using.

Now, use cryptsetup to format the luks partition:


  cryptsetup luksFormat -c aes-cbc-essiv:sha256 /dev/hda4

Substitute /dev/hda4 with whatever partition you created earlier. It will ask you to enter a password. Use a strong one, and don't just write it on a piece of paper by your computer, or you've defeated the whole point of this.

Now, we need to open the partition so we can create our encrypted data partition. We do this with the following:


  cryptsetup luksOpen /dev/hda4 crypt-home

This will make /dev/mapper/crypt-home, which is the device you use to mount your /home. Currently that partition is unformatted, so use your mkfs of choice to format it.


  mke2fs -j /dev/mapper/crypt-home

Next, make a temporary place to mount this so you can copy over your data, and mount it.


  mkdir /mnt/crypt-home
  mount /dev/mapper/crypt-home /mnt/crypt-home

And then, copy all your data from your current /home to the new one:


  rsync -tarv /home/* /mnt/crypt-home

Now would also be a good time to back up your important data to some other location.

Before we continue, we should configure the system to mount our new /home at boot. This requires editing /etc/fstab:


  # /etc/fstab
  # ... your other stuff ...
  /dev/mapper/crypt-home /home ext3 noatime 0 2

and /etc/conf.d/dmcrypt:


  # /etc/conf.d/dmcrypt
  # This file has all sorts of comments in it already
  # just uncomment the following:

  ## /home with passphrase
  target=crypt-home
  source='/dev/hda4'

Now all that is left is to remove the unencrypted copy of /home. First, you should go through and rm -rf anything that doesn't contain sensitive information, like open source project code, your mp3s, etc.

The last step is to use the shred command to securely delete all the remaining files. Shred works by overwriting a file many times with different patterns to make recovering them extremely difficult. Use the following commands to securely delete all the files in home, and then remove all the empty directories:


  find -H /home/*/ -type f -exec shred -u -v {} \;
  rm -rf /home/*/

Now, reboot and if everything went well, you should be prompted for your password, and then everything should just work as it did before.

Update: fixed links.

by Mike Kelly at June 08, 2012 08:12 PM

Switch to Apache2, WebDAV for Subversion, and evil google robots

So, I finally dropped lighttpd/fcgi and switched back to Apache 2.2. Trac is running with mod_python now. I think I've tracked down the main cause of our load/memory issues - googlebot. It was indexing all 4000 some revisions of our svn repository via the trac browser... bad stuff, but it should be blocked from that by our robots.txt now.

Also, I've added WebDav for Subversion now. Paludis is at http://svn.pioto.org/paludis, and the same is true for most of the other repos I host as well. Now those who have evil company/school firewalls and proxies can get through.

Update: SVN is sooooo 2007. Paludis is using git now: http://git.exherbo.org/paludis/paludis.git/

by Mike Kelly at June 08, 2012 08:07 PM

My random old scripts moved to git

So, I had a few random old scripts lying around in SVN. I've migrated them to git now. Along with my other repos, they're browseable at http://git.pioto.org/

Things of interest might be:

  • rbtpb - A replacement for tpb which is hopefully more robust.
  • rubeak - A tool for handling multimedia keyboard keys, and some IR remotes.

Update: fixed links.

by Mike Kelly at June 08, 2012 07:57 PM

RbTPB - A ruby script for handling brightness/volume display on thinkpads

So, been a while, but here's something I just threw together. It's still a little rough around the edges, but it seems to be more robust than tpb for my system, at least, and it doesn't require me to make /dev/nvram available.

It uses /sys/class/backlight/thinkpad_screen/actual_brightness (from the thinkpad_acpi module in the 2.6.22 kernel) to figure out the screen brightness, and /proc/acpi/ibm/volume to figure out the volume and mute states, also provided by the thinkpad_acpi module (I'll switch to using sysfs for this when it becomes available).

It also requires the ruby-xosd package, which you can get from my overlay: git://git.pioto.org/pioto-overlay.git

For lazy paludis users, just add this to /etc/paludis/repositories/pioto-overlay.conf:

format = ebuild
location = /var/paludis/repositories/pioto-overlay
sync = git://git.pioto.org/pioto-overlay.git
master_repository = gentoo
names_cache = /var/cache/paludis/names
write_cache = /var/cache/paludis/metadata

Or, you can just do: playman -a pioto-overlay

You can get the current version of this script from git at: https://github.com/pioto/rbtpb

Update: Fix links.
Update 2: Fix links, again.

by Mike Kelly at June 08, 2012 07:55 PM

May 15, 2012

Mike Kelly

Migrating from Typo to Movable Type

I migrated my blog from Typo to Movable Type a while ago. I wrote a little script to do it, but I've only just now gotten around to cleaning it up enough so that it's suitable for general use.

It's available now from my git repo, and on CPAN

As always, "patches welcome".

by Mike Kelly at May 15, 2012 05:00 PM

Random Perl Hacking

My day job mostly involves Perl, so I've been using it more for my random tasks at home. I've now put a few of them up on CPAN:

  • Unix::Uptime - Determine the current uptime, in seconds, and load averages, across different *NIX architectures.
  • Remind::Client - class for working with remind's daemon mode

I also have a few other scripts I've been messing around with, for doing some reporting and such:

by Mike Kelly at May 15, 2012 04:57 PM

March 13, 2012

Bryan Østergaard

Pictures from Open Source Days?

This weekend saw yet another edition of the Open Source Days conference in Copenhagen. And despite a few small issues (most notably a large power outage taking out a big area of the city) most people really seemed to enjoy the conference.

I also saw quite a few people taking pictures of the event and we'd love to see those pictures. Please send an email to team2012@opensourcedays.org or directly to me at bryan@opensourcedays.org if you would like to share your pictures.

March 13, 2012 11:47 AM

March 03, 2012

Bryan Østergaard

Looking for helpers for Open Source Days

With the conference just a week away we're still looking for volunteers.

Volunteering for Open Source Days means you'll get to know a lot of other open source interested people, broadening your network and you get to be an active part of the biggest open source event in Denmark.

You'll typically have to work 2 x 3 hours at the conference but for the most part you can decide what areas you want to help with and we do our best to coordinate your shifts so they don't conflict with talks you find particularly interesting.

As a thank you for your work we throw in conference tickets including the saturday night social event.

Right now I'm particularly looking for people with some video experience. You don't need professional video experience but a little experience goes a long way towards making the setup go more smoothly. We will of course make sure that people on the video team gets the needed instructions so don't be afraid of signing up even if you have no prior experience. The most important thing is your interest and dedication as that's what's ultimately going to it a success.

Besides volunteers for the video team we're also looking for a number of other people. There's too many different roles to mention them all here but we still need chairmen for example.

Please contact me directly at bryan@opensourcedays.org if you want to volunteer for the video team. If you want to sign up for the many other roles you can do so using our sign up form.

March 03, 2012 12:43 PM

February 19, 2012

Wulf C. Krueger

systemd in Exherbo – what’s happened so far…

It has been quite a while since I last wrote something about my work on systemd in Exherbo, so here’s an update:

What has been accomplished so far:

  • The Exherbo patches are done. Do NOT try to submit them upstream yet, though. I’ll take care of that when the time is ripe.
  • Lots of services are done.
  • You can boot and run most systems using systemd now.
  • I’ve built new amd64 and x86 stages without any init system so you can start out without the baselayout-1/sysvinit cruft.
  • The installation guide has been updated.

Every systemd service is implemented natively and we’re not using anything from baselayout-1 or sysvinit anymore. Instead, all the important stuff has been moved to skeleton-filesystem-layout. systemd’s dependencies have been updated accordingly.

Thus, for people using systemd, baselayout-1 and sysvinit are now obsolete. YAY!

What still needs to be done:

  • Improve existing service definitions for systemd.
  • Create socket definitions for several of the existing service definitions. (And new ones, of course.)
  • Create systemd service files for missing services.

Rules for new service files:

  • Please make sure they’re implemented natively. I won’t accept non-native service files unless you can convince me there’s definitely no other solution.
  • If you convinced me, scripts go to /usr/${LIBDIR}/systemd.
  • EnvironmentFiles (configuration) go to /etc/conf.d and end in .conf. We do NOT create a configuration file for every single service but create (grep-able) logical units, e. g. now-obsolete font@.service and keymap@.service used to use console.conf).
  • You can reference environment variables from configuration files in service. If you have to quote the values in the configuration file, you need to use $FOO; if you don’t quote them (preferred), you use ${FOO}. This is probably a bug (and known to upstream) but for now that’s how it is.
  • Services and their (potentially) accompanying files must not collide with baselayout-1.

Requirements:

  • You have to run Linux kernel >=2.6.36-rc1 (I’m using 2.6.36-rc6; latest NVidia-Drivers work fine and there are patches for the VMWare modules available.).

How to get started with systemd:

Read this.

Conclusion:

Since both systemd and its exheres have now reached an acceptable degree of stability, I don’t intend on breaking things anymore as I’ve done over the last months from time to time.

In fact, systemd is so usable these days, I’m writing this on a systemd-initialised system! This means as well that I can live without baselayout-1 and sysvinit. YAY! :-)

by Wulf C. Krueger at February 19, 2012 04:02 PM

February 18, 2012

Bryan Østergaard

Open Source Days ticket sale now open

The Open Source Days conference opened the ticket sale a couple days ago. You can buy tickets for the conference itself as well the many training courses we're arranging in the days before the conference.

See opensourcedays.org for more information and pay attention to the early bird discount that ends about 5 days from now.

Also note that while there's not that many abstracts on the website yet we're going to keep adding batches of new abstracts. There's going to be a lot of interesting talks so keep checking the website for new abstracts and other news.

February 18, 2012 10:28 PM

January 15, 2012

Bryan Østergaard

Open Source Days - Second call for speakers

The second and final call for speakers just went out for the Open Source Days conference in Copenhagen, Denmark.

Noteworthy news compared to the first call is:
- We moved the conference a week to make sure we have plenty of room for speakers, visitors and sponsors. The conference is going to take place at march 10 and 11 with training happening on march 9.
- We added information about conference size and being somewhat ambitious we're hoping to reach previous heights of 800-900 people.
- Extended the deadline for talk proposals. Deadline is now january 27th.
- User groups interested in a community booth also needs to start planning. Deadline is february 13th but you need to start thinking of activities, manning the booth and so on.

More information and details to be found on opensourcedays.org

Don't miss Denmarks biggest open source event!

January 15, 2012 11:25 PM

December 07, 2011

Bryan Østergaard

Open Source Days 2012: Call for speakers

Open Source Days is Denmarks biggest open source conference and it's only 3 months away now. We are therefore looking for interesting speakers.

The conference has two focus areas, namely:
  • startups (everything related to startups / small business and open source software)
  • green technology (recycling, monitoring etc.)
Besides these two focus areas we also have several tracks with general technical talks. These tracks can cover everything from office packages to interesting new programming languages, network administration or other more technical areas.

See www.opensourcedays.org for the full announcement.

December 07, 2011 07:59 PM

October 01, 2011

Wulf C. Krueger

Exherbo – my goals for the remainder of 2011 & 2012

(Disclaimer: The following is just my personal opinion and what *I* want to achieve for Exherbo. It’s fairly likely not everyone will agree with everything I’m going to state. :-) )

We’ve come a long way with Exherbo since we started:

- We have a pretty much complete set of packages to use Exherbo on desktop, notebook and server systems.
- With exheres-0, we have a very powerful and useful EAPI.
- We’re now a rather “stable” Linux distribution in that we don’t usually break things every other week anymore.
- We’ve stopped actively discouraging people to try Exherbo.

 

That said, I still have a few goals I’d like to see achieved:
 

For some months now, I’ve been in discussions with the OIN and I’m happy to say that we’re going to join them. I hope (and am confident) we’ll get this done in 2011.

- Set up a structure that would allow us as a project (in contrast to individual developers) to accept donations.
Currently, Exherbo doesn’t really have any means to accept donations as a project. Sure, as individuals, we can accept them (e. g. a generous donator (who wants to remain anonymous) gave me a very nice server which we’re now using for Exherbo) but Exherbo as a project can’t.

There are several ways to accomplish this:

- Join an umbrella organisation that accepts donations on our behalf.
- Create an organisation for Exherbo ourselves.

Personally, I’d strongly prefer to create an organisation ourselves, e. g. as a German “eingetragener Verein” (“e. V.”), a (non-profit) registered association.
We’d be independent from weals and woes of any umbrella organisation and we’d have much more freedom to deal with anything concerning donations, laws, etc.

Since becoming a registered association would require some effort and actually cost money (in the case of an e. V. about EUR 75 to 120), I’d be willing to do the paperwork and pay for it myself.

(To be completely honest, I would not be willing to work and/or pay for joining some umbrella organisation.)

- Creating a “Developer’s Manual”.
We do have exheres-for-smarties and it’s really good but it can’t really stand alone. We still expect people to be at least somewhat aquainted with that thinG… That needs to change!

Thus, one of these days I’m going to start working on a real, full-blown “Developer’s Manual” which will incorporate everything you need to create and work on exheres.

- Getting multilib/multibuild to work
We’ve had multilib branches for what feels like aeons. People have worked on multilib (spb, myself, compnerd & others) and they seem to have given up.

I’m not sure what’s wrong with our current approach (if you do, please comment on it here) but I know I really want to see the day when we can finally merge the multilib branches back to master.

Should that turn out to be impossible, we should get rid of them for good but we need to finally do something about multilib/multibuild.

- A stable exheres-1.
As I said in the introduction, exheres-0 is fairly stable by now and, I think, pretty much feature-complete (maybe with the exception of multilib/multibuild).

Thus, I’d really get to the point where we formally declare that and make exheres-0 into a stable exheres-1 EAPI.

This is mostly a symbolic goal but I think it would give us, Exherbo, a slight increase in credibility and confidence.

- Participation in Google’s Summer of Code.
For three years we’ve been trying to get accepted into Google’s Summer of Code. This year, I’ve lead the third attempt to get accepted and, according to Google, we almost got there.

In 2012, I’m definitely going to try again by employing the improvements Google suggested. I do want Exherbo to participate in GSOC – and if it’s the last thing I’ll ever do! ;-)

(This, too, is more of a symbolic achievement but it’s important to me and it would potentially help Exherbo achieve some sound technical goals as well.)

- Exherbo entry on Wikipedia
Entirely symbolic, this goal is just here because i think we’re nearing the point where Wikipedia’s guidelines about notability, etc. will be met.

- Working on patches
My personal pet peeve. We really need to improve on working on patches.

I’m not sure we’ll be able to achieve all these goals but I’m going to do my best to make all of these become reality for a bright future for Exherbo!

by Wulf Krueger at October 01, 2011 01:21 PM

June 28, 2011

Ali Polatel

pinktrace-0.1.2

pinktrace-0.1.2 is released with a minor change to recognize Linux-3.0 and a new function pink_name_lookup_with_length()

June 28, 2011 07:00 AM

June 09, 2011

Ali Polatel

Multilingual Site using Jekyl & Liquid

Here is a tip to make a multilingual site using Liquid templates and Jekyll relatively easily and with few duplications.

I will be giving examples from my own experience for http://alip.github.com/

Start by specifying the language in YAML Front Matter using a custom tag like lang:

    ---
    layout: default
    title: Projelerim
    lang: tr
    ---

Here lang is just a custom tag which we can make use via page.lang variable from within our pages.

Next, change your _layouts/ and _includes/ to be multilingual using simple case statements:

    <h3>{% case page.lang %}{% when 'tr' %}Etiket Bulutu{% else %}Tag Cloud{% endcase %}</h3>

Make note of the else statements which we use to specify a default language. So pages without the lang tag will be in English.

That’s all!

For more information, feel free to play with the source code of my blog: http://github.com/alip/alip.github.com

Now I’ll be writing a Turkish translation of this post and see if it works :)

Note to self: writing literal Liquid inside Liquid requires some weird syntax mentioned here.

June 09, 2011 07:00 AM

January 31, 2011

Ingmar Vanhassel

We are going to FOSDEM!

Like previous years, a few of the Exherbo developers will be coming to FOSDEM!

If you’ve been dying to meet Alexander Færøy, Bo Ørsted Andresen, Bryan Østergaard (or if you really want to know what an emu using a linux computer looks like), Jochen Maes or myself, find us at the beer event, or anywhere at the conference! Feel free to hop by in #exherbo to find our whereabouts.

See you there!


by ingmarv at January 31, 2011 04:17 PM

January 19, 2011

Ali Polatel

For Hrant

19th January 2007 was a black day. Journalist Hrant Dink was assassinated by a Turkish nationalist. Hrant was a brave man who refused to remain silent despite threats on his life. Today - after four years - the pain is still fresh. The anger towards fascism and the will to escape from our stinking black-minded ignorance keeps growing.

Just like other intellectuals of this land whose lives were taken away - Ahmet Taner Kışlalı, Bahriye Üçok and Uğur Mumcu to name a few - he has a place in our hearts. Their ideas and thoughts shed light on our path to peace.

January 19, 2011 08:00 AM