You are here

Debian

Upgrading request-tracker 3.6 to 3.8 on Squeeze

Today I had some problems with request-tracker in version 3.6 on Squeeze, coming from Lenny: although I was able to write mails to the ticket system and was able to receive mails from it when creating new tickets, I was unable to send replies to tickets to the requestor. Instead of dealing around with 3.6 I tried to upgrade to rt 3.8. Basically the upgrade went fairly well, except for my PostgreSQL database. It depends on postgresql-client which is a virtual package for postgresql-client-8.4. As learned lately postgresql-8.4 is somewhat uninstallable on Squeeze at the moment.

So, I needed to make some sort of backport for rt3.8-db-postgresql_3.8.8-3_all.deb, which was quite easy. Instead of

Depends: ${misc:Depends}, libdbd-pg-perl (>= 1.41),
 postgresql-client (>= 7.4)
Suggests: postgresql | postgresql (>= 7.4)

I changed the lines to this: 

Depends: ${misc:Depends}, libdbd-pg-perl (>= 1.41),
 postgresql-client-8.3 (>= 7.4)
Suggests: postgresql-8.3 | postgresql (>= 7.4)

Now I was able to install request-tracker3.8 successfully, upgrade the database and enjoy the new shiny version of rt. I'm unsure whether I needed to edit/save the Respond scrips as well to make the mail sending again or not. But that shouldn't be big show blocker either.

Anyway, I think I'll write a bug report for rt 3.8 tomorrow... It's always fun to find yet another bug when a new release is upcoming... :-)

UPDATE:
Bug report filed as #596926

Kategorie: 
 

Upgrading PostgreSQL 8.3 to 8.4 on Squeeze

Currently upgrading Debian Lenny to Squeeze is not that easy, because PostgreSQL 8.3 from Lenny is getting to be removed while PostgreSQL 8.4 won't be installed because of some dependency issues: 

# apt-get install postgresql-8.4 postgresql-8.4-postgis postgresql-contrib-8.4
Reading package lists... Done
Building dependency tree      
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies.
  postgresql-8.4: Depends: libgssapi-krb5-2 (>= 1.8+dfsg) but it is not going to be installed
                  Depends: libkrb5-3 (>= 1.6.dfsg.2) but it is not going to be installed
                  Depends: libpq5 (>= 8.4~0cvs20090328) but 8.3.11-0lenny1 is to be installed
                  Depends: postgresql-client-8.4 but it is not going to be installed
  postgresql-contrib-8.4: Depends: libpq5 (>= 8.4~0cvs20090328) but 8.3.11-0lenny1 is to be installed
E: Broken packages

Well, yes, I know Squeeze is still Testing and such, but as libkrb5-3 and libgssapi-krb5-2 are required but seem to be unavailable, I wonder when this issue will get solved? There seems no bug report for postgresql-8.4, libkrb5-3 or libgssapi-krb5-2. Is that for a reason? Or is the reason for uninstallable postgresql-8.4 something else?

UPDATE:

# apt-cache policy postgresql-8.4
postgresql-8.4:
  Installed: (none)
  Candidate: 8.4.4-2
  Version table:
     8.4.4-2 0
        500 http://ftp.de.debian.org squeeze/main Packages

# apt-cache policy libkrb5-3
libkrb5-3:
  Installed: 1.8.3+dfsg~beta1-1
  Candidate: 1.8.3+dfsg~beta1-1
  Version table:
 *** 1.8.3+dfsg~beta1-1 0
        500 http://ftp.de.debian.org/debian/ squeeze/main amd64 Packages
        100 /var/lib/dpkg/status
 

UPDATE 2:
This issue seems to be caused by #596678. Thanks Rhonda & Martin!

Kategorie: 
 

Solved: Problems with IPv6 and Bridging/Xen

Since I ordered a new dedicated rootserver, I had problems with my IPv6 setup. Thanks to Niggurath@#debian.de/ircnet and his tips, I finally found the reason for all the mess when I migrated from my old rootserver with Lenny to the new one running Squeeze.

The problem was that in /etc/sysctl.conf there was the following setting on the old server: 

net.ipv6.conf.all.forwarding=1

Due to a issue in Lenny, this setting had basically no effect on the old server. Sysctl.conf was called before the IPv6 interface went up, so this setting failed or never got active. Meanwhile in Squeeze IPv6 seems to be enabled at an earlier point in the boot process and the forwarding setting will succeed. This in return resulted in my not working IPv6 setup.

When I disable the line in sysctl.conf everything works just fine: the domU honors the Router Advertisments of radvd again and everything is fine again. Sometimes the solution is so simple, you can't find it yourself. :-) 

 

Kategorie: 
 

Problems with IPv6 and Bridging/Xen

I've been using IPv6 on my rootserver for some time now. Last week I migrated to a new rootserver and copied my domU/VM instances over to the new hardware. Everything is working fine so far - except IPv6. The network setup is the same as on the old server: the external interface is eth0. The domU/VMs are hooked up to a bridge, called xenbr0. There's another bridge for internal communication: xenbr1.

The dom0/Xen host itself seems reachable via IPv6. The /48 subnet is provided by Sixxs and is using a static 6-to-4 tunnel. But the VMs are not reliable reachable, although it is setup in the same way as it was on the old server and where it was working like a charme.

The configs of the hosts are these: 

Xen dom0
config old server new server
System Debian Etch
2.6.18-6-xen-amd64
linux-image-2.6.18-6-xen-amd64
linux-modules-2.6.18-6-xen-amd64
xen-hypervisor-3.0.3-1-amd64
xen-ioemu-3.0.3-1
xen-linux-system-2.6.18-6-xen-amd64
xen-tools
xen-utils-3.0.3-1
xen-utils-common

Debian Squeeze
2.6.32-5-xen-amd64
libxenstore3.0
linux-image-2.6.32-5-xen-amd64
xen-hypervisor-4.0-amd64
xen-linux-system-2.6.32-5-xen-amd64
xen-tools
xen-utils-4.0
xen-utils-common
xenstore-utils
xenwatch

/etc/sysctl.conf net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
net.ipv4.conf.default.proxy_arp=1
net.ipv4.ip_forward=1
net.ipv4.ip_syncookies=1
net.ipv4.conf.all.rp_filter=1
net.ipv4.icmp_echo_ignore_broadcasts=1
/etc/xen/xend-config.sxp (network-script network-route)
(vif-script     vif-bridge)
(dom0-min-mem 196)
(dom0-cpus 0)
(vif-script vif-bridge)
(network-script network-route)
(dom0-min-mem 196)
(enable-dom0-ballooning yes)
(total_available_memory 0)
(dom0-cpus 2)
(vncpasswd '')
/etc/network/interfaces

# device: eth0
auto eth0
iface eth0 inet static
  address 85.10.209.30
  broadcast 85.10.209.31
  netmask 255.255.255.224
  up route add -net 85.10.209.0 netmask 255.255.255.224 gw 85.10.209.1 eth0 || true
  up ip route add 85.10.209.0/28 via 85.10.209.1 src 85.10.209.30 || true
  up route add default gw 85.10.209.1 || true

auto xenbr0
iface xenbr0 inet static
        address 85.10.209.30
        netmask 255.255.255.224
        pre-up brctl addbr xenbr0
        up route add -net 78.47.85.144/29 dev xenbr0  || true
        up ip -6 r a 2001:6f8:90e:145::1/64 via 2001:6f8:90e:1:216:3eff:fe55:197c dev xenbr0 ||true
        up ip -6 r a 2001:6f8:90e:146::1/64 via 2001:6f8:90e:1:216:3eff:fe2f:481d dev xenbr0 || true
        up ip -6 r a 2001:6f8:90e:147::1/64 via 2001:6f8:90e:1:216:3eff:fe60:68be dev xenbr0 || true
        up ip -6 r a 2001:6f8:90e:a100::1/64 via 2001:6f8:90e:1:216:3eff:fe70:be dev xenbr0 || true

auto xenbr1
iface xenbr1 inet static
        address 192.168.x.254
        netmask 255.255.255.0
        pre-up brctl addbr xenbr1
        # some internal IPv4 routing


auto sixxs
iface sixxs inet6 v4tunnel
        address 2001:6f8:900:c6e::2
        netmask 64
        endpoint 212.224.0.188
        local 85.10.209.30
        ttl 64
        up ip link set mtu 1280 dev sixxs || true
        up ip route add default via 2001:6f8:900:c6e::1 dev sixxs || true
        up ip -6 route flush dev eth0 || true
        up ip -6 r a 2001:6f8:90e::/48 dev xenbr0 || true
        down ip -6 route flush dev sixxs || true

 # device: eth0
auto  eth0
iface eth0 inet static
  address   178.63.83.84
  broadcast 178.63.83.127
  netmask   255.255.255.192
  gateway   178.63.83.65
  # default route to access subnet
  up route add -net 178.63.83.64 netmask 255.255.255.192 gw 178.63.83.65 eth0

auto xenbr0
iface xenbr0 inet static
        address 178.63.83.84
        netmask 255.255.255.192
        pre-up brctl addbr xenbr0
        up route add -host 178.63.83.104 dev xenbr0  || true
        up route add -host 178.63.83.105 dev xenbr0  || true
        up route add -host 178.63.83.106 dev xenbr0  || true
        up ip route add 178.63.123.128/26 dev xenbr0 || true
        up ip -6 r a 2001:6f8:90e:145::1/64 via 2001:6f8:90e:1:216:3eff:fe89:6c31 dev xenbr0 ||true
        up ip -6 r a 2001:6f8:90e:146::1/64 via 2001:6f8:90e:1:216:3eff:fedc:af5f dev xenbr0 || true
        up ip -6 r a 2001:6f8:90e:147::1/64 via 2001:6f8:90e:1:216:3eff:fe08:8f40 dev xenbr0 || true
        up ip -6 r a 2001:6f8:90e:a100::1/64 via 2001:6f8:90e:1:216:3eff:fe70:be dev xenbr0 || true


auto xenbr1
iface xenbr1 inet static
        address 192.168.x.254
        netmask 255.255.255.0
        pre-up brctl addbr xenbr1
        # some internal IPv4 routing

     
auto sixxs
iface sixxs inet6 v4tunnel
        address 2001:6f8:900:c6e::2
        netmask 64
        endpoint 212.224.0.188
        local 178.63.83.84
        ttl 64
        up ip link set mtu 1280 dev sixxs || true
        up ip route add default via 2001:6f8:900:c6e::1 dev sixxs || true
        up ip -6 route flush dev eth0 || true
        up ip -6 r a 2001:6f8:90e::/48 dev xenbr0 || true
        down ip -6 route flush dev sixxs || true

The config of one of the Xen domUs is this: 

sample domU config
config old server new server
system Debian Lenny
2.6.18-6-xen-amd64
Debian Lenny
2.6.32-5-xen-amd64
/etc/sysctl.conf net.ipv4.conf.default.rp_filter=1
net.ipv4.tcp_syncookies=1
net.ipv4.conf.default.forwarding=1
net.ipv6.conf.default.forwarding=1
net.ipv4.conf.eth0.proxy_arp=1
net.ipv4.conf.default.proxy_arp=1
kernel.shmmax=268435456
net.ipv4.conf.default.rp_filter=1
net.ipv4.tcp_syncookies=1
net.ipv4.conf.default.forwarding=1
net.ipv4.conf.all.forwarding=1
net.ipv6.conf.default.forwarding=1
net.ipv4.conf.eth0.proxy_arp=1
net.ipv4.conf.default.proxy_arp=1
kernel.shmmax=268435456
/etc/network/interfaces

# The primary network interface
auto eth0
iface eth0 inet static
        address 78.47.85.145
        netmask 255.255.255.248
        up ip route add 85.10.209.0/27 dev eth0
        up route add default gw 85.10.209.30 dev eth0
        up ip -6 address add 2001:6f8:90e:145::1/64 dev eth0 || true
        up ip -6 route add default via 2001:6f8:90e:1::1 || true       
        up iptables -t nat -A POSTROUTING -s 192.168.x.96/27 -o eth0 -j MASQUERADE || true

iface eth0 inet6 static
        address 2001:6f8:90e:145::1
        netmask 64
        gateway 2001:6f8:90e:1::1

auto eth1
iface eth1 inet static
        address 192.168.x.1
        netmask 255.255.255.0

# The primary network interface
auto eth0
iface eth0 inet static
        address 178.63.83.104
        gateway 178.63.83.84
        netmask 255.255.255.192
        broadcast 178.63.83.127
        up ip -6 address add 2001:6f8:90e:145::1/64 dev eth0 || true
        up ip -6 route add default via 2001:6f8:90e:1::1 src 2001:6f8:90e:1:216:3eff:fe89:6c31 || true
        up iptables -t nat -A POSTROUTING -s 192.168.x.96/27 -o eth0 -j MASQUERADE || true

iface eth0 inet6 static
        address 2001:6f8:90e:145::1
        netmask 64
        gateway 2001:6f8:90e:1::1

auto eth1
iface eth1 inet static
        address 192.168.x.1
        netmask 255.255.255.0

The dom0 seems to be reachable via IPv6 just perfectly fine. When trying to reach the domU I see packets going through the xenbr0 bridge and reaching the domU eth0 interface. The ICMP6 echo request packets (proto 58) are unanswered there, no echo replies. Strange enough it seems to work from time to time, but mostly not. I've also tried to set a generic default route like ip -6 route add default dev eth0, but still no improvement.

Did I miss something when migrating to the new server? Is there any mistake in the configs? Any suggestions are appreciated! :-)

UPDATE:
This is a tcpdump from the domU, doing a ping from dom0: 

07:35:29.308261 IP6 fe80::e46d:25ff:fe1f:317b > ip6-allnodes: ICMP6, router advertisement, length 56
07:35:29.329411 IP6 gate-hro.ip6.windfluechter.net > vserv.windfluechter.net: ICMP6, echo request, seq 45, length 64
07:35:30.329439 IP6 gate-hro.ip6.windfluechter.net > vserv.windfluechter.net: ICMP6, echo request, seq 46, length 64
07:35:30.451991 IP6 2001:418:4001:3::c657:b0c5 > vserv.windfluechter.net: ICMP6, echo request, seq 52836, length 64
07:35:30.481124 IP6 fe80::e46d:25ff:fe1f:317b > ff02::1:ff70:be: ICMP6, neighbor solicitation, who has 2001:6f8:90e:1:216:3eff:fe70:be, length 32
07:35:31.329906 IP6 gate-hro.ip6.windfluechter.net > vserv.windfluechter.net: ICMP6, echo request, seq 47, length 64
07:35:31.481645 IP6 fe80::e46d:25ff:fe1f:317b > ff02::1:ff70:be: ICMP6, neighbor solicitation, who has 2001:6f8:90e:1:216:3eff:fe70:be, length 32
07:35:32.329284 IP6 gate-hro.ip6.windfluechter.net > vserv.windfluechter.net: ICMP6, echo request, seq 48, length 64
07:35:32.481114 IP6 fe80::e46d:25ff:fe1f:317b > ff02::1:ff70:be: ICMP6, neighbor solicitation, who has 2001:6f8:90e:1:216:3eff:fe70:be, length 32
07:35:33.329951 IP6 gate-hro.ip6.windfluechter.net > vserv.windfluechter.net: ICMP6, echo request, seq 49, length 64
07:35:34.329705 IP6 gate-hro.ip6.windfluechter.net > vserv.windfluechter.net: ICMP6, echo request, seq 50, length 64

UPDATE #2:
The issue is finally solved. The solution can be found here.

Kategorie: 
 

Converting AVCHD Videos

When we were going on holiday lately we took some 2-3 hours of videos. It's a Panasonic HDC-SD600 camcorder we bought for that matter. Usually I'm connecting the camera to my Mac and import the videos into iMovie or such. During the holiday I copied the clips to an external USB drive to save the space on the 16 GB SD card. The plan was to copy it back to the card and import it later. This usually works, but somehow it did not for one backup. Sadly iMovie is so dumb that it can't import directly from those file. So I needed another way to import the movies. Kdenlive is able to import the movies as well as Handbrake on OSX is able to convert them. In the end I used ffmpeg on Debian to convert the clips: 

for i in *.MTS ; do echo $i ; ffmpeg -i $i -deinterlace -threads 4 -sameq /srv/video/iMovie/ffmpeg/${i}.mp4 ; done

This converts the MTS files from the camera into some MPEG4 format that iMovie is able to import by itself. The quality seems to be ok on a first quick view. Or do I miss something and there's a command switch that will result in better quality? Basically I want the same video and audio quality as the source files have.

Kategorie: 
 

OS X, Linux and netatalk

After coming back from holiday where I made lots of photos and videos, I needed the possibility to import all those from SD cards to my fileserver running Debian unstable. To import the photos I used Digikam on Linux, that was no problem. But for the videos I needed iMovie and/or FinalCut Express on my Mac. I've looked into Kino and Cinelerra, but those Linux apps are awful.

The problem was that iMovie is able to directly import from our Panasonic HD camcorder to the network storage. I was always forced to first import the fotoage to the drive in my MacBook Pro and copy it then to the Linux box onto a Samba share. The solution for that problem is to use netatalk/AFP. The Linux box appears as a Mac Xserve then.

However, I quickly found some HowTos for configuring netatalk. One HowTo is from Mike Hughes and the other one can be found on disgruntled-dutch.com. If you follow these two HowTos you're quite close to have a working AFP service to interact with your Mac via Bonjour/Avahi.

There are mainly two problems when you follow them. First, Mike Hughes has some illegal chars in his sample /etc/avahi/services/afpd.servicefile:

<!DOCTYPE service-group SYSTEM “avahi-service.dtd”>
<service-group>
<name replace-wildcards=”yes”>%h</name>

The quotation marks are the problem. Instead of ” you'll need normal " quotation marks. Or you can use the file on disgruntled-dutch.com.

Next problem is the configuration of the shares. On both sites the examples are using cdb as CNID backend: 

~/                      "Home Directory"        cnidscheme:cdb options:usedots,upriv

But this will give the following error:

Aug  3 23:30:29 muaddib afpd[8151]: Can't open volume "/home/ij" CNID backend "cdb"
Aug  3 23:31:26 muaddib afpd[8151]: Cannot find module named [cdb] in registered module list!

The solution can be found on forum.ubuntuusers.de (German): you'll need to change the cdb to dbd. So, the Home Directory share will look like this then: 

~/                      "Home Directory"        cnidscheme:dbd options:usedots,upriv

Quite simple and easy. Now restart your avahi-daemon and netatalk services and have fun! When you want to use a share on your Linux server for TimeMachine backups, you'll need to add a "tm" to the options of your share.

 

Kategorie: 
 

Getting hit by a spammer with Exim

Yesterday I was warned by Nagios that something is going on with my server. The number of processes has been gone beyond the limit. The reason for this were a bunch of Exim processes trying to deliver a lot of mails. Apparently a spammer made it happen to send spams via my server. How could this happen?

I was seeing a lot of those log entries: 

2010-06-28 16:29:25 1OTFKt-0004cZ-1R <= vsvc@euhu.com H=(qknlvj.com) [58.212.194.230] P=esmtpa A=cram_md5:inna S=1455 id=0ec5ff00b06c43369e2582fc4269839e@e12c17c51ec546bf9e7a23e6f9875941
2010-06-28 16:29:27 1OTFKw-0004cZ-KZ <= ebms@ylmdbm.com H=(qknlvj.com) [58.212.194.230] P=esmtpa A=cram_md5:inna S=1520 id=58913c34bde64e908310db7e1280eff5@2dc8ed5998b64e8485c472cae5ef98c3
2010-06-28 16:29:28 1OTFKy-0004cZ-1p <= wiyscy@hegyogz.com H=(qknlvj.com) [58.212.194.230] P=esmtpa A=cram_md5:inna S=1436 id=814a7bdcbe85447a9283d4a0a074830b@0ada3cde4a4c41c38c65bc912639afb6

Apparently the spammer has successfully found a way to bypass the authenticators in Exim. By default only authenticated users can send mails via my mailserver, of course. But this spammer found a way around that problem. A user "inna" is not known, so the spammer shouldn't be able to send mails at all. But he can. Something is broken apparently.

The spammer sent an empty password ('') and the database didn't find an user by this name and returned an empty resultset (''). Both sides of the comparison matches and the mail is allowed in. Let's have a look at my Exim config: 

cram_md5:
  server_debug_print = "running smtp auth $1 $2"
  driver = cram_md5
  public_name = CRAM-MD5
  server_secret = ${lookup pgsql{select clear from passwd where passwd.usr='$1' limit 1}{$value}}
  server_set_id = $1

On #exim@freenode there was just another user with the very same problem with exactly the same spammer. Apparently the lookup is true for empty passwords or users. The solution is to add a "fail" in the lookup statement: 

server_secret = ${lookup pgsql{select clear from passwd where passwd.usr='$1' limit 1}{$value}fail}

That's pretty all to do to prevent the spamming. But how could this happen at all? Back then when I was configuring my mailserver (around 2003 or so) I can remember that I tried a "fail" statement in the server_secret as it is described in the Exim documentation, but it didn't work as expected. So I ended up with no "fail". This worked fairly well over the years and I remember that I tested this lookup by trying to send with user/password combinations of all different sorts. So it went into "production".

Apparently it doesn't work anymore today. The other guy on the #exim channel said that he found no database lookup example with "fail" at all. Even the example in one of his books was without "fail". So I believe that something changed either in Exim or in PostgreSQL to make submitting an empty password string a positive match for bypassing authentication nowadays.

For the records: the spammer send approx. >10.000 mails. Another bunch of 8000 mails were rejected, but this is just slightly over the daily average.

Kategorie: 
 

Slow Import with Digikam

Scheinbar gingen in den letzten Tagen wieder ein paar Invites für Flattr.com raus. Zumindest wenn man die Twittermeldungen dazu liest. ;-)
Neue Dinge sind natürlich hipp und man will ja auch dabei sein, wenn was neues kommt, um mitreden zu können. Aber was ist die Motivation derjenigen, die Flattr nutzen? Wollen sie selber von anderen geflattred werden, was ja nicht nur schmeichelhaft für das Ego ist, sondern im Zweifel auch noch ein bißchen Geld bringt? Oder wollen sie primär gute Artikel selber flattren und anderen damit etwas Wertschätzung zeigen und sind somit auch bereit, für gute Artikel im Netz etwas zahlen?
Dazu hab ich mal auf Anraten von Tobias Gies einen Twtpoll aufgesetzt. Bitte schön:

Kategorie: 
 

Drupal and PostgreSQL - SELECT DISTINCT, ORDER BY

Gestern habe ich einen Artikel über Abmahnungen bei Stefan Niggemeier, der ebenfalls wie ich aus Georgsmarienhütte stammt, gelesen.
Niggemeier ist derzeit wohl ziemlich unter Beschuß von Anwälten und hat auch schon die eine oder andere Abmahnung hnter sich. Einzelheiten kann man ja in seinem Artikel lesen. Aber der eigentliche Punkt, auf den ich hinaus will, ist dieser:

Diese Leute — nicht nur dieser Anwalt oder sein Mandant, sondern viele andere — haben das elementare Prinzip der Meinungsfreiheit nicht verstanden. Sie haben nicht verstanden, dass sie ein Wert an sich ist. Dass sie auch Beiträge schützt, die nach irgendwelchen subjektiven oder objektiven Maßstäben wertlos sind. Artikel 5, Absatz 1, Satz 1 des Grundgesetzes lautet nicht: „Jeder hat das Recht, seine Meinung in Wort, Schrift und Bild frei zu äußern und zu verbreiten, solange es sich um ein wichtiges Thema handelt und ein Interesse der Öffentlichkeit an dieser Meinung besteht.”

[......]

Durch den Gang zum Anwalt und zum Gericht wird aus einer Auseinandersetzung um Wahrheit zu einer, in der regelmäßig nicht derjenige gewinnt, der Recht hat, sondern der sich die Auseinandersetzung leisten kann. Der Mächtige gewinnt.

Wer schon einmal mit solchen Leuten zu tun gehabt hat, der wird sicherlich auch abgewogen haben, ob er sich die Durchsetzung seiner Meinungsfreiheit leisten kann? Gerade die Tatsache des fliegenden Gerichtsstands macht die Sache für die Abmahner einfach. Sie können sich einfach irgendwo in Deutschland ein Gericht suchen, von dem sie glauben, daß es in ihrem Sinne entscheiden wird. So werden häufig die Berliner oder Hamburger Gerichte ausgewählt, vor denen dann geklagt wird. Auch wenn weder Kläger noch Beklagter aus Hamburg oder Berlin kommen.

Wer also ein Blog betreibt oder anderweitig im Internet seine Meinung publiziert, muss schon immer sehr genau darauf achten, was er schreibt. Letztendlich führt das zu einer Schere im Kopf. Einer vorauseilenden Selbstzensur. Man schreibt nicht mehr seine Meinung ins Netz, sondern das, von dem man selber denkt und hofft, daß es auch andere so sehen, was rechtlich gesehen unbedenklich sein könnte. Das aber hat, wie Niggemeier anmerkt, wenig mit dem Grundrecht auf Meinungsfreiheit zu tun. Er zitiert ja auch das Bundesverfassungsgericht und seine Stärkung der Meinungsfreiheit neuestem. Bleibt also zu hoffen, daß dieses höchstrichterliche Urteil auch in Berlin und Hamburg Eingang in die dortige Rechtssprechung findet.
Denn das Grundrecht auf Meinungsfreiheit beinhaltet (zumindest für mich) auch, daß ich diese frei äußern darf. Ein solches Grundrecht ist keines, wenn ich eine Meinung lediglich haben darf, diese aber nicht teilen, kommunizieren oder veröffentlichen darf. "Die Gedanken sind frei", heißt es. Aber erst wenn ich diese Gedanken und somit meine Meinung auch frei äußern darf, herrscht Meinungsfreiheit. Und ein vom Grundgesetz garantiertes Grundrecht darf nicht vom Geldbeutel des Menschen abhängen, der diese Meinung hat und sie auch frei äußern möchte.

Der Gesetzgeber ist also aufgerufen, dem Unwesen der Abmahnungen Einhalt zu gebieten.

Kategorie: 
 

Pages

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer