ring0 » blog

I2C VGA Adapter

tags: debian, debian, debian, i2c, i2c, i2c, vga, vga, vga, hdmi, hdmi, hdmi, dvi, dvi, dvi, hardware, hardware, hardware, electronics, electronics, electronics, logic level converter, logic level converter, logic level converter, linux, linux, linux2012-07-07 10:41 by lwi

For one of my projects I'm making heavy use of I²C devices. For development it would be nice to connect them to my notebook and develop and debug the sourcecode natively.

Luckily I remembered that all common display connection standards (VGA, HDMI, DVI) have an I²C control channel. In the linux kernel these pins are exported as I²C device by the graphic card driver. For example my intel driver exports 8 I²C devices.

So the only hardware needed to use an I²C device on my notebook is a cheap VGA cable. After cutting it in half we have two I²C adapters. I decided to create one cable for 5V I²C devices. This one is already done after cutting the cable in half. I soldered a jumper wire connector on the four needed wires and removed the others.

Driving 3.3V I²C sensors with 5V might destroy them, so some more work is needed for the second cable. For the logic parts (SDA and SCL) Sparkfun's Logic Level Converter can be used (I can be bought for ca. 1.50€). It does need a 3.3V reference voltage, though. An external power supply can be avoided by using a low dropout voltage regulator, e.g. a LM1117-3.3 (ca. 1.00€).

You can see how easy the setup is by viewing the schematics.

On the software side it is enough to load the i2c-dev kernel module, which exports I²C devices to userland as /dev/i2c-<number>. Then one can try to find the correct device by using i2cdetect -l to find the correct device.

Documentation how to work with the device can be found in the kernel documentation.

How to install XenServer 6 + RAID1 remotely

tags: XenServer, XenServer, XenServer, RAID1, RAID1, RAID1, unattended, unattended, unattended2012-02-15 16:25 by lwi

Recently we decided to switch the ISP and therefore a new server needed to be set up. Since Xen runs great we figured to stick with it. Unfortunately not many Linux distributions support Xen so we ended up with XenServer Free from Citrix.

Our new ISP of course does not offer an automated installation for XenServer but quite a lot of other options (even an outdated OpenBSD). The first approach to sneak in XenServer was by installing some random Linux distribution, mounting the second hard drive and using KVM to install it there. Afterwards a chainloader entry in Grub would save the day. At least in theory since it failed in practise. With all hope lost on that approach surfing the web to look for suitable solutions seemed the right way to continue in this endeavour.

Luckily someone had the exact the same problem and came up with a clever solution (german): Launching the unattended installer via Grub. Infact it worked like a charm.

Full of joy I launched the management console and was almost creating VMs when I noticed there was one further thing I almost missed: software raid. We had it before and wanted to keep it that way. It turns out Citrix does not recommand using software RAID. They dont just say that, they also make sure you are unable to configure your system to run software RAID. The website I found also had a chapter for creating a software RAID, but I was not able to see any partitions from the rescue system. A quick web search revealed that one had to disable GUID Partition Tables first. The provided approach however was based on a live setup and not an unattended one. In order to overcome that challenge the installation image install.img had to be modified since it contained the python script we want to modify. After unpacking one needs to edit opt/xensource/installer/constants.py and change GPT_SUPPORT = True to False. The newly created image did the job and XenServer was installed using an old partition table.

After all the desired setup was achieved and everyone happy not knowing further adventures were waiting for them (such as OpenBSD HVM unter XenServer, missing Grub configs or mastering a mail/xmpp migration without downtime).

EOF

Debian: Japanese (にほんご) support

tags: debian, debian, debian, input, input, input, latex, latex, latex, japanese, japanese, japanese2011-11-15 02:11 by lwi

I'm currently participate in a Japanese course at my university. Therefore I want to be able to input Japanese characters on my notebook.

To do this it's enough to simply install the package 'ibus-anthy', 'ibus-gtk' and 'ibus-gtk3'. Afterwards you can switch between normal input mode and japanese input mode via the keystroke combination [CTRL] + [Space].

But I'm a vim user and found it anoying to remember leaving the Japanese mode before leaving the Edit mode (otherwise vim's Normal mode won't work correctly). I want vim to take care of that for me, so I added a small function to my vimrc:

" source: http://d.hatena.ne.jp/fuenor/20110705/1309866529 au InsertLeave * call PyIBusDisable() function! PyIBusDisable() python << EOF import ibus bus = ibus.Bus() ic = ibus.InputContext(bus, bus.current_input_contxt()) ic.disable() EOF endfunction

Last but not least I want LaTeX support. For this two more packages are needed: 'latex-cjk-japanese' and 'latex-cjk-japanese-wadalab'. After installing the packages there's an UTF-8 example file showing how it works in /usr/share/doc/latex-cjk-common/examples/CJKutf8.tex.gz. If you hit any errors it may help to remove ~/.texmf-var. Check Debian Bug #406701 to get more details.

convergence notary

tags: convergence, convergence, convergence, security, security, security, ssl, ssl, ssl2011-09-07 22:35 by lwi

ring0.de is now hosting a convergence notary on notary.ring0.de You can find the corresponding notary file here

For more information on convergence watch the talk on ssl and authenticity on youtube and visit the website of convergence