21st century digital boy
   I don't know how to live, but I've got a lot of toys

Allgemein 0 Kommentare »

Allgemein 0 Kommentare »

linux 0 Kommentare »

Lets face the truth. Desktop Linux has made an incredible progress in the last few years. It still gives you all the freedom, happiness and elegance it inherited from it’s UNIX-foundation – and it tries hard to compete with the Windows Plug-And-Play mentality.

The standard user shouldn’t need to do complicated things on the console. Basic things should just work. Especially Ubuntu did great, they really improved many GUI aspects of the GNOME-desktop. Most modern machines run and work just “out of the box” with a fresh Ubuntu install. BUT there are still these little annoyances and things that don’t work as expected. I will collect my personal annoyances with Ubuntu 9.10 “Karmic Koala” in this post and add solutions, if I find them.

Annoyance #1
Logs are spammed with messages about CPU temperature

This one is an ugly one. It started for me with Karmic. /var/log/kern.log and /var/log/syslog got spammed with millions of messages from the kernel stating things like:

CPU0: Temperature above threshold, cpu clock throttled (total events = 208[ 8973.550089] CPU0: Temperature/speed normal

CPU0: Temperat cpu clock throttled (total events = 2080190)
This was a real problem, because about 100 messages per second were written to the logs, making them hard to read for other purposes. Syslog archiving them pushed my CPU to 100% and they filled up my root partition very quickly. This behaviour seems to originate from a kernel bug that should be fixed anytime soon. There is an Ubuntu Bug-Report on the problem already: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/453444. There is no real fix for it, as this is a kernel bug, but there is a workaround that fixed the odd behaviour of my system. I just disabled the logging of lines, that contain the bogus information:

• Create a file /etc/rsyslog.d/10-temperature.conf
• Paste the following code into it::msg,contains,”Temperature/speed normal” ~
  :msg,contains,”Temperature above threshold” ~

• Save it
• Do an sudo restart rsyslog to make the new rule active.

Annoyance #2
CPU Frequency Scaling Monitor didn’t remember my password

There is a very useful little applet for the Gnome panel, that allows you to change the speed of your CPU while working. As I am using a notebook most of the time, this thingy came in quiet handy for me. Because changing of the CPU policy requires root-privileges, you had to enter your password once with old Ubuntu versions. After that you were able to check a checkbox and Ubuntu remembered your policy. Things changed in Karmic. With the new policykit2 environment, there was no possibility anymore to remember the password. I had to reenter it every time i wanted to change my CPU policy. I found out, that I could set the permisson right in the config files for policykit2:

• Create a file  /var/lib/polkit-1/localauthority/50-local.d/gnome-cpufreq.pkla
• Paste the following code into it (be sure to replace YOURUSERNAME with your username):[Allow users to set the CPU frequency]
  Identity=unix-group:YOURUSERNAME
  Action=org.gnome.cpufreqselector
  ResultAny=no
  ResultInactive=no
  ResultActive=yes

• Save it
• There is no password needed anymore for changing CPU policies

Annoyance #3
Streamtuner couldn’t load the Shoutcast streamlist anymore

This started with Intrepid or so. Shoutcast changed the hostname of it’s streamlist-servers. The old hostname seems to be hardcoded into Streamtuner, so it couldn’t get the streamlist anymore. This was  unconvenient  for me, because i got used to tune into my favourite internet radio stations (like Lemixx Paris France) with Streamtuner. There seems to be no effort to fix this in the Ubuntu package, as the bug is now several months old already. I fixed it by adding the right IP to /etc/hosts.

• Open up /etc/hosts with a text editor
• Add the following line to it:205.188.234.120 www.shoutcast.com

• Save it
• Streamtuner can access Shoutcast streams again

Annoyance #4
USB Startup Disk Creator is unable to create an USB Startup Disk

Ubuntu brings it’s own tool to clone itself onto an USB flashdrive. You basicly get a fully working Ubuntu Installation on your flashdrive. A very useful thingy to carry around if you want to connect to the internet from untrusted machines or if you want to fix a brokeen down computer. So far so good, it didn’t work. When you start the USB Startup Disk Creator from Ubuntus menu, the tool starts but is unable to format or write to partitions on your flashdrive. The solution is surprisingly simple: It needs to be run as root to make it work:

• Open up a terminal
• Enter the following command:
  sudo usb-creator-gtk
• Create and enjoy your flashdrive
  

Annoyance #5
Couldn’t click on any web link in Pokerstars with wine

Poker is one of my hobbies and the guys from Pokerstars did a great job on making it a good experience on Linux with wine too. There are a few downgrades though. When clicking on links in the Pokerstars software, no webbrowser opened up in Gnome. You need to edit the registry to fix that.

• Run wine regedit to open the registry editor
• Navigate to  HKEY_CLASSES_ROOT\http\shell\open\command
• Add a “%1″ after -nohome in that registry key
• Links work now in Pokerstars

Annoyance #6
Couldn’t make Pokerstars tables fullscreen with wine

Another Pokerstars problem. Scaling tables didn’t work well. There was no way to make a table fullscreen. There is a way to fix that, implemented espcially for wine users by Pokerstars.

• Open up the file user.ini in your Pokerstars directory ($HOME/.wine/Program….)
• Add a line with  f5redrawtable=1 to the file
• Save it
• Tables are redrawn now after resizing them when you press F5
  

To be continued…

linux 0 Kommentare »

SSH must be my favourite piece of software ever. It’s free, it gives you freedom, it’s simple to use yet powerful in the things it can do. It helps you to encrypt and secure your communication. It can do this in an universal way and for nearly every usage case. In this post, I want to show you 6 things you can do with SSH without too much hassle. SSH can do more than just serve as an encrypted remote session. Try the following examples for yourself and explore the power of the Secure Shell.

Thingy #1 – A secure remote shell

OK, this is the most obvious thing you can do with SSH and i bet most of you have already done it: Connect to a remote machine via a SSH-secured connection and type on it’s console to administer it.

This is very simple:

ssh user@box_B

This will connect you to Box B as user “user”. After having entered your password, you will be able to use BOX B’s console.

Sometimes you don’t want to connect to the remote machine for an interactive session, because you just want to run a single command on the remote machine. In that case you can just do a

ssh user@box_B command

This will connect to Box B as “user”, run “command”, show you “command”’s output and disconnect.

Thingy #2 – Copy files between your boxes

Great, we can administer a remote machine with SSH but we can also move data between machines in an encrypted and secure way. It basicly works like the standard “cp” command, but it has got a different name: “scp”

scp /home/me/a_file.txt user@box_B:/home/me/

This will copy the local file “/home/me/a_file.txt” on our Box A to “/home/me/a_file.txt” on Box B.

It will work vice versa as well:

scp user@box_B:/home/me/b_file.txt /home/me

This would get the file “/home/me/b_file.txt” and would put in into our home dir on box A.

Because “scp” works like “cp” wildcards are allowed as well:

scp /var/log/* user@box_B:/home/me/logsbackup

This would copy all of the log files from our Box A to “/home/me/logsbackup” on Box B.

Thingy #3 – Mount a remote directory into your local file system

Sometimes it’s not enough to simply copy one or more files from one machine to another. Mounting a remote directrory into your local filesystem becomes super useful, when you want to work on the remote files with local programs. A good example for this would be working on a remote website. You can simply mount the web-directory from the remote server into your local filesystem and use all your fancy HTML-editors and image-programs on the remote files as if they were on your local harddrive. That’s where “sshfs” comes in handy. The tool isn’t installed by default in most distributions but you should be able to find it in your repository. On Debian based systems just install it with:

apt-get install sshfs

After having installed sshfs you can start using it:

mkdir /mnt/b_data

sshfs user@box_B:/b_data /mnt/b_data

This mounts the directory “/b_data” from box B into “/mnt/b_data” on your local file system. Now you can work on your remote files with local tools. When you are done, you can unmount the directory with:

fusermount -u /mnt/b_data

If the unmount fails, check if you have still open files in the directory or if you are still in that directory in some shell or Nautilus/Konqueror window.

Thingy #4 – Surf the Web uncensored and anonymously from “critical” locations

Corporate policies, fascist governments, internet cafés and other “unfriendly” rules, institutions and places can give you a hard time, when you want to access the web in a secure and private way. Firewalls and proxies may block your favourite sites, log the sites you have visited, perform man in the middle attacks or can just give you a bad feeling. SSH is the solution for these problems. It offers you the possibility to use it as a web-proxy. You simply connect to your good old trusted box B and surf through the encrypted connection.

(Local Browser <-> Local SSH Proxy <-> SSH <-> Box B <-> Website)

Now nobody on your unfriendly local LAN can block or spy on your surfing session.
Sounds good? Great! It’s even simple to setup. SSH offers the “-D” option to provide a SOCKS proxy on the local machine:

ssh -D 1234 user@box_B

You’ll have a proxy listening on localhost port 1234. Now you just have to setup your webbrowser to use the “SOCKS proxy” on localhost port 1234 and all your surfing will go through Box B. You can check if it worked by visiting a website that shows your IP. http://www.whatismyip.com is a site that would work. If that site shows Box B’s IP-address instead of your local one, you setup everything correctly. A portable webbrowser on your USB-pendrive like  Portable Firefox would make things even more cozy.

Thingy #5 – Encrypt the data traffic of your favourite local application or access services in LAN’s you couldn’t reach otherwise with SSH-tunnels

OK, we encrypted remote admin-sessions, copied files securely and even surfed the web in a private way. But SSH can do more. You can encrypt the traffic of every application that uses the TCP-protocol with SSH tunnels. Like with our SOCKS-proxy, we can tunnel other data through ssh, for example the traffic of our e-mail client. Lets say you want to pickup your e-mail while being in a “critical” environment. Bad corporations / governments / script kiddies could read your email and even worse could sniff your e-mail password. SSH helps. The syntax for tunnels in SSH might puzzle your brain at first sight, but it’s not too hard:

ssh -L local_port:target_host:target_port user@box_B

for example

ssh -L 10000:pop3.mailprovider.com:110 user@box_B

OK, lets see what happened here. We told ssh to create a tunnel with a local (-L) endpoint at port “10000″. Everything that is put into our local endpoint goes first encrypted to our Box B and after that to “pop3.mailprovider.com” on port 110 (which is POP3). You relay all data that goes into our local endpoint in an encrypted way via Box B to your E-Mail provider. In this example you would set the POP-account in your e-mail client to “localhost” port “10000″. It doesn’t have to be e-mail. Any other application that uses a protocol utilizing TCP works as well. For example IRC, FTP, HTTP, IMAP, you name it…

in case you are running your own server-service on Box B, “target host” can be Box B itself of course:

ssh -L 10000:127.0.0.1:110 user@box_B

Target host in this example is “127.0.0.1″ because it’s the target from Box B’s point of view. “127.0.0.1″ seen from Box B sure is Box B itself.

Tunneling can be useful to secure your services or to connect to services inside BOX B’s network. Lets say BOX B is in an intranet that has an interesting webserver on IP “192.168.0.77″ and you are unable to access that server from the outside. You just tunnel your way to BOX B and let BOX B forward you to the webserver:

ssh -L 10000:192.168.0.77:80 user@box_B

Now typing “http://127.0.0.1:10000″ into your local webbrowser will show you the homepage of the intranets webserver.

Thingy #6 – A tunnel the other way around

OK, this could have been part of “Thingy #5″ but to make things more clear i made an extra point for it. If you understood #5 this should be no problem for you. Here, you open up a “remote” endpoint on Box B. Everything that goes in there is relayed encrypted to Box A (the one you are using at the moment) and after that to the target host.

ssh -R remote_port:target_host:target_port user@box_B

for example

ssh -R 10000:pop3.mailprovider.com:110 user@box_B

An e-mail client would set “box_B” and port “10000″ as the POP3 server. BOX B would relay the traffic to BOX A through SSH. BOX A would relay the traffic to “pop3.mailprovider.com” port “110″.

Useful commandline options for SSH

-c “Compress”

The “-c” option in SSH compresses all traffic with gzip before sending it to the remote host. This increases the speed greatly with uncompressed data-types. It’s very useful for copying large text-files over SSH or for surfing the web with the “-D” option. In general “-c” never hurts, it just puts a little more pressure onto your CPU.

ssh -c -D 1234 user@box_B

-g “Grant Access”

The “-g” option allows other hosts to connect to your local tunnel endpoints. If you don’t use “-g” in combination with a tunnel, only your own localhost (Box A in the examples) may use the tunnel.

ssh -L -g 10000:127.0.0.1:110 user@box_B

-p “Port”

The “-p” option is needed, if the SSH-server you want to connect to doesn’t run on the default port “22″

ssh -p 22000 user@box_b

-v “Verbose”

Add this option if you want to dive deeper into SSH. You will see many technical information while connecting to a remote host.

Further reading

I tried to keep this article as simple as possible to make it usable. There is a lot more to know about SSH. If you are looking for a more comprehensive read i suggest you check out these docs:

The SSH man page

The SSH RFC

Wikipedia on SSH

SSH – The Definitive Guide by O’Reilly

Allgemein 0 Kommentare »

Allgemein 1 Kommentar »

Just for the kicks, i tried to connect 2 Asterisk servers thru a SSH tunnel to place encrypted calls via IAX2 from BOX1 to BOX2. It worked, but the sound quality is ugly and the FIFO-nature of converting UDP-traffic into TCP-traffic gave some strange results. But after all I learned a lot doing it….

What we need:

- 2 Asterisk Boxes

- root on BOX2

- ssh

- socat

What I did:

Connect both boxes with a SSH port-forwarding to get the calls thru the internet. Convert the IAX2 UDP-traffic coming from Box1s Asterisk into TCP with socat, because SSH doesn’t support UDP tunneling. Send the TCP data thru the tunnel. Pick it up at the other side with socat and convert it back to UDP. Feed the UDP data into the target asterisk.

How I did it:

BOX1:

context to feed an outbound call into our socat converter:

exten => 3,1,Dial(IAX2/user:pass@127.0.0.1:10000/1)

setting up socat:

socat udp4-listen:10000,reuseaddr,fork tcp:127.0.0.1:10001

setting up our ssh tunnel:

ssh -L 10001:127.0.0.1:10000 root@box2

---

Box2:

Setting up socat to pick up the TCP-stream from the tunnel and pass it to asterisk:

socat tcp4-listen:10000,reuseaddr,fork UDP:127.0.0.1:4569

iax.conf:

[general]
bindport = 4569
bindaddr = 0.0.0.0
disallow=all
allow=ulaw
allow=alaw

[box1]
type=peer
username=user
secret=pass
auth=plaintext
context=iax-tunnel
peercontext=iax-tunnel
qualify=yes
trunk=yes

The iax-tunnel context just playing a beep:
; IAX testing
[iax-tunnel]
exten => 1,1,Answer()
exten => 1,2,Playback(beep)
exten => 1,3,Hangup()

Enjoy…

Die Welt heute 0 Kommentare »

Es gab einmal einen magischen Wasserhahn in einer Welt ohne Meere, Flüsse, Seen und Regen. Der Hahn war an keine Wasserleitung angeschlossen und trotzdem sprudelte er ständig fidel und glücklich. Das frische Wasser floß wie aus dem Nichts heraus und versorgte die Durstigen. Doch er war auch gierig. Er verschenkte sein Wasser nicht an die Durstigen sondern verlieh es nur. Die Durstigen mußten ihm das Wasser später zurückgeben. Außerdem verlangte er bei der Rückgabe immer etwas mehr Wasser als Leihgebühr. Da der magische Wasserhahn der einzige Wasserhahn der Welt war, war leider niemals genug Wasser da. Auch das zusätzliche Wasser, das ja als Gebühr zusätzlich zurückgegeben werden mußte, konnte man nur aus dem Wasserhahn beschaffen. So kam es, dass immer mehr Leute Wasserschulden hatten, sich immer mehr Leute gegenseitig Wasser stahlen und immer mehr Leute verdursteten.

Die Welt heute 0 Kommentare »

Gefunden bei den Diskussionen über den DOW-JONES bei Google Finance, der heute ein neues historisches Tief erreicht hat.

An American businessman was at the pier of a small coastal Mexican
village when a small boat with just one fisherman docked. Inside the
small boat were several large yellowfin tuna.

The American complimented the Mexican on the quality of his fish and
asked how long it took to catch them. The Mexican replied, “only a
little while.” The American then asked why didn’t he stay out longer
and catch more fish? The Mexican said he had enough to support his
family’s immediate needs.

The American then asked, “But what do you do with the rest of your
time?” The Mexican fisherman said, “I sleep late, fish a little, play
with my children, take siesta with my wife, Maria, stroll into the
village each evening where I sip wine and play guitar with my amigos.
I have a full and busy life, senor.”

The American scoffed, “I am a Harvard MBA and could help you. You
should spend more time fishing and with the proceeds buy a bigger
boat, with the proceeds from the bigger boat you could buy several
boats, eventually you would have a fleet of fishing boats. Instead of
selling your catch to a middleman you would sell directly to the
processor, eventually opening your own cannery. You would control the
product, processing and distribution. You would need to leave this
small coastal fishing village and move to Mexico City, then LA and
eventually NYC where you will run your expanding enterprise.”

The Mexican fisherman asked, “But senor, how long will this all take?”

To which the American replied, “15 or 20 years.”

“But what then, senor?”

The American laughed and said, “that’s the best part. When the time is
right you would announce an IPO and sell your company stock to the
public and become very rich, you would make millions.”

“Millions, senor? Then what?”

The American said, “Then you would retire. Move to a small coastal
village where you would sleep late, fish a little, play with your
kids, take siesta with your wife, stroll to the village in the
evenings where you could sip wine and play your guitar with your
amigos.”

Allgemein 0 Kommentare »

Allgemein 0 Kommentare »

GAME OVER – Insert Coin(s) – Other Game(s)