Saturday, December 28, 2013

foomatic is moving into cups-filters

Part of the printing packages on Gentoo are very similar to, err, well, a dumpster on a hot summer afternoon. Nobody really wants to lift the lid and look inside, and beware of poking around in it... version numbers starting with 2007 and self-generated distfiles that noone knows how to regenerate. Yes I'm trying but so far my insights are limited.
What news is happening? The foomatic filters, an awesome printer driver system, originally supported not just CUPS but also LPRng, LPD, and many other prehistoric printing systems. Turns out, every backend except cups is now unmaintained. As a result, after a Google summer of code project, the actual filter binary is now upstream moving into cups-filters, to have a more active development and be perfectly integrated into the CUPS printing system. (Yes this means foomatic support for LPRng will not see further updates and may have to go away one day in the future due to bitrot.) For Gentoo this means that newer versions of net-print/cups-filters cannot be installed together with net-print/foomatic-filters but replace that package.
As a result we get to today's call for testers, preferably ~arch users: If you feel adventurous and if you are using foomatic-filters together with cups, please keyword newest cups-filters, remove foomatic-filters from your world file, and upgrade:
echo '=net-print/cups-filters-1* **' > /etc/portage/package.keywords/cupsfilters
emerge --deselect net-print/foomatic-filters
emerge -uDNav world
If this leads to blockers with one of the following packages, you might want to upgrade that to newest ~arch or re-emerge it first:  net-print/foo2zjs, net-print/foomatic-db-engine, net-print/foomatic-filters-ppds, net-print/hplip, net-print/pnm2ppa
Then, test if your printers still work! Any feedback is appreciated, either on a tracking bug or here in the comments section.

Sunday, December 8, 2013

LibreOffice KDE integration

I was this close to just masking the LibreOffice KDE integration in Gentoo and let it be done with that. Recently some really ugly bugs in the glue code crept up (crashes in the file dialog and in drag-n-drop), impacting productivity a lot... Asking around I heard that the KDE/Qt integration of LibreOffice was basically unmaintained and bitrotting.
Luckily someone stepped up and started bugfixing, and patches have made their way into the LibreOffice git master branch (and partially also into libreoffice-4.2). I have prepared a backport for the two bugs mentioned above; I'm flying blind and this is completely untested, but feedback on the bug reports would be very welcome! If you want to try (note, this affects only LibreOffice with USE=kde), keyword
=app-office/libreoffice-4.1.3.2-r2 **
somewhere in /etc/portage/package.keywords, start the update, and get some fish for your penguins; they will be busy for a while... :)

Thursday, November 21, 2013

SFB 689 "Spin phenomena in reduced dimensions" funding also renewed for another 4 years!

Yet another piece of exciting news reaches us from Bonn today. After positive evaluation some weeks ago, the collaborative research centre SFB 689 "Spin phenomena in reduced dimensions" has now also officially received a renewal of funding for four more years. Time to celebrate - and then do a lot more of fascinating research!

Wednesday, November 13, 2013

Deactivating the RC4 cipher in Firefox

This has probably been blogged, reblogged, and reblogged again. Anyway... The RC4 cipher is considered broken, however many https websites still use it as default and Firefox even displays these connections as "high grade encryption". What can you do? Disable RC4 in the Firefox configuration!
  1. Call up the configuration page by typing about:config in the address bar.
  2. Firefox may pop up a warning along the lines of "here ends your warranty". If it does that, confirm that you'll be careful. 
  3. On top of the page, above many config settings, there's now a search bar. Enter RC4
  4. As search result you see the various cipher combinations that use this encryption standard (6 lines here). Double-click on each of these 6 lines (e.g. security.ssl3.rsa_rc4_128_md5) to toggle them from "true" to "false". 
  5. That's it, you're done.
Note that if a web site ONLY supports RC4 then you'll end up with a connection error now. You probably shouldn't go there anyway though.

Friday, November 8, 2013

GRK 1570 "Electronic Properties of Carbon Based Nanostructures" extended!

Today's exciting news is that funding for the the Regensburg DFG research training group "Electronic Properties of Carbon Based Nanostructures" (GRK 1570) has been extended until 2018! The program focuses on the experimental and theoretical investigation of carbon-based nanostructures, i.e. devices based on graphene, carbon nanotubes, aromatic molecules or hybrids of those. A large number of projects is involved, with topics as various as e.g. the transport spectroscopy and analysis of electronic interactions in ultra-clean carbon nanotubes (our group), atomic force microscopy based research on forces in molecular electronics, or femtosecond plasmonics in graphene. More details on the research activities can be found on the projects web page, including direct links to the participating research groups. Thanks a lot to everyone who helped making this happen!

Friday, November 1, 2013

Speeding up app-office/libreoffice-bin generation

Since the last app-office/libreoffice-bin upgrade was long-delayed and overall slightly painful, we've modernized behind the scenes. Patrick Lauer a.k.a. bonsaikitten, who is amongst other things already running the commit notification bot irker on #gentoo-commits and the amazing AutoRepoman verifying quality and consistency of the portage tree, has provided me with generous access to two dedicated build chroots for amd64 and x86 libreoffice on a rather fast server. Together we're trying to automatize the upgrade process as much as possible. The app-office/libreoffice-bin-4.1.3.2 packages that I'm uploading right now and that will appear on the mirror servers and in the portage tree within the next 24h are the first result of the new setup. Test and enjoy!
Oh yeah, and since many people have asked me already, the awesome new splash screen was contributed by Denis M. a.k.a. Phr33d0m, see bug 456666. Thanks a lot too!

Saturday, October 19, 2013

Gentoo on Facebook

Turns out Gentoo had a Facebook page with >10k "likes" already for quite some time. It was created in 2008 by a developer who later stopped using Facebook at some point, and noone really posted anything "official" there. Well, now's the time to step up public relations a bit... We (as in the people I spoke to on the #gentoo-pr Freenode channel) are not 100% sure so far what to do with it exactly, but there will certainly be occasional news and updates. Also, I'm feeding it with the Gentoo Planet RSS. If you are a Facebook user, head to the page and like us! :)

Lab::Measurement 3.20 released - including Lab::XPRESS

We have uploaded Lab::Measurement 3.20 to CPAN today. This release includes significant new features, in particular in the high-level measurement code and in the instrument readout logic.

The central new feature is Lab::XPRESS. This set of Perl modules builds upon the Instrument layer and provides a replacement and alternative to the Lab::Measurement class and its metadata handling. As detailed in several examples (1, 2, 3), nested loops of parameters, as e.g. gate voltages, combined with arbitrary measurements at each point can now be implemented in a highly flexible but simple way: you describe the logical structure of the measurement, without having to program the loops yourself. This means the actual measurement scripts become simpler and shorter, while remaining highly configurable. The underlying code can automatically take care of many details such as waiting times, timing of measurements, and pause or well-defined abort of the script on key events.

At the Instrument level, foundations have been laid for a centralized caching of instrument parameters. While this defaults off, it can be enabled in an instrument driver. The functionality is useful e.g. if reading out a parameter from the device that does not change on its own, unless explicitly set by a script, is a slow command. This also includes a generic support for asynchronous readout, i.e. first requesting a measurement value and thereby starting a read-out, then later in a separate command reading the result.

In addition, several instrument drivers have been added in varying states of completion, as e.g. the Cryogenic SMS magnet power supply, the Knick S252 voltage source, the Anritsu MG369xB signal generator, and the Keithley 2000 multimeter.

Finally, the TCPraw connection has been deprecated in favour of a new generic Socket implementation which provides a larger feature set. While TCPraw is still available, it internally only calls Socket and will be removed in a future version.

The release package is available from CPAN. Documentation as well as a web view of the Git code repository and a bug tracker are available from the package homepage https://www.labmeasurement.de/.

app-emulation/vmware-workstation-10 and friends

I finally got around to import the ebuilds for the new VMware Workstation and Player versions into the main tree. Thanks a lot to all the contributors on Bugzilla. Right now the ebuilds do not have any keywords yet since I have not tested the installation results at all myself, so if you want to try installing the software, remember you need a license for VMware Workstation, and 10 != 9 :], and then keyword it manually in /etc/portage/package.keywords as follows:
=app-emulation/vmware-modules-279* **
=app-emulation/vmware-workstation-10* **
=app-emulation/vmware-player-6* **
(Obviously this will only work on x86 and amd64, since the software only exists for these architectures.) Feedback of all sorts is welcome on the version bump bugs for VMware Workstation and the kernel modules and for VMware Player.

Friday, October 11, 2013

Not keeping up - DB ICE w-lan hotspots pointless

We used to be very much at the top of travel comfort, at least what network connectivity concerned. On many routes of the high speed trains within Germany, W-LAN hotspots were installed in the cars, and the network was (not free but) reliable and quite fast. (Which 3G mobile network connectivity usually is not once you're moving at 300kph.)
Now, in the age of the smartphone, unfortunately we learn firsthand what happens if supply does not follow demand... During each of my last train trips, the router was quickly out of IP adresses. Strong signal, wi-fi connection fine, no network layer. Which makes the whole thing extremely pointless. :(

Friday, September 27, 2013

pss(b) accepted: Negative frequency tuning of a carbon nanotube nano-electromechanical resonator under tension

One of the measurements in the MSc project of Sabine Kugler revealed a very particular carbon nanotube nano-electromechanical resonator. Usually the mechanical resonance frequency is tuned up to higher values by applying a gate voltage to the back gate: the larger charge on the nanotube and the larger forces between gate and nanotube cause mechanical tension within the nanotube, and exactly the same way as when tuning a guitar or piano string this translates to a higher resonance frequency. Curiously, here a very strong effect to the opposite can be observed; we can tune the resonance frequency to 75% of its zero-gate voltage value by applying a gate voltage! This is even more astonishing since we can conclude from the higher harmonics of our vibration mode that the nanotube is under tension.
The observed effect can be explained via so-called electrostatic softening of the vibration mode. Let us assume that the carbon nanotube is very close to the gate and vibrates towards and away from it. The capacitance between gate and nanotube varies within one oscillation cycle, and thereby the electrostatic force between these two obtains an additional position-dependent component. This can be seen as an electrodynamic contribution to the spring constant of the resonator; it is negative and thereby decreases the resonance frequency. We can estimate the size of this effect and obtain indeed consistent values for our sample geometry.

"Negative frequency tuning of a carbon nanotube nano-electromechanical resonator under tension"
P. L. Stiller, S. Kugler, D. R. Schmid, C. Strunk, and A. K. Hüttel
accepted for publication by physica status solidi (b), arXiv:1304.5092 (PDF)

Monday, July 15, 2013

Thank you

I'm going to keep this short: now that the election results for the Gentoo Council are out, thanks a lot for your vote of confidence. It'll be an honour and a pleasure to help making Gentoo the most awesome not-just-linux distribution ever. :)

Wednesday, May 29, 2013

News from the 2013/05 Gentoo KDE team meeting

Last week we had our monthly Gentoo KDE team meeting; here are few details that are probably worth sharing.
  • So far we've provided the useflag "semantic-desktop" which in particular controls the nepomuk functionality. Some components of KDE require this functionality unconditionally, and if you try to build without it, bugs and build failures may occur. In addition, by now it is easily and reliably possible to disable e.g. the file indexer at runtime. So, we've decided that starting with KDE 4.11 we will remove the useflag and hard-enable the functionality and the required dependencies in the ebuilds. The changes are being done already in the KDE overlay in the live ebuilds (which build upstream git master and form the templates for the upcoming 4.11 releases).
  • After recent experiences the plan to drop kdepim-4.4 is off the table again. We will keep it in the portage tree as alternative version and try to support it until it finally breaks.
  • In the meantime we (well, mainly Chris Reffett) have started in the KDE overlay to package Plasma Active, the tablet Plasma workspace environment. Since Gentoo ARM support is already excellent, this may become a highly valuable addition. Unfortunately, it's not really ready yet for the main tree and general use, but packaging work will continue in the overlay- what we need most is testing and bug reporting!
Independent of the meeting, a stabilization request has already been filed for KDE 4.10.3;  thanks to the work of the kde stable testers, we can keep everyone uptodate. And as a final note, my laptop is back to kmail1... Cheers!

Edit, 13/6/2013: Johu has posted a blog entry on how to disable the semantic desktop functionality at runtime.

Sunday, May 26, 2013

OpenPGP smartcards and Gentoo - part 2: card and gnupg setup

This is part 2 of a tutorial on OpenPGP smartcard use with Gentoo. Part 1 can be found in an earlier blog post. This time, we assume that you already have a smart card and a functioning reader, and continue setting up the card. Then we'll make everything ready for use with GnuPG by setting up a key pair. As already stated, I am picking a compromise between ultra-security and convenience. Please do not complain if you find guides on the web on how to do things "better". All information here is provided as a best effort, however I urge you to read up on your own. Even if you follow this guide to the last letter- if things break, it is your own responsibility.

Setting the AdminPIN and the PIN

OK, let's start. We insert a blank card into the card reader. The card should come with some paper documentation, stating the initial values of the PIN and the AdminPIN- these we will need in a moment. Now, we want to edit the card properties. We can do this with the command "gpg --card-edit".
jones@pinacolada ~ $ gpg --card-edit 

Application ID ...: D276000124010200000500000AFA0000
Version ..........: 2.0
Manufacturer .....: ZeitControl
Serial number ....: 00000AFA
Name of cardholder: [not set]
Language prefs ...: de
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: forced
Key attributes ...: 2048R 2048R 2048R
Max. PIN lengths .: 32 32 32
PIN retry counter : 3 0 3
Signature counter : 0
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]
General key info..: [none]

gpg/card> help
quit       quit this menu
admin      show admin commands
help       show this help
list       list all available data
fetch      fetch the key specified in the card URL
passwd     menu to change or unblock the PIN
verify     verify the PIN and list all data
unblock    unblock the PIN using a Reset Code
This menu is not really that helpful yet. However, a lot more commands are hidden below the "admin" keyword:
gpg/card> admin
Admin commands are allowed

gpg/card> help
quit       quit this menu
admin      show admin commands
help       show this help
list       list all available data
name       change card holder's name
url        change URL to retrieve key
fetch      fetch the key specified in the card URL
login      change the login name
lang       change the language preferences
sex        change card holder's sex
cafpr      change a CA fingerprint
forcesig   toggle the signature force PIN flag
generate   generate new keys
passwd     menu to change or unblock the PIN
verify     verify the PIN and list all data
unblock    unblock the PIN using a Reset Code
First of all we change the AdminPIN and the PIN from the manufacturer defaults to some nice random-looking values that only we know.
gpg/card> passwd
gpg: OpenPGP card no. D276000124010200000500000AFA0000 detected

1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit

Your selection? 3
At this point a window from gpg-agent pops up (same as when asking for a passphrase), requests the old AdminPIN and twice the new AdminPIN. Make sure you remember the new AdminPIN or write it down somewhere safe. The AdminPIN allows to change the card parameters (from name of cardholder to stored keys and PIN) and can be used to reset the PIN if you have forgotten it or mistyped it three times. However, if you mistype the AdminPIN three times, your card locks up completely and is basically trash. Note that changing the PINs cannot be done via a reader keypad yet.

PIN changed.

1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit

Your selection? 1
PIN changed.

1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit

Your selection? q

gpg/card>

Setting the cardholder data

Now, let's enter the cardholder data. With the first change you will be prompted for the AdminPIN.
gpg/card> nameCardholder's surname: Jones
Cardholder's given name: Henry W.

gpg/card> lang
Language preferences: en

gpg/card> sex
Sex ((M)ale, (F)emale or space): M

gpg/card> quit
jones@pinacolada ~ $
What are the remaining commands good for? Well...
  • "url" sets an URL where to retrieve the public keys. We will use that later on. 
  • "login" sets a log-in data field. Here you could store your username for e.g. network authentication. 
  • "forcesig" toggles a flag inside the card that has been introduced because of German legislative requirements for some smartcard applications. Normally, once you have inserted the card into the reader, you enter the PIN once for unlocking e.g. the encryption or the signature key, and then the key remains open for the moment. If the signature PIN is "forced", you will have to reenter the PIN again each time you want to make a signature.
  • "generate" generates a RSA key pair directly on the card. This is the "high security option"; the generated private key will and can never leave the card, which enhances its security but also makes backups of the key impossible.
Which leaves the "reset code" to be explained. Imagine you are issued a card by e.g. your employer. The card will be preset with your name, login, and keys, and you should not be able to change that. So, you will not know the AdminPIN. If you enter your user PIN wrong three times in a row, it is invalidated. Now the reset code instead of the AdminPIN can also be used to reset the PIN. Basically this is the same functionality as the PUK for mobile phone SIM cards. The definitive source on all this functionality is the OpenPGP Card 2.0 specification.

Generating GnuPG keypairs

As mentioned in the beginning, there are many different ways to proceed. A keypair can be generated on the card or in the computer. Different types of keys or parts of keys can be uploaded to the card. I'm now presenting the following use case:
  • We generate the GnuPG keys not on the card but on the trusted computer, and then copy them to the card. This makes backups of the keys possible, and you can also upload them later to a second card should the first one accidentally drop into the document shredder.
  • We upload the whole key, not just subkeys as described in some howtos. This makes it possible to access the entire GnuPG functionality from the card- decrypting, signing, and also especially certifying (i.e. signing keys). Of course this means that your primary key is on the card, too.
In general, before you generate a GnuPG keyset you may want to read up on GnuPG best practices; see e.g. this mailing list post of our Gentoo Infra team lead robbat2 for information and further pointers.
Enough talk. We use GPG to generate a 4096bit RSA primary key for signing and certifying with an 4096bit RSA encryption subkey. Note that for all the following steps you need in Gentoo at least app-crypt/gnupg-2.0.19-r2; I strongly recommend app-crypt/gnupg-2.0.20 since there smartcard handling has improved a lot.
jones@pinacolada ~ $ gpg --gen-key
gpg (GnuPG) 2.0.19; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 3y

Key expires at Tue May 24 23:26:58 2016 CEST
Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: Henry W. Jones Jr.
Email address: henry.w.jones@uchicago.edu
Comment:
You selected this USER-ID:
    "Henry W. Jones Jr. <henry.w.jones@uchicago.edu>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
You need a Passphrase to protect your secret key.

We need to generate a lot of random bytes. It is a good idea to perform

some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: /home/jones/.gnupg/trustdb.gpg: trustdb created

gpg: key 14ED37BC marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2016-05-24
pub   4096R/14ED37BC 2013-05-25 [expires: 2016-05-24]
      Key fingerprint = 3C94 3AC9 713D E3E3 B3C6  BF73 3898 61DB 14ED 37BC
uid                  Henry W. Jones Jr. <henry.w.jones@uchicago.edu>
sub   4096R/345D5ECB 2013-05-25 [expires: 2016-05-24]

jones@pinacolada ~ $
Got it. Now we do something unusual- in addition to the sign/certify (SC) main key and the encryption (E) subkey, we add a second subkey, an authentication (A) key (for later on). We edit the just generated key with the --expert option:
jones@pinacolada ~ $ gpg --expert --edit 14ED37BC
gpg (GnuPG) 2.0.19; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  4096R/14ED37BC  created: 2013-05-25  expires: 2016-05-24  usage: SC  
                     trust: ultimate      validity: ultimate
sub  4096R/345D5ECB  created: 2013-05-25  expires: 2016-05-24  usage: E   
[ultimate] (1). Henry W. Jones Jr. <henry.w.jones@uchicago.edu>

gpg> addkey
Please select what kind of key you want:

   (3) DSA (sign only)
   (4) RSA (sign only)
   (5) Elgamal (encrypt only)
   (6) RSA (encrypt only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
Your selection? 8
We select to add an RSA key where we set the capabilities ourselves. Now we disable Sign and Encrypt, and enable Authenticate instead.
Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions: Sign Encrypt

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? s

Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions: Encrypt

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? e

Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions:

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? a

Possible actions for a RSA key: Sign Encrypt Authenticate
Current allowed actions: Authenticate

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? q
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 3y
Key expires at Tue May 24 23:39:55 2016 CEST
Is this correct? (y/N) y
Really create? (y/N) y
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.

pub  4096R/14ED37BC  created: 2013-05-25  expires: 2016-05-24  usage: SC  
                     trust: ultimate      validity: ultimate
sub  4096R/345D5ECB  created: 2013-05-25  expires: 2016-05-24  usage: E   
sub  4096R/808D3DB3  created: 2013-05-25  expires: 2016-05-24  usage: A   
[ultimate] (1). Henry W. Jones Jr. <henry.w.jones@uchicago.edu>

gpg> save
jones@pinacolada ~ $
This additional key cannot be used directly by GnuPG, but it is stored in the keyring and will come in handy later on.

Copying the keys to the smartcard

Now we copy the secret keys to the smartcard.
jones@pinacolada ~ $ gpg --edit 14ED37BC
gpg (GnuPG) 2.0.19; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  4096R/14ED37BC  created: 2013-05-25  expires: 2016-05-24  usage: SC  
                     trust: ultimate      validity: ultimate
sub  4096R/345D5ECB  created: 2013-05-25  expires: 2016-05-24  usage: E   
sub  4096R/808D3DB3  created: 2013-05-25  expires: 2016-05-24  usage: A   
[ultimate] (1). Henry W. Jones Jr. <henry.w.jones@uchicago.edu>
With "toggle" we switch from public key to secret key view.
gpg> toggle

sec  4096R/14ED37BC  created: 2013-05-25  expires: 2016-05-24
ssb  4096R/345D5ECB  created: 2013-05-25  expires: never     
ssb  4096R/808D3DB3  created: 2013-05-25  expires: never     
(1)  Henry W. Jones Jr. <henry.w.jones@uchicago.edu>
We select the authentication key and move it to the card (we need the AdminPIN for that):
gpg> key 2

sec  4096R/14ED37BC  created: 2013-05-25  expires: 2016-05-24
ssb  4096R/345D5ECB  created: 2013-05-25  expires: never     
ssb* 4096R/808D3DB3  created: 2013-05-25  expires: never     
(1)  Henry W. Jones Jr. <henry.w.jones@uchicago.edu>

gpg> keytocard
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]

Please select where to store the key:
   (3) Authentication key
Your selection? 3

sec  4096R/14ED37BC  created: 2013-05-25  expires: 2016-05-24
ssb  4096R/345D5ECB  created: 2013-05-25  expires: never     
ssb* 4096R/808D3DB3  created: 2013-05-25  expires: never     
                     card-no: 0005 00000AFA
(1)  Henry W. Jones Jr. <henry.w.jones@uchicago.edu>
Then, we select the encryption key and deselect the authentication key; same procedure follows.
gpg> key 1

sec  4096R/14ED37BC  created: 2013-05-25  expires: 2016-05-24
ssb* 4096R/345D5ECB  created: 2013-05-25  expires: never     
ssb* 4096R/808D3DB3  created: 2013-05-25  expires: never     
                     card-no: 0005 00000AFA
(1)  Henry W. Jones Jr. <henry.w.jones@uchicago.edu>

gpg> key 2

sec  4096R/14ED37BC  created: 2013-05-25  expires: 2016-05-24
ssb* 4096R/345D5ECB  created: 2013-05-25  expires: never     
ssb  4096R/808D3DB3  created: 2013-05-25  expires: never     
                     card-no: 0005 00000AFA
(1)  Henry W. Jones Jr. <henry.w.jones@uchicago.edu>

gpg> keytocard
Signature key ....: [none]
Encryption key....: [none]
Authentication key: 8474 2310 057F 1D64 056F  5903 F15B 3DEE 808D 3DB3

Please select where to store the key:
   (2) Encryption key
Your selection? 2

sec  4096R/14ED37BC  created: 2013-05-25  expires: 2016-05-24
ssb* 4096R/345D5ECB  created: 2013-05-25  expires: never     
                     card-no: 0005 00000AFA
ssb  4096R/808D3DB3  created: 2013-05-25  expires: never     
                     card-no: 0005 00000AFA
(1)  Henry W. Jones Jr. <henry.w.jones@uchicago.edu>
Finally we deselect the encryption key, so no subkey is selected anymore, and move the primary (signature/certification) key.
gpg> key 1

sec  4096R/14ED37BC  created: 2013-05-25  expires: 2016-05-24
ssb  4096R/345D5ECB  created: 2013-05-25  expires: never     
                     card-no: 0005 00000AFA
ssb  4096R/808D3DB3  created: 2013-05-25  expires: never     
                     card-no: 0005 00000AFA
(1)  Henry W. Jones Jr. <henry.w.jones@uchicago.edu>

gpg> keytocard
Really move the primary key? (y/N) y
Signature key ....: [none]
Encryption key....: 2050 EC35 2F6C 3EB0 223C  C551 279A 16D7 345D 5ECB
Authentication key: 8474 2310 057F 1D64 056F  5903 F15B 3DEE 808D 3DB3

Please select where to store the key:
   (1) Signature key
   (3) Authentication key
Your selection? 1

sec  4096R/14ED37BC  created: 2013-05-25  expires: 2016-05-24
                     card-no: 0005 00000AFA
ssb  4096R/345D5ECB  created: 2013-05-25  expires: never     
                     card-no: 0005 00000AFA
ssb  4096R/808D3DB3  created: 2013-05-25  expires: never     
                     card-no: 0005 00000AFA
(1)  Henry W. Jones Jr. <henry.w.jones@uchicago.edu>
Now we leave GnuPG, and it's important that we leave without saving. Otherwise, the secret key would be deleted on-disk and only remain on the card. (Of course, this may also be desired.)
gpg> quit
Save changes? (y/N) n
Quit without saving? (y/N) y
jones@pinacolada ~ $
Now, the card is basically ready for use. Let's have a look at its contents once more:
jones@pinacolada ~ $ gpg --card-status
Application ID ...: D276000124010200000500000AFA0000
Version ..........: 2.0
Manufacturer .....: ZeitControl
Serial number ....: 00000AFA
Name of cardholder: Henry W. Jones
Language prefs ...: en
Sex ..............: male
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: forced
Key attributes ...: 4096R 4096R 4096R
Max. PIN lengths .: 32 32 32
PIN retry counter : 3 0 3
Signature counter : 0
Signature key ....: 3C94 3AC9 713D E3E3 B3C6  BF73 3898 61DB 14ED 37BC
      created ....: 2013-05-25 21:30:56
Encryption key....: 2050 EC35 2F6C 3EB0 223C  C551 279A 16D7 345D 5ECB
      created ....: 2013-05-25 21:30:56
Authentication key: 8474 2310 057F 1D64 056F  5903 F15B 3DEE 808D 3DB3
      created ....: 2013-05-25 21:39:35
General key info..: pub  4096R/14ED37BC 2013-05-25 Henry W. Jones Jr. <henry.w.jones@uchicago.edu>
sec   4096R/14ED37BC  created: 2013-05-25  expires: 2016-05-24
ssb   4096R/345D5ECB  created: 2013-05-25  expires: 2016-05-24
ssb   4096R/808D3DB3  created: 2013-05-25  expires: 2016-05-24
jones@pinacolada ~ $
We'll discuss how to exactly use the card next time (but that's not really hard to figure out either :). Cheers!

Sunday, May 19, 2013

personal experience and opinion - kmail2 still not suitable for on-the-road use :(

I was very sceptic for a long time. Then, I slowly started to trust the kmail2/akonadi combination. I've been using it on my office desktop for a long time, and it works well and is very stable and fast there. (Might be related to the fact that the IMAP server is just across the lawn.) Some time ago, when I deemed things solid enough I even upgraded my laptop again, despite earlier problems. In Gentoo, we've been keeping kdepim-4.4 around all the time, and as you may have read, internal discussions led indeed to the decision to finally drop it some time ago.
What happened in the meantime?
1) One of the more annoying bugs mentioned in my last blog post was fixed with some help from Kevin Kofler. Seems like Debian stumbled into the same issue long ago.
2) I was on vacation. Which was fun, but mostly unrelated to the issue at hand. None of my Gentoo colleagues went ahead with the removal in the meantime. A lot of e-mails accumulated in my account.
3) Coming back, I was on the train with my laptop, sorting the mail. The train was full, the onboard WLAN slightly overstressed, the 4G network just about more reliable. Network comes and goes sometime with a tunnel, no problem. Or so I thought.
4) Half an hour before arriving back home I realized that silently a large part of the e-mails that I had (I though) moved (using kmail2-4.10.3 / akonadi-1.9.2) from one folder to another over ~3 hours had disappeared on one side, and not re-appeared on the other. Restarting kmail2 and akonadi did not help. A quick check of the webmail interface of my provider confirmed that also on the IMAP server the mails were gone in both folders. &%(/&%(&/$/&%$§&/
I wasn't happy. Luckily there were daily server backup snapshots, and after a few days delay I had all the documents back. Nevertheless... Now, I am considering what to do next. (Needless to say, in my opinion we should forget dropping kmail1 in Gentoo for now.) Options...
a) migrate the laptop back to kmail1, which is way more resistant to dropped connections and flaky internet connection - doable but takes a bit of time
b) install OfflineIMAP and Dovecot on the laptop, and let kmail2/akonadi access the localhost Dovecot server - probably the most elegant solution but for the fact that OfflineIMAP seems to have trouble mirroring our Novell Groupwise IMAP server
c) other e-mail client? I've heard good things about trojita...
Summarizing... no idea still how to go ahead, no good solution available. And I actually like the kdepim integration idea, so I'll never be the first one to completely migrate away from it! I am sincerely sorry for the sure fact that this post is disheartening to all the people who put a lot of effort into improving kmail2 and akonadi. It has become a huge lot better. However, I am just getting more and more convinced that the complexity of this combined system is too much to handle and that kmail should never have gone the akonadi way.

Saturday, May 18, 2013

Gentoo CUPS-1.6 status

We've had CUPS 1.6 in the Gentoo portage tree for a while now already. It has even been keyworded by most of the arches (hooray!), and from the bug reports quite some people use it. Sometime in the intermediate future we'll stabilize it, however until then quite some bugs still have to be resolved.
CUPS 1.6 brings changes. The move to Apple has messed up the project priorities, and backward compatibility was kicked out of the window with a bang. As I've already detailed in a short previous blog post, per se, CUPS 1.6 does not "talk" the printer browsing protocol of previous versions anymore but solely relies on zeroconf (which is implemented in Gentoo by net-dns/avahi). Some other features were dropped as well...
Luckily, CUPS was and is open source, and that the people at Apple removed the code from the main CUPS distribution did not mean that it was actually gone. In the end, all these feature just made their way from the main CUPS package to a new package net-print/cups-filters maintained at The Linux Foundation. There, the code is evolving fast, bugs are fixed and features are introduced. Even network browsing with the CUPS-1.5 protocol has been restored by now; cups-filters includes a daemon called cups-browsed which can generate print queues on the fly and accepts configuration directives similar to CUPS-1.5. As far as we in Gentoo (and any other Linux distribution) are concerned, we can get along without zeroconf just fine.
The main thing that is hindering CUPS-1.6 stabilization a the moment is that the CUPS website is down, kind of. Their server had a hardware failure, and since nearly a month (!!!) only minimal, static pages are up. In particular, what's missing is the CUPS bugtracker (no I won't sign up for an Apple ID to submit CUPS bugs) and access to the Subversion repository of the source. (Remind me to git-svn clone the code history as soon as it's back and push it to gitorious.)
So... feel free to try out CUPS-1.6, testing and submitting bugs for sure helps. However, it may take some time to get these fixed...

Sunday, May 12, 2013

Lab::Measurement 3.11 released

Lab::Measurement 3.11 has been uploaded to CPAN. This is a minor maintenance release, with small bug fixes in the voltage source handling (gate protect and sweep functionality) and the Yokogawa drivers (output voltage range settings).

Thursday, April 18, 2013

kdepim-4.4 (kmail1) in Gentoo - unsupported, dying, dead

Bitrot is accumulating, and while we've tried to keep kdpim-4.4 running in Gentoo as long as possible, the time is slowly coming to say goodbye. In effect this is triggered by annoying problems like these:
There are probably many more such bugs around, where incompatibilities between kdepim-4.4 and kdepimlibs of more recent releases occur or other software updates have led to problems. Slowly it's getting painful, and definitely more painful than running a recent kdepim-4.10 (which has in my opinion improved quite a lot over the last major releases).
Please be prepared for the following steps:
  • end of april 2013, all kdepim-4.4 packages in the Gentoo portage tree will be package.masked 
  • end of may 2013, all kdepim-4.4 packages in the Gentoo portage tree will be removed
  • afterwards, we will finally be able to simplify the eclasses a lot by removing the special handling
We still have the kdepim-4.7 upgrade guide around, and it also applies to the upgrade from kdepim-4.4 to any later version. Feel free to improve it or suggest improvements.

R.I.P. kmail1.

Sunday, April 14, 2013

NVIDIA 300 series Linux drivers - worst functionality regression ever

For a long time, I've been extraordinarily happy with both NVIDIA graphics hardware and the vendor-supplied binary drivers. Functionality, stability, speed. However, things are changing and I'm frustrated. Let me tell you why.

Part of my job is to do teaching and presentations. I have a trusty thinkpad with a VGA output which can in principle supply about every projector with a decent signal. Most of these projectors do not display the native 1920x1200 resolution of the built-in display. This means, if you configure the second display to clone the first, you will end up seeing only part of the screen. In the past, I solved this by using nvidia-settings and setting the display to a lower resolution supported by the projector (nvidia-settings told me which ones I could use) and then let it clone things. Not so elegant, but everything worked fine- and this amount of fiddling is still something that can be done in the front of a seminar room while someone is introducing you and the audience gets impatient.

Now consider my surprise when suddenly after a driver upgrade the built-in display was completely glued to the native resolution. Only setting possible - 1920x1200. The first time I saw that I was completely clueless what to do; starting the talk took a bit longer than expected. A simple, but completely crazy solution exists; disable the built-in display and only enable the projector output. Then your X session is displayed there and resized accordingly. You'll have to look at the silver screen while talking, but that's not such a problem. A bigger pain actually is that you may have to leave the podium in a hurry and then have no video output at all...

Now, googling. Obviously a lot of other people have the same problem as well. Hacks like this one just don't work, I've ended up with nice random screen distortions. Here's a thread on the nvidia devtalk forum from where I can quote, "The way it works now is more "correct" than the old behavior, but what the user sees is that the old way worked and the new does not." It seems like now nVidia expects that each application handles any mode switching internally. My usecase does not even exist from their point of view. Here's another thread, and in general users are not happy about it.

Finally, I found this link where the following reply is given: "The driver supports all of the scaling features that older drivers did, it's just that nvidia-settings hasn't yet been updated to make it easy to configure those scaling modes from the GUI." Just great.

Gentlemen, this is a serious annoyance. Please fix it. Soon. Not everyone is willing to read up on xrandr command line options and fiddle with ViewPortIn, ViewPortOut, MetaModes and other technical stuff. Especially while the audience is waiting.

Saturday, April 13, 2013

OpenPGP smartcards and Gentoo - part 1: hardware

Gnupg is an excellent tool for encryption and signing, however, while breaking encryption or forging signatures of large key size is likely somewhere between painful and impossible even for agencies on significant budget, all this is always only as safe as your private key. Let's insert the obvious semi-relevant xkcd reference here, but someone hacking your computer, installing a keylogger and grabbing the key file is more likely. While there are no preventive measures that work for all conceivable attacks, you can at least make things as hard as possible. Be smart, use a smartcard. You'll get a number of additional bonuses on the way. I'm writing up here my personal experiences, as a kind of guide. Also, I am picking a compromise between ultra-security and convenience. Please do not complain if you find guides on the web on how to do things "better".

The smart cards

Obviously, you will need one or more OpenPGP-compatible smart cards and a reader device. I ordered my cards from kernel concepts since that shop is referred in the GnuPG smartcard howto. These are the cards developed by g10code, which is Werner Koch's company (he is the principal author of GnuPG). The website says "2048bit RSA capable", the text printed on the card says "3072bit RSA capable", but at least the currently sold cards support 4096bit RSA keys just fine. (You will need at least app-crypt/gnupg-2.0.19-r2 for encryption keys bigger than 3072bit, see this link and this portage commit.)

The readers

While the GnuPG smartcard howto provides a list of supported reader devices, that list (and indeed the whole document) is a bit stale. The best source of information that I found was the page on the Debian Wiki; Yutaka Niibe, who edits that page regularly, is also one of the code contributors to the smartcard part of GnuPG. In general there are two types of readers, those with a stand-alone pinpad and those without. The extra pinpad takes care that for normal operations like signing and encryption the pin for unlocking the keys is never entering the computer itself- so without tampering with the reader hardware it is impossible pretty hard to sniff it. I bought a SCM SPG532 reader, one of the devices supported ever first by GnuPG, however it's not produced anymore and you may have to resort to newer models soon.

Drivers and software

Now, you'll want to activate the USE flag "smartcard" and maybe "pkcs11", and rebuild app-crypt/gnupg. Afterwards, you may want to log out and back in again, since you may need the gpg-agent from the new emerge.
Several different standards for card reader access exist. One particular is the USB standard for integrated circuit card interface devices, short CCID; the driver for that one is directly built into GnuPG, and the SCM SPG532 is such a device. Another set of drivers is provided by sys-apps/pcsc-lite; that will be used by GnuPG if the built-in stuff fails, but requires a daemon to be running (pcscd, just add it to the default runlevel and start it). The page on the Debian Wiki also lists the required drivers.
These drivers do not need much (or any) configuration, but should work in principle out of the box. Testing is easy, plug in the reader, insert a card, and issue the command
gpg --card-status
If it works, you should see a message about (among other things) manufacturer and serial number of your card. Otherwise, you'll just get an uninformative error. The first thing to check is then (especially for CCID) if the device permissions are OK; just repeat above test as root. If you can now see your card, you know you have permission trouble.
Fiddling with the device file permissions was a serious pain, since all online docs are hopelessly outdated. Please forget about the files linked in the GnuPG smartcard howto. (One cannot be found anymore, the other does not work alone and tries to do things in unnecessarily complicated ways.) At some point in time I just gave up on things like user groups and told udev to hardwire the device to my user account: I created the following file into /etc/udev/rules.d/gnupg-ccid.rules:
ACTION=="add", SUBSYSTEM=="usb", ENV{PRODUCT}=="4e6/e003/*", OWNER:="huettel", MODE:="600"
ACTION=="add", SUBSYSTEM=="usb", ENV{PRODUCT}=="4e6/5115/*", OWNER:="huettel", MODE:="600"
With similar settings it should in principle be possible to solve all the permission problems. (You may want to change the USB id's and the OWNER for your needs.) Then, a quick
udevadm control --reload-rules
followed by unplugging and re-plugging the reader. Now you should be able to check the contents of your card.
If you still have problems, check the following: for accessing the cards, GnuPG starts a background process, the smart card daemon (scdaemon). scdaemon tends to hang every now and then after removing a card. Just kill it (you need SIGKILL)
killall -9 scdaemon
and try again accessing the card afterwards; the daemon is re-started by gnupg. A lot of improvements in smart card handling are scheduled for gnupg-2.0.20; I hope this will be fixed as well.
Here's how a successful card status command looks like on a blank card:
huettel@pinacolada ~ $ gpg --card-status
Application ID ...: D276000124010200000500000AFA0000
Version ..........: 2.0
Manufacturer .....: ZeitControl
Serial number ....: 00000AFA
Name of cardholder: [not set]
Language prefs ...: de
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: forced
Key attributes ...: 2048R 2048R 2048R
Max. PIN lengths .: 32 32 32
PIN retry counter : 3 0 3
Signature counter : 0
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]
General key info..: [none]
huettel@pinacolada ~ $

That's it for now, part 2 will be about setting up the basic card data and gnupg functions, then we'll eventually proceed to ssh and pam...

Edit: You can find part 2 here.

Saturday, February 9, 2013

Gentoo 10.0 to 13.0 profiles upgrade & server profiles going away

We've generated a new set of profiles for Gentoo installation. These are now called 13.0 instead of 10.0, e.g., "default/linux/amd64/10.0/desktop" becomes "default/linux/amd64/13.0/desktop".
Everyone should upgrade as soon as possible. This brings (nearly) no user-visible changes. Some new files have been added to the profile directories that make it possible for the developers to do more fine-grained use flag masking (see PMS-5 for the details), and this formally requires a new profile tree with EAPI=5 (and a recent portage version, but anything since sys-apps/portage-2.1.11.31 should work and anything since sys-apps/portage-2.1.11.50 should be perfect).
Since the 10.0 profiles will be deprecated immediately and removed in a year, emerge will suggest a replacement on every run. I strongly suggest you just follow that recommendation.
One additional change has been added to the package: the "server" profiles will be removed; they do not exist in the 13.0 tree anymore. If you have used a server profile so far, you should migrate to its parent, i.e. from "default/linux/amd64/10.0/server" to "default/linux/amd64/13.0". This may change the default value of some use-flags (the setting in "server" was USE="-perl -python snmp truetype xml"), so you may want to check the setting of these flags after switching profile, but otherwise nothing happens.

Friday, February 8, 2013

KDE 4.10.0 plasma-desktop crashes and qt frustrations

While on my machine KDE 4.10.0 runs perfectly fine, unfortunately a lot of Gentoo users see immediate crashes of plasma-desktop - which makes the graphical desktop environment completely unuseable. We know more or less what happened in the meantime, just not how to properly fix it...
The problem:
  • plasma-desktop uses a new code path in 4.10, which triggers a Qt bug leading to immediate SIGSEGV. 
  • The Qt bug only becomes fatal for some compiler options, and only on 64bit systems (amd64).
  • The Qt bug may be a fundamental architectural problem that needs proper thought.
The links:
The bugfixing situation:
  • Reverting the commit to plasma-workspace that introduced the problem makes the crash go away, but plasma-desktop starts hogging 100% CPU after a while. (This is done in plasma-workspace-4.10.0-r1 as a stopgap measure.) Kinda makes sense since the commit was there to fix a problem - now we hit the original problem.
  • The bug seems not to occur if Qt is compiled with CFLAGS="-Os". Cause unknown. 
  • David E. Narváez aka dmaggot wrote a patch for Qt that fixes this particular codepath but likely does not solve the global problem.
  • So far comments from Qt upstream indicate that this is in their opinion not the right way to fix the problem.
  • Our Gentoo Qt team understandably only wants to apply a patch if it has been accepted upstream.
Right now, the only option we (as Gentoo KDE team) have is wait for someone to pick up the phone. Either from KDE (to properly use the old codepath or provide some alternative), or from Qt (to fix the bug or apply a workaround)...

Sorry & stay tuned.

Thursday, January 24, 2013

PhD position available: A carbon nanotube as a moving weak link

The combination of localized states within carbon nanotubes and superconducting contact materials leads to a manifold of fascinating physical phenomena and is a very active area of current research. An additional bonus is that the carbon nanotube can be suspended, i.e. the quantum dot between the contacts forms a nanomechanical system. In this research field a PhD position is immediately available; the working title of the project is "A carbon nanotube as a moving weak link".

You will develop and fabricate chip structures combining various superconductor contact materials with ultra-clean, as-grown carbon nanotubes. Together with your colleagues, you will optimize material, chip geometry, nanotube growth process, and measurement electronics. Measurements will take place in one of our ultra-low temperature setups.

Good knowledge of superconductivity is required. Certainly helpful is knowledge of semiconductor nanostructures and low temperature physics, as well as basic familiarity with Linux. The starting salary is 1/2 TV-L E13.

Interested? Contact Andreas K. Hüttel (e-mail: andreas.huettel@ur.de, web: http://www.physik.uni-r.de/forschung/huettel/ ) for more information!

PhD position available: Gigahertz nanomechanics with carbon nanotubes

We are currently working on integrating carbon nanotube nanomechanical systems into superconducting radio-frequency electronics. Overall objective is the detection and control of nanomechanical motion towards its quantum limit. In this project, we've got a PhD position with project working title "Gigahertz nanomechanics with carbon nanotubes" available immediately.

You will design and fabricate superconducting on-chip structures suitable as both carbon nanotube contact electrodes and gigahertz circuit elements. In addition, you will build up and use - together with your colleagues - two ultra-low temperature measurement setups to conduct cutting-edge measurements.

Good knowledge of electrodynamics and possibly superconductivity are required. Certainly helpful is low temperature physics, some sort of programming experience, as well as basic familiarity with Linux. The starting salary is 1/2 TV-L E13.

Interested? Contact Andreas K. Hüttel (e-mail: andreas.huettel@ur.de, web: http://www.physik.uni-r.de/forschung/huettel/ ) for more information!

Tuesday, January 1, 2013

JAP accepted: Transversal Magnetic Anisotropy in Nanoscale PdNi-Strips

Right at the start the new year 2013 brings the pleasant news that our manuscript "Transversal Magnetic Anisotropy in Nanoscale PdNi-Strips" has found its way into Journal of Applied Physics. The background of this work is - once again - spin injection and spin-dependent transport in carbon nanotubes. (To be more precise, the manuscript resulted from our ongoing SFB 689 project.) Control of the contact magnetization is the first step for all the experiments. Some time ago we picked Pd0.3Ni0.7 as contact material since the palladium generates only a low resistance between nanotube and its leads. The behaviour of the contact strips fabricated from this alloy turned out to be rather complex, though, and this manuscript summarizes our results on their magnetic properties.
Three methods are used to obtain data - SQUID magnetization measurements of a large ensemble of lithographically identical strips, anisotropic magnetoresistance measurements of single strips, and magnetic force microscopy of the resulting domain pattern. All measurements are consistent with the rather non-intuitive result that the magnetically easy axis is perpendicular to the geometrically long strip axis. We can explain this by maneto-elastic coupling, i.e., stress imprinted during fabrication of the strips leads to preferential alignment of the magnetic moments orthogonal to the strip direction.

"Transversal Magnetic Anisotropy in Nanoscale PdNi-Strips"
D. Steininger, A. K. Hüttel, M. Ziola, M. Kiessling, M. Sperl, G. Bayreuther, and Ch. Strunk
Journal of Applied Physics 113, 034303 (2013); arXiv:1208.2163 (PDF[*])
[*] Copyright American Institute of Physics. This article may be downloaded for personal use only. Any other use requires prior permission of the author and the American Institute of Physics.