2012-11-18

Ingress

Posted in Computers, Gaming, Personal, PlanetDebian at 21:11 UTC (+0000) by sven

As some may have noticed, Google launched something that is unusual for the company: A game. A mobile alternate reality game, to be precise. See allthingsd article for a bit more information. In my opinion this game is most interesting to people who are mildly interested in geo-caching. You spend most of the gaming time either looking for the right “portals” (geo-location that is an interesting place for one reason or another, many located at sculptures, murals or (more scarcely) interesting local businesses), or trying to solve the puzzles that appear in the game itself or on http://www.nianticproject.com/. I was one of the beta testers and really enjoy the game, especially in areas with more players.

As the game is most fun when people coordinate a bit, I started a google group for the munich area for one of the two teams (the enlightenment), but I will only let people enter that group who can be verified to be on that team.

On a side note: I still have a few invites to the game left, so if you are interested, please leave a comment and enter your gmail.com email address (you need a Google account to play anyway) while doing so. I will send out invites in the order I received the requests (which I admit might not always be the same in which they were submitted. First come first serve and no guarantee to get an invitation though. Your email address you enter when commenting isn’t shown to anyone and I don’t share them with anyone but the game (and thus Google).

EDIT: So short time went past, but I already ran out of invites (note that I didn’t approve comments that really only were like “please send me an invite”, but still did sent one out). Feel free to still ask me for an invite, I will send some out as I get new ones, but this might take anything between a few days and some weeks.

PS: For the lucky ones who got invites: You don’t strictly need to do the training offered when you start the game for the first time, but I strongly encourage you to do so.
PPS: I’m opening my group to any enlightened players in Germany. I will share some useful information about some game details there in the near future (nothing company confidential of course, just information anyone can gather in the game or from the published information).

EDIT: As noted before, I don’t have any more invites to give away. As I still get like 4 requests for invites per day, and now have more than 30 unfulfilled requests pending (with no new invites to give in sight), I’m now disabling comments.

Disclaimer: I work for Google since a few months ago, but this post solely represents my own opinions and hasn’t been endorsed by Google in any way.

2012-08-14

UK going completely crazy on cryptography law.

Posted in Computers, IT-Security, Personal, PlanetDebian, Random links at 16:46 UTC (+0000) by sven

It seems that the UK government recently passed a law that makes it illegal to be unable to decrypt what the law enforcement entities think is encrypted:

From http://falkvinge.net/2012/07/12/in-the-uk-you-will-go-to-jail-not-just-for-encryption-but-for-astronomical-noise-too/:

But it’s worse than that. Much worse. You’re not going to be sent to jail for refusal to give up encryption keys. You’re going to be sent to jail for an inability to unlock something that the police think is encrypted. Yes, this is where the hairs rise on our arms: if you have a recorded file with radio noise from the local telescope that you use for generation of random numbers, and the police asks you to produce the decryption key to show them the three documents inside the encrypted container that your radio noise looks like, you will be sent to jail for up to five years for your inability to produce the imagined documents.

This is just insane.

Edit: The law was created several years ago, but the blog post somehow made me think it was more recent.

2012-04-20

Ex-TSA lead on air traffic security woes

Posted in Personal, PlanetDebian, Random links at 11:26 UTC (+0000) by sven

I came across this article today and really found it noteworthy:

http://online.wsj.com/article/SB10001424052702303815404577335783535660546.html

Original title: Why Airport Security Is Broken—And How To Fix It

Kip Hawley, TSA head from July 2005 to January 2009, writes about how the current TSA procedures came into being, how he failed at some of his goals (to make the checks less annoying) during his involvement and what could be done to fix procedures. I especially liked these points:

By the time of my arrival, the agency was focused almost entirely on finding prohibited items. Constant positive reinforcement on finding items like lighters had turned our checkpoint operations into an Easter-egg hunt. When we ran a test, putting dummy bomb components near lighters in bags at checkpoints, officers caught the lighters, not the bomb parts.

(also quoted on LWN.net)

And this one:

The public wants the airport experience to be predictable, hassle-free and airtight and for it to keep us 100% safe. But 100% safety is unattainable.

I think the most important thing he mentioned is the fifth and last of his action items to improve both experience by passengers and security:

5. Randomize security: Predictability is deadly. Banned-item lists, rigid protocols—if terrorists know what to expect at the airport, they have a greater chance of evading our system.

He got it nailed there, in my opinion: If security measures are predictable, the loopholes in it are also predictable, so you basically give attackers a handbook of what to avoid when planning the attack. This, by the way isn’t limited to physical security and air travel, but also applies to IT security (though it is much easier to hide your IT security measures and make them somewhat unpredictable that way, then it is to do so with physical security and passenger screening on airports.

2011-10-13

Strange MySQL (5.0) issue with authentication

Posted in Computers, PlanetDebian at 07:47 UTC (+0000) by sven

Dear Lazyweb….

I ran into a very strange issue with MySQL authentication. The initial situation is as follows:
Two MySQL servers, let’s name them a0.my.do.main and a1.my.do.main. Their my.cnf configuration is identical except for the server_id (equals 1 on a0 and 2 on a1).
Since I wanted to set up a master< ->master replication, I created a user “repl@%.my.do.main” on a0, then shut down the mysql server on both hosts, copied over the mysql database on the filesystem layer (i.e. rsync of the data directory), then started mysql on both hosts again. So far, so good, both servers came up nicely, and local (unix socket) login as a root user worked fine as expected. However:

Logging in via TCP socket only works from a1 (to both a0 and a1). Logging in via TCP socket from a0 doesn’t work to either host. I also created a test user “sven”@”%.my.do.main” (I also tried with @”%”) which has all privileges.
Here is what the commands output:

sven@a0 ~ > mysql -u sven -ptestpass -h a0.my.do.main
ERROR 1045 (28000): Access denied for user 'sven'@'a0.my.do.main' (using password: YES)
sven@a0 ~ > mysql -u sven -ptestpass -h a1.my.do.main
ERROR 1045 (28000): Access denied for user 'sven'@'a0.my.do.main' (using password: YES)

sven@a1 ~ > mysql -u sven -ptestpass -h a0.my.do.main
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 32
Server version: 5.0.77-log Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> Bye
sven@a1 ~ > mysql -u sven -ptestpass -h a1.my.do.main
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 24
Server version: 5.0.77-log Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql>

All packages on both machines are up to date (CentOS5 with all updates available). The server variables shown with “show variables” also seem identical (except for the hostname and the server id). Besides, it looks more like a client problem to me than a server problem.

Last datapoint: If I define the mysql user “sven” with an explicit host (a0.my.do.main and a1.my.do.main) instead of a wildcard, everything works nicely, from and to both hosts.

So, dear lazyweb: Does anyone have an idea what might be causing this issue?

Update:

Due to some comments, let me add a few points of information:

  1. flush hosts doesn’t help. Host resolution looks OK, according to documentation, the hostname in the error message is what the server things is right, not what the client specified, and that documentation seems to be consistent with my experiences.
  2. The “db” and “user” tables look as expected. And I’m quite sure they are not the issue here, as I can connect from other hosts that match the host pattern.
  3. There is no ~/.my.cnf on either host
  4. Copying the database files on the filesystem layer is one of the documented ways of initializing the database on the slave for replication. Anyway, I had the same issue when trying to set up the database on the slave by loading a dump.
  5. DNS looks fine, both forward and reverse mappings, both servers use the same DNS server.
  6. IPv6 is not involved, it is disabled on these servers

Thanks for the hint at serverfault.com, I will try that if I don’t get sufficient info here.

Update 2

Another strange data point:
When I disable the (non-privileged) anonymous access user in the mysql.user table (i.e. drop the rows with user=”"), everything works as expected from both servers. However, why does it work from one host (client) to both DBs if the anonymous access is allowed (with no privileges except for being able to see that the test and mysql databases exist), but not from the other host (client)? It really looks like an issue on the client side, but I still don’t get what exactly goes wrong.

2011-04-06

Strange iptables error with kernels >= 2.6.32 – solved

Posted in Computers, IT-Security, PlanetDebian at 12:43 UTC (+0000) by sven

Alright. If you ever come into the same situation I was in and need a newer kernel (2.6.32 or up, perhaps also 2.6.31) on some system with old iptables package (versions below 1.4.0 I think, 1.3.5 in my case: CentOS5/RHEL5), you might get this helpful error message when using the iprange module in your iptables rules:

iptables: Unknown error 18446744073709551615

Or even more helpful, if you use iptables-restore to load your rules, you will get an error in the line containing the COMMIT statement (iptables-restore: line X failed).

The reason for this is that the netfilter guys have removed an interface to the iprange module in kernel version 2.6.31 or 2.6.32 (see my bug report at #711 of the netfilter bugzilla).

Just posting this so it might hopefully help others if they get into the same situation.

2009-07-07

RHEL/CentOS bi-arch problems

Posted in Computers, Personal, PlanetDebian, rant at 10:57 UTC (+0000) by sven

Oh well, I think RHELs support for multiple architectures installed at the same time (and thus the same support in CentOS) really needs some rethinking.
While the following might not be able to happen with the default installation media (I didn’t verify), it still can happen if you run your own mirrors and actually need both architectures listed in your yum repositories…
Anyway, what happened today is just one example of how the multi-arch support caused problems for me:

On a Xen Dom0, I needed to apply a kernel upgrade (from 2.6.18-92something to 2.6.18-128something) and as a result, a reboot. At this point you should memorize that the old kernel worked quite fine and all I did was a yum update followed by a reboot. A procedure I did on quite a number of Dom0 machines in the past weeks.

Well, the reboot this time didn’t work, the kernel halted after printing:
request_module: runaway loop modprobe binfmt-464c

Well, reboot again, select old kernel, systems boots fine….

What happened was that both the x86_64 and i686 versions of the old kernel was installed, so yum update updated both, probably first the x86_64 version, then the i686 version (but I didn’t check). Well, while for the old kernel, grub booted the x86_64 kernel with the x86_64 initrd, for the new kernel it tried to boot the i686 kernel with the x86_64 initrd. (verified by unpacking the initrd and the vmlinuz kernel image and running file on the binaries therein)

Now the big question is: How could the stupid yum/rpm/postinstall script system end up doing this? It is supposed to warn about conflicts if two packages ship different versions of the same file AFAICT, but there is no way the i686 and x86_64 versions of /boot/vmlinuz* could be identical. So there should have been a warning about this. And after that, how come the mkinitrd tool doesn’t even try to check wether the kernel architecture and that of the initrd binaries match? It happily packed 64bit binaries and 64bit kernel modules(sic!) when run against a 32bit kernel….

OK, enough of my frustration….
I really wished I had to maintain not RHEL/CentOS machines but Debian (based distro) machines here at work. Unfortunately, that won’t happen for various reasons…

While the bi-arch support in RHEL/CentOS is helpful in many ways, RPM and the way bi-arch works on these distros caused almost as much trouble to me already as it helped avoid.

2009-06-22

Another link collection 2009-06-22

Posted in Computers, Personal, PlanetDebian at 08:45 UTC (+0000) by sven

I seem not to post anything but links lately, but anyway,

Eddy Petrișor has a post about transitioning from lilo to grub2 (considering usage of LVM).

Romain Beauxis writes about what he dislikes about git (or probably most distributes version control systems) when it comes to team-maintained packages, to which Martin F. Krafft responded with an interesting post that puts some aspects of distributed versioning into a more balanced perspective then Romain had. After all though, I agree that there are uses to DVCSs which make sense (like being able to commit while not having any sort of connection to the “central” repository). However, I still think that relatively small “projects” like maintaining Debian packages have more to gain from the central repository then from the ability to commit while not connected. That is, at least as long as upstream doesn’t use a DVCS already, in which case there are other benefits from using the same DVCS, like easily pulling in upstream changes.

David Welton posted about a small script that swaps virtual desktops (please note that you will need to enable javascript to actually see the script).

While not technologically new to me, this post by David Pashley about copying files with netcat was a nice summarization of how to do it (and why it is sometime preferable over scp or rsync, plain or over ssh). One of the comments refers to mbuffer, which might also prove useful if you need really high speeds (>200MByte/s) or want some more advanced buffering options. The pv tool (alias Pipe Viewer) might be of interest to meter the throughput.

Phil Hands writes about getting an USB stick to boot (certain) ISO images with the help of grub4dos.

2009-05-18

Link collection 2009/05/18

Posted in Computers, Personal, PlanetDebian, Uncategorized at 14:06 UTC (+0000) by sven

  • Marco d’Itri about adding support for yet-unknown-to-kernel-drivers devices. More specifically: how to make udev tell ftdi-sio that it should accept a certain VendorID/ProductID combination in addition to previously supported ones.
  • Thomer M. Gil about ICMPTX, a combination made from proxy and server that tunnels IP through ICMP. Nice thing if you need a connection from some NATed and heavily firewalled location I guess. (Thanks go to Runa Sandvik for finding this.)
  • Non-technical in a way, but still a nice link: Image of the Shuttle transiting the sun, thanks to Pablo Lorenzzoni for this link.
  • Another post by Marco d’Itri that explains how to install Debian on a SheevaPlug. Not that I need this info now, but it might come in handy some day.

That’s it for now, will update the post if I find more interesting links in the next few days.

2009-03-31

Link collection 2009/03

Posted in Computers, PlanetDebian, Random links at 14:22 UTC (+0000) by sven

Well, I normally despise of thinks like this link collection, but I thought I might add it anyway, since these are useful links for me and if I don’t post them here, I’m likely to forget where to find them in the near future:

  1. Sean Finney has a nice post about storing the list of parameters a (shell) script got in a way that it can be restored later. Quite handy if your script walks through the arguments parsing them (and consuming them while doing so) but you want to be able to display them in a helpful way if the parsing fails at some point.
  2. A while ago, Ingo Jürgensmann had a post that helps retrieving files from lost+found after a filesystem check, provided that you run his helper script on a regular basis. The same approach can also be used if you have a backup of all files, but lost the sorting work you did after the backup was done. This is possible because running the script can be done more often then you would normally do backups.
  3. He also has a small post about mtr oddities when IPv6 comes into play
  4. Adeodato Simó wrote about databases and when timestamps that store the timezone information really are more useful then timestamps that don’t.
  5. Adeodato also has a short post on using ssh as a socks proxy, which can be quite handy if you are behind a firewall.

Update: Fixed link to Ingo’s file retrieval from lost+found article. Thanks to Patrick Schoenfeld who pointed me at the wrong link.
Also thanks to the anonymous poster who found an alternative way to store and (in a way) restore commandline parameters. The solution doesn’t work in an as general way as that by Sean Finney et al., but it is much shorter and therefore interesting for where it can be used (when you control how commandline parameters are processed). See comments on this post for details.

2009-03-26

Apache SSL oddity

Posted in Computers, PlanetDebian at 16:07 UTC (+0000) by sven

If you ever have the problem described below, you have to realize that Apache HTTPD is selecting the SSL certificate (and/or key) not based on you VirtualHost definition, but based on the ServerName in the current context. This means that you have two virtual hosts with the same ServerName, but on two different IPs, and are wondering why the wrong key (and/or certificate) is used, it might be because of this. Assume we have the following (simplified) configuration:


<VirtualHost a.b.c.d:443>
ServerName a.b.c.d
SSLCertificateFile /etc/ssl/certs/a.b.c.d_443.pem
SSLCertificateKeyFile /etc/ssl/certs/a.b.c.d_443-key.pem
</VirtualHost>
<VirtualHost a.b.c.d:444>
ServerName a.b.c.d
SSLCertificateFile /etc/ssl/certs/a.b.c.d_444.pem
SSLCertificateKeyFile /etc/ssl/certs/a.b.c.d_444-key.pem
</VirtualHost>

(note: This happened to me when wanting to open a SSL server for subversion on a host that also had Apache run as a reverse/application proxy for some specific application that managed its own CA)

Both VirtualHosts will use the very same certificate and key (as far as I was able to tell, but at least the same key), in my case that of the specific application (which was(is?), in its way, broken regarding SSL).

This might as well be a bug or a design decision (AKA feature), I don’t know. However the “workaround” that worked for us was to change one of the server names to something else (since it seems it is unused anyway, unless the apache decides to generate a self-refering URL, which it certainly won’t do for the reverse/application proxy part).

Update: Fixed formatting on configuration sample to make it clear this is not about name-based virtual hosts.

UPDATE: Finally, I also found a soluti^Wwork-around to the problem: Append the port number to the ServerName supplied, like this:

<VirtualHost a.b.c:443>
Servername a.b.c:443
...
</VirtualHost>

The additional port doesn’t harm browsers (or other applications) accessing the virtual host, but for Apache, these are now clearly different and as such use different SSL parameters (as far as specified).

« Previous entries Next Page » Next Page »