pages tagged workaroundrohieb.namehttps://rohieb.name/blag/tag/workaround/rohieb.nameikiwiki2019-05-05T21:56:21ZGoogle Earth and IPv6 DNS lookupshttps://rohieb.name/blag/post/google-earth-and-ipv6-dns-lookups/rohieb
CC-BY-SA 3.0
2013-09-19T05:04:01Z2011-01-22T12:02:00Z
<p>Apparently the combination of a WLAN router that blocks IPv6 DNS queries
of type <code>AAAA</code> (in my case, it was a Siemens S1621-Z220-A sold as <a href="http://www.alice-wiki.de/Alice_Modem_1121_WLAN">Alice
Modem 1121 WLAN</a>) and the current version of Google Earth for Linux (I am
using 5.1.3533.1731 from <a href="http://www.medibuntu.org/">Medibuntu</a>) do not work well together. The
problem is that the router simply throws away <code>AAAA</code> queries (or
generally, any type it does not know), so the DNS query times out.
However, Google Earth does not seem to fall back to IPv4 queries (type
<code>A</code>) in this case, and shows a message about network connectivity errors.
I don’t know if it’s Google Earth’s fault or if the underlying eglibc
resolver of my Linux system does something wrong, anyhow there is a
fairly well-commented <a href="https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/417757">bug report</a> on Launchpad for Ubuntu Karmic and
Lucid which explains the issue.</p>
<p>Anyway, I got rid of the problem by manually configuring a nameserver on
my local machine (for example the nameserver(s) of your internet
provider, or the ones of OpenDNS), and not using the WLAN router as a
resolver. NetworkManager allows you to do this by editing a connection
and choosing “Automatic DHCP (Addresses only)” on the IPv4 register tab;
or you can write the settings directly to your <code>/etc/resolv.conf</code> (here
for the OpenDNS servers):</p>
<pre><code>nameserver 208.67.222.222
nameserver 208.67.220.220
</code></pre>
SSH key authentication with encrypted home directorieshttps://rohieb.name/blag/post/ssh-key-authentication-with-encrypted-home-directories/rohieb
CC-BY-SA 3.0
2019-05-05T21:56:21Z2010-10-08T22:00:00Z
<p>Yesterday, I ran into an interesting problem: I tried to set up <a href="http://www.openbsd.org/cgi-bin/man.cgi?query=ssh&sektion=1#AUTHENTICATION">SSH
public key authentication</a> between two of my machines, <code>c3po</code> and
<code>r2d2</code>, so I could log in from <code>rohieb@r2d2</code> to <code>rohieb@c3po</code> without a
passphrase. However, everytime I tried to login to <code>c3po</code>, I was
prompted to enter the passwort for <code>rohieb@c3po</code>, and the debug output
mentioned something that the key could not be verified. More
astonishing, when I established a second SSH connection while the first
was still running, I was <em>not</em> prompted for a password, and debug output
said that key authentication had been sucessful. I googled a bit, and
after a while got to <a href="https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/362427/comments/12">this comment</a> on Launchpad, mentioning problems
when the user on the remote machine had its home directory encrypted
through ecryptfs – which was the case for me. Of course, since ecryptfs
only encrypts the user’s home <em>after</em> he has been authenticated, the SSH
daemon cannot read his <code>~/.ssh/authorized_keys</code> at the first time, and
falls back to password authentication.</p>
<p>The Launchpad comment proposes to first unmount the ecryptfs filesystem,
then store <code>~/.ssh/authorized_keys</code> unencrypted, and then mount the
encrypted home again (<strong>note</strong> that no program should be running that
could try to access your home directory):</p>
<pre><code>$ ecryptfs-umount-private
$ cd $HOME
$ chmod 700 .
$ mkdir -m 700 .ssh
$ chmod 500 .
$ echo $YOUR_REAL_PUBLIC_KEY > .ssh/authorized_keys
$ ecryptfs-mount-private
</code></pre>
<p>This works indeed, but has the drawback that key authentication only
works for the <em>first</em> login, because ecryptfs hides the unencrypted
files when it mounts the encrypted directory on login; and you had to
synchronize the encrypted and the unencrypted version of
<code>authorized_keys</code> everytime you add a new key. To circumvent that, I
simply moved the file to <code>/etc/ssh/authorized_keys/rohieb</code> (with the
file only readable and writable by me, and <code>/etc/ssh/authorized_keys</code>
writeable for all users) and adjusting <code>/etc/ssh/sshd_config</code>
appropriately:</p>
<pre><code>$ sudo vi /etc/ssh/sshd_config # or use your favorite editor instead of vi
[... some lines ...]
AuthorizedKeysFile /etc/ssh/authorized_keys/%u
[... some more lines ...]
$ sudo /etc/init.d/ssh restart
</code></pre>
<h2 id="update">Update</h2>
<p>There is yet a better approach instead, which doesn’t need the SSHd
config to be edited at all:</p>
<ol>
<li>login to the user on the remote machine</li>
<li>create <code>/home/.ecryptfs/$USER/.ssh</code> and put your <code>authorized_hosts</code> there</li>
<li><p>symlink your encrypted version there:</p>
<pre><code>$ ln -s /home/.ecryptfs/$USER/.ssh/authorized_hosts ~/.ssh/authorized_hosts
</code></pre></li>
<li><p>symlink your unencrypted version there (as above, <strong>make sure</strong> no
process wants to write to your home directory in the meantime):</p>
<pre><code>$ ecryptf-umount-private
$ mkdir ~/.ssh
$ ln -s /home/.ecryptfs/$USER/.ssh/authorized_hosts ~/.ssh/authorized_hosts
$ ecryptfs-mount-private
</code></pre></li>
</ol>
<p>The paths are for Ubuntu 9.10 (Karmic Koala) and later. On other
systems, you might want to replace <code>/home/.ecryptfs</code> with
<code>/var/lib/ecryptfs</code>.</p>
ZSNES on AMD64 Ubuntuhttps://rohieb.name/blag/post/zsnes-on-amd64-ubuntu/rohieb
CC-BY-SA 3.0
2019-05-05T21:56:21Z2010-10-05T22:00:00Z
<p><strong>[ Update, 2013-10:</strong> This post post is not up to date anymore. On newer
Debians (since 7.0/wheezy) and Ubuntus (at least since 12.04, Precise Pangolin),
you should be able to install zsnes out of the box: <code>sudo apt-get install
zsnes:i386</code>. For details see the MultiArch documentation for
<a href="https://wiki.debian.org/Multiarch/">Debian</a> and <a href="https://help.ubuntu.com/community/MultiArch">Ubuntu</a>. <strong>]</strong></p>
<p>Before I bought my current hardware, I was working on a 32-bit-based
system, and I really appreciated ZSNES as an SNES emulator. But
unfortunately, my new hardware was an AMD64 system, and there is
currently no ZSNES package for 64-bit Ubuntu or Debian <img src="https://rohieb.name/smileys/sad.png" alt=":(" /> So I decided
to google a bit about the issue, but it took me until now (a year later)
to get ZSNES finally working on my machine. The problem is, if you build
ZSNES on a 64-bit machine, all the application does is segfault at
start, and if you <a href="http://board.zsnes.com/phpBB3/viewtopic.php?p=118067&sid=dd9a2a54d9178eb5009c33586aea703c#p118067">try to compile for 32-bit systems</a>, you get errors
about missing 32-bit libs (in particular, configure does not find a
suitable <code>libsdl</code>). Instead, if you just take the binary which was
compiled on a 32-bit system, and install the <code>ia32-libs</code> package,
everything seems to work—at least I was able to play a few levels of
Super Mario World succesfully <img src="https://rohieb.name/smileys/smile.png" alt=":-)" /> </p>
<p>So here was my idea: take the 32-bit package from the Ubuntu repository,
and just change the Architecture control field, and by this fool dpkg :P
And as it turned out, this idea worked great. You can get the Debian
package here if you want, it <em>should</em> work for Ubuntu Karmic and Lucid,
as well as for Debian testing (<strong>but</strong> I only tested it on Lucid, so
there is no warranty here—but I’m happy to hear if it works :-)):</p>
<ul>
<li><a href="http://rohieb.name/stuff/zsnes_1.510-2.2ubuntu3~ppa1_amd64.deb">zsnes_1.510-2.2ubuntu3~ppa1_amd64.deb</a></li>
<li>SHA1: <code>716bbd37267b477ef02961a7727212619309b83f</code></li>
<li>MD5: <code>452ea5230ad17df1dee649ab4cc6c8c0</code></li>
</ul>
<h2 id="howtoreproduceit">How to Reproduce It</h2>
<p>For the curious people reading here, here is what I actually did:</p>
<ol>
<li><code>wget http://archive.ubuntu.com/ubuntu/pool/universe/z/zsnes/zsnes_1.510-2.2ubuntu3_i386.deb</code></li>
<li><code>ar x zsnes_1.510-2.2ubuntu3_i386.deb</code></li>
<li><code>tar xzf data.tar.gz</code></li>
<li><p>Edit <code>usr/share/applications/zsnes.desktop</code> and added <code>-ad sdl</code> to the
<code>Exec:</code> field, otherwise it would just segfault on the first run:</p>
<pre><code>Exec=zsnes -ad sdl
</code></pre></li>
<li><p>Edit <code>usr/share/doc/zsnes/changelog.Debian.gz</code> and added a new
changelog entry for the version (just copy one of the previous
entries and adapt it)</p></li>
<li><code>tar xzf control.tar.gz</code></li>
<li><p>Edit the <code>control</code> file, changed the <code>Version:</code> and <code>Architecture:</code>
field to <code>amd64</code>, added the <code>ia32-libs</code> dependency, and set myself as
maintainer:</p>
<pre><code>Package: zsnes
Version: 1.510-2.2ubuntu3~ppa1
Architecture: amd64
Maintainer: Roland Hieber <foobar@example.org>
Installed-Size: 4160
Depends: ia32-libs, libao2 (>= 0.8.8), libc6 (>= 2.4), libgcc1 (>= 1:4.1.1),
libgl1-mesa-glx | libgl1, libpng12-0 (>= 1.2.13-4),
libsdl1.2debian (>= 1.2.10-1), libstdc++6 (>= 4.1.1), zlib1g (>= 1:1.2.2.3)
[...]
</code></pre></li>
<li><p>Change the <code>md5sums</code> file for the right values for
<code>usr/share/applications/zsnes.desktop</code> and
<code>usr/share/doc/zsnes/changelog.Debian.gz</code> (I used the <code>md5sum</code>
command and copy-pasted it)</p></li>
<li><code>tar czf control.tar.gz control md5sums postrm postinst</code></li>
<li><code>tar czf data.tar.gz usr/</code></li>
<li><code>ar r zsnes_1.510-2.2ubuntu3~ppa1_amd64.deb debian-binary
control.tar.gz data.tar.gz</code></li>
</ol>
<p>I’m afraid that I can’t put the package into <a href="https://launchpad.net/~rohieb/+archive/ppa">my PPA</a>, Launchpad only
accepts source packages for uploads, and builds the binary packages
itself, both for i386 and AMD64. This approach can not be used here,
since we needed the i386 binary for AMD64.</p>