Hier nun mein Beitrag dazu…

Quartiere

Quartier 1 – Wohnen am Alten Strom

Als Schwächen werden u.a. erneuerungsbedürftige Fußwege, der durch Touristen überlastete Bereich und parkende Autos in den Verbotsbereichen genannt. Dem ist eigentlich nichts mehr hinzuzufügen, denn es ist einfach so: zuviele Touristen haben halt einfach solche Folgen. Den “Charme des Ursprünglichen”, wie im Strukturkonzept aufgeführt, muss man zu Zeiten suchen, wo wenige Touristen da sind. Was diese Touristenmassen für die Anwohner bedeutet, mag man sich gar nicht ausmalen. Ein schönes Wohnen, wo man sich eventuell auch von seiner stressigen Arbeit in der Firma erholen kann, scheint dort nicht mehr möglich. Mit allen seinen Nebenwirkungen wie gesundheitliche Probleme.

Quartier 2 – Nördlicher historischer Kern

Hier ist das Gebiet zwischen Heinrich-Heine-Straße, Alexandrinenstraße, Kirchenplatz und Seestraße gemeint. Auch hier wird der schlechte Zustand der Gehwege wie auch die Parksituation bemängelt. Teilweise wurde hier aber schon umfangreich saniert. Es ist kein Geheimnis, daß sich etwas an der Parkplatzsituation ändern muss: Anwohnerparken für Anwohnerinnen und Anwohner und das Verhindern von Touristenparken kann hier helfen, insbesondere auch fuer den Kirchenplatz, auf dessen Parkplatz für Bewohner, die ihren Erledigungen nachgehen wollen, allzu häufig kein Parkplatz zu finden ist.

Quartier 3 – Südlich der Kirche

Wie überall in Warnemünde gibt es hier auch marode Straßen und Gehwege und zuwenig Parkraum für die Anwohner. Hier wäre es wünschenswert, wenn eine verträgliche und tragfähige Lösung für die Anwohner gefunden werden kann, indem man Fremdparker aus dem Bereich heraushalten kann, ohne die Gewerbetreibenden dort zu benachteiligen.

Quartier 4 – Wohnen südlich der Rostocker Straße

Dieses Quartier ist, nunja, den Meisten vermutlich relativ unbekannt. Bestenfalls fährt man hier vorbei, wenn man zum Bahnhof auf den großen Parkplatz möchte. Damit stellt die Rostocker Straße eine entsprechende Barriere dar, die sich auch nicht abschaffen läßt, sollte man auf der Mittelmole weiterhin das Konzept verfolgen, dort einen großen Parkplatz anzubieten.

Quartier 5 – Wohnen am Kurpark

Auch hier, rund um den Kurpark: schlechte Straßen, miese Gehwege. Teilweise zeigt die vor wenigen Jahren sanierte Straße schon nach kurzer Zeit schon wieder Risse und Defekte, was nicht unbedingt von entsprechender Qualität der Straßensanierung zeugt. Auch hier ist das Hauptproblem jedoch der touristische Parkplatzsuchverkehr. Das Verhandensein der Tiefgarage ist eventuell zwiespältig: zum Einen werden hier Pakrplätze zur Verfügung gestellt, zum Anderen wird dadurch entsprechender Verkehr dorthin geleitet, der besser draußen vor den Toren bleiben sollte.

Quartier 6 – Südlich Mühlenstraße

Gefühlt ist dieses Quatier der Wohmittelpunkt Warnemündes. Dementsprechend angespannt ist hier sicherlich auch die Parkplatzsituation für die Anwohner. Die Grünflächen und Bäume für mehr Parkraum zu opfern kann und darf sicherlich keine Option für mehr Parkraum sein. Auf der Parkfläche “Am Markt” ein Parkhaus für Anwohner mit Unter- und Obergeschoß zu bauen, dürfte die Parksituation im gesamten Quartier sicherlich signifikant entlasten. Der unter “Schwächen” aufgeführten Umwandlung von Mietwohnungen in Eigentums- und Ferienwohnungen muss wirksam entgegnet werden.

Quartier 7 – Zwischen Strandweg und Stephan-Jantzen-Park

Das Quartier betrifft den Bereich zwischen Strandpromenade und Parkstraße. Auch hier wieder herauszuheben sind marode Fahrbahnen, unzumutbare Gehwege und die Verkehrsproblematik sowohl das rollenden als auch des ruhenden Verkehrs. Stellenweise herrscht hier im Bereich der Ecolea-Berufsschule schon Tempo 30, aber aufgrund der allgemeinen Situation mit Spielplätzen, Kindergarten, Fahrrädern und querendem Fußgängern scheint eine Tempo 30 Zone für die gesamte Parkstraße mehr als angebracht zu sein, nicht nur für Fahrzeuge über 7.5t.
Die seit Jahren im Gespräch befindliche Umgehungsstraße läßt hier auch noch immer auf sich warten, so daß das Verkehrsaufkommen hier ganztägig auch außerhalb der Saison sehr hoch ist und damit auch die Larmbelastung entsprechend groß. Die Lärmkarte MV weist hier einen 24h Lärmpegel von 65-70 dB(A) auf, nachts einen Pegel von 60-65 dB(A). Das bedeutet, daß tagsüber der Lärmpegel sicherlich deutlich über den kartierten 65-70 dB(A) liegen dürfte. Bei Näße scheint der Lärm noch stärker zu sein. Hier herrscht also sicherlich auch in Hinblick auf den Immissionsschutz der Anwohner dringender Handlungsbedarf durch lärmreduzierende Maßnahmen.
Die erwähnte Problematik mit den Toilettenhäuschen kann man anhand des abgebildeten Toiletten-“Häuschens” leicht nachvollziehen. Laut Ostsee-Zeitung plant das nicht allzu ferne Börgerende ganz andere Toilettenhäuser. Toiletten sollten in Strandnähe kostenlos zu nutzen sein. Deren Bewirtschaftung könnte über die Kurtaxe oder eine Strandnutzungsgebühr finanziert werden.

Quartier 8 – Wohnen rund um den Wiesenweg

Das Strukturkonzept spricht hier von “überwiegend ein Wohngebiet”. Für die Gartenstraße scheint diese Behauptung aber zumindest stellenweise sehr gewagt, da sich hier durchaus viele Ferienwohnungen befinden. Manche Häuser scheinen sogar zu 100% Ferienwohnungen zu sein. Weiterhin ist hier der Parkplatzsuchverkehr im Sommer ein Problem, bei dem selbst vor Einfahrten nicht Halt gemacht wird – oder anders ausgedrückt: es wird eben doch Halt gemacht, indem das Auto so geparkt wird, daß man weder vom noch auf die eigene Einfahrt kommt. Zugeparkte Gehwege sind ebenfalls ein ständiges Ärgernis. Auch hier sollte über ein Anwohnerparken bzw. Zufahrt nur für Anlieger nachgedacht werden.
Eventuell wäre auch ein Radweg zwischen Wiesenweg und Stadtautobahn an der Außenseite des Kleingartenvereins “Am Moor” machbar.
Wie überall anders auch, sind die Straßen- und Gehwege in einem erbärmlichen Zustand.

Quartier 9 – Zwischen Richard-Wagner-Straße und An der Stadtautobahn

Dieser Bereich dürfte maßgeblich für viele nachfolgende Probelmatiken sein: im Ortseingangsbereich der Stadtautobahn dürfte sich zukünfig schon entscheiden, wie sehr die Parkplatzsuche in den anderen Quartieren die Anwohner belastet. Anders ausgedrückt: An dieser Stelle müssen schon Maßnahmen ergriffen werden, daß der Verkehr erst gar nicht in den Ort verlagert wird. Tagestouristen sollten hier schon abgefangen und auf die an dieser Stelle verfügbaren Parkplätze geleitet werden. Vorgelagerte Parkleitsystem an der B103 und der A19/A20 sollten Anreisende schon frühzeitig über die aktuelle Parkplatzsituation informieren, so daß es hier gar nicht mehr zu einem Parkplatzsuchverkehr kommen kann. Wenn der Ort voll ist, ist der Ort voll. Da hilft es auch nicht, wenn noch weitere 5000 Touristen aus Berlin versuchen, einen Parkplatz zu finden. Diese müssen dann in andere Orte ausweichen, wenn sie denn unbedingt an die Ostsee wollen. Im Notfall sollte auch über eine Sperrung des Ortes nachdenken, wie es dieses Jahr in der Kieler Bucht aufgrund der Corona Pandemie auch geschehen ist. Das dortige Ampel-System für überfüllte Strände sollte auch auf Warnemünde erweitert werden. 
Sollte der Parkplatz an der Jugendhergerge ausgebaut werden, so sollte der Verkehr dorthin nicht durch den Ort, sondern über alternative Strecken wie die seit Jahren geplante Umgehungsstraße ab Lichtenhagen geführt werden, um den Ort zu entlasten. Der Abreiseverkehr sollte dementsprechend ebenfalls nicht durch den Ort geführt werden. Für Anwohner und berechtigte Anlieger (Hotel-, Ferienwohnungsgäste, sowie regulärer Besuch der Anwohner) sollte weiterhin die Zufahrt möglich sein. Ob hier technische, aber grundrechtsschonende und datenschutzsparsame Maßnahmen möglich sind, sollte evaluiert werden. 

Quartier 10 – Warnemünde West

Hier befindet sich das Dünenquartier, das schon für viel Unmut bei den Warnemündern in diversen Ortsbeiratssitzungen gesorgt hatte, u.a im Jahr 2013. Die Nähe zu den Sportplätzen und der Jugendherberge mit dem großen Parkplatz erscheint als ein Garant für Probleme. Ein Ausbau der Parkplätze dürfte den wenigen regulären Einwohnern, die keine Ferienwohnung oder Zweitwohnung dort haben, ebenso zur Belastung. Etngegen der Aussagen und Zusicherungen von damals, scheinen die meisten Wohneinheiten im Dünenquartier eben nicht als Erstwohnsitz, sondern als Ferienwohnung genutzt zu werden. Insofern dürfte die Mehrheit der Warnemünder wohl relativ desinteressiert an der Wohnsituation dort sein.
Was aber seit längerem ein Thema (auch in der Presse) ist, ist die Situation des Geh- und Radwegs im Bereich Parkstraße, nicht nur dort, sondern der gesamten Parkstraße. Es ist sicherlich Konsens, daß hier etwas geschehen muss. 

Quartier 11 – Mittelmole

Die Mittelmole – bei den Warnemündern ein noch größeres Streitthema bei den Warnemündern als das Dünenquartier. Eine Wohnbebauung erscheint vielen Warnemündern als Irrweg. Das Conexeum schlägt u.a. einen Veranstaltungshalle für die Warnemünder Vereine vor. Ebenso sollte der Segelschwerpunkt mit den Segelvereinen und die Sportschule des Landessportbundes dort erhalten und eventuell ausgebaut werden, um den maritimen Charakter Warnemündes zu stärken und die Bedeutung Warnemündes als Veranstaltungsort für Segel-Events zu betonen.
Auf keinen Fall sollten abstruse Vorhaben wie Hochhäuser dort umgesetzt werden. Sinnvoll wäre eine niedrige Bebauung, die den Einwohnern Warnemündes wie auch dem Tourismus gleichmaßen nützt. Das könnte durch 3-4 stöckige Gebäude mit Gastronomie und Einkaufsmöglichkeiten im Erdgeschoß und Geschäfts- und Praxisräumen in den oberen Etagen erfolgen. Eventuell könnte hier auch eine “Außenstelle” des Technologieparks neue Räumlichkeiten für die Ansiedlung entsprechender Firmen und damit auch zusätzlicher, wohnortnaher Arbeitsplätze entstehen.

But Cisco Jabber is a whole infrastructure environment: you can’t use Cisco Jabber client on its own without the other required Cisco infrastructure as Cisco CUCM and CIsco IM&P servers. So you can’t just setup Prosody or ejabberd on your Debian server and connect Cisco Jabber to it. But what are the differences of Cisco Jabber to “standard” XMPP clients?

Cisco Jabber

The above screenshot from the official Cisco Jabber product webpage shows the new, single view layout of the Cisco Webex Teams client, but you can configure the client to have the old, classic split view layout of Contact List and Chat Window. But as you can already see from above screenshot audio & video calls is one of the core functions of Cisco Jabber whereas this feature has been added only lately to the well-known Conversations XMPP client on Android. Conversations is using Jingle extension to XMPP whereas Jabber uses SIP for voice/video calls. You can even use Cisco Jabber to control your deskphone via CTI, which is a quite common setup for Jabber. In fact you can configure Jabber to be just a CTI client to you phone or a fully featured UC client.

When you don’t want to have Ciscos full set of on-premise servers, you can also use Cisco Jabber in conjunction with Cisco Webex as Cisco Webex Messenger. Or in conjunction with Webex Teams in Teams Messaging Mode. Last month Cisco announced general availability of XMPP federation for Webex Teams/Jabber in Teams Messaging Mode. With that you have basic functionality in Webex Teams. And when I say “basic” I really mean basic: you can have 1:1 chat only, no group chats (MUC) and no Presence status will be possible. Hopefully this is just the beginning and not the end of XMPP support in Webex Teams.

XMPP Clients

Well, I’m sure many of you know “normal” XMPP clients such as Gajim or Dino on Linux, Conversations on Android or Siskin/Monal/ChatSecure on Apple IOS. There are plenty of other clients of course and maybe you used an XMPP client in the past without knowing it. For example Jitsi Meet is based on XMPP and you can still download the Jitsi Desktop client and use it as a full-featured multi-protocol client, e.g. for XMPP and SIP. In fact Jitsi Desktop is maybe the client that comes closest to Cisco Jabber as a chat/voice/video client. In fact I already connected Jitsi Desktop to Cisco CUCM/IM&P infrastructure, but of course you won’t be able to use all those Cisco proprietary extensions, but you can see the benefit of open, standardized protocols such as XMPP and SIP: you are free to use any standard compliant client that you want.

So, while Jitsi supported voice/video calls for a long time, even before they focussed on Jitsi Meet as a WebRTC based conference service, Conversations added this feature last month, as already stated. This had a huge effect to the whole XMPP federation, because you need an XMPP server that supports XEP-0215 to make these audio/video calls work. The well-known Compliance Tester listed the STUN/TURN features first as “Informational Tests”, but quickly made this a mandatory test to pass tests and gain 100% on the Compliance Tester. But you cannot place SIP calls to other sides, because that’s a different thing.

As many of you are familiar with standard XMPP clients, I’ll focus now on some similarity and differences between Cisco Jabber and standard XMPP…

Similarities & Differences

First, you can federate with Cisco Jabber users. Cisco IM&P can use standard XMPP federation with all other XMPP standard compliant servers. This is really a big benefit and way better than other solutions that usually results in vendor lock-in. Depending on the setup, you can even join from your own XMPP client in MUCs (Multi User Chats), which Cisco calls “Persistent Chat Room”. The other way is not that simple: basically it is possible to join with Cisco Jabber in a MUC on a random server, but it is not as easy as you might thing. Cisco Jabber simply lacks a way to enter a room JID (as you can find them on https://search.jabber.network/. Instead you need to be added as participant by a moderator or an admin in that 3rd party MUC.

Managed File Transfers is another issue. Cisco Jabber supports Peer-to-Peer file transfers and Managed File Transfers, where the uploaded file get transferred to an SFTP server as storage backend and where the IM&P server is handling the transfer via HTTPS. You can find a schematic drawing in the Configuration Guides. Although it appears similar to HTTP Upload as defined in XEP-0363, it is not very likely that it will work. I haven’t tested it yet, because in my test scenario there is a gatekeeper in the path: Cisco Expressway doesn’t support (yet) Managed File Transfer, but you can upvote the idea in the ideas management of Cisco or other ideas such as OMEMO support.

OMEMO support? Yes, there is no end-to-end encryption (E2EE) currently planned for Cisco Jabber, while it is common nowadays for most modern XMPP clients. I think it would be good for Cisco Jabber to also (optionally) support OMEMO or its successor. Messaging clients without E2EE are not state of the art anymore.

Whereas Conversations is the de-facto standard on Android, Apple IOS devices are still lacking a similar well-working client. See my blog post “XMPP – Fun with Clients” for a summary. In that regard Cisco Jabber might be the best XMPP client for IOS to some degree: you have working messaging, voice/video calls, Push Notifications and integration into Apples Call Kit.

There are most likely many, many more differences and issues between Cisco Jabber and standard compliant XMPP servers and clients. But basically Cisco Jabber is still based on XMPP and extends that by proprietary extensions.

Summary

While I have the impression that the free clients and servers are well doing and increased development in the past years (thanks to Conversations and the Compliance Tester), the situation of Cisco Jabber is a little different. As a customer you can sometimes get the impression that Cisco has lost interest in developing Cisco Jabber. It got better in the last years, but when Cisco Spark was introduced some years ago, the impression was that Cisco is heavily focussed on Spark (now: Webex Teams). It’s not like Cisco is not listening to customers or the development has been stopped on Jabber, but my impression is that most customers don’t give feedback or tell Cisco as the vendor what they want. You can either submit ideas via the Colaboration Customer Ideas Tool or provide feedback via your Cisco and partner channels.

I think it is important for the XMPP community to also have a large enterprise level vendor like Cisco. Otherwise the Internet will become more and more an Internet of closed silos like MS Teams, Slack, Facebook, etc. Of course there are other companies like ProcessOne (ejabberd) or Tigase, but I think you agree that Cisco is another level.

The situation for macOS and iOS users are not that good as for Windows, Linux or Android users. But in the end all clients have their pro and cons… I’ll try to summarize a few clients on Linux, macOS and iOS…

Linux

Gajim

Fully featured multiprotol client with lots of available plugins. If you want to use OMEMO with Gajim you need to enable it in your plugin settings. There is even a plugin for letting the keyboard LED blink when there are new/unread messages. I found that a little bit annoying, so I disabled that. Gajim is an old-style client with the well-known layout of a contact list window and one for the actual chats. Gajim has some nice features like service discovery on your or remote servers.

Dino

Dino is available in Debian as dino-im and is a quite new client, which you will find out at first start: it’s a single window app where the focus is on the chats. There is no contact list at first glance where you can see whether or not your contacts are online. You can find your contacts when you want to start a conversation with your contact. I don’t find this bad or good. It’s just different and puts the chat into focus, as said, maybe similar to WhatApp, Signal or other messengers nowadays where you just sent messages back and forth and don’t care if the contact is online. The contact will receive and read your message when the contact is online and will eventually answer your message.

macOS

Monal

Monal is an actively developed and maintained client for macOS and iOS. If you want to try out Monal, don’t waste your time with the older client, but focus on Monal Catalyst (direct download link). Catalyst shares the same code as the iOS version of Monal and will become the default Monal download within the next few weeks. It’s far easier for the developers to focus on one codebase than on two different ones. Monal has great potential, but also has some issues. For some reason it seems that some messages from time to time will be sent multiple times to a contact or a MUC. The developers are very helpful and supportive. So when you find a bug or issue, please report back.

BeagleIM

BeagleIM is a free XMPP client by Tigase, which business is to sell their XMPP Communication suite and professional support for it. They provide clients for Android, macOS and iOS. Maybe for that reason their clients seems to be very mature, but of course will work best with their own server software. That doesn’t mean that the clients won’t work well with other 3rd party XMPP servers, just that their main focus will be their own server software, However, BeagleIM seems to work well with Prosody and ejabberd and when you have issues you can also reach out to Tigase on Mastodon, which I find a very big plus! They are really helpful there as well. The BeagleIM client is currently my main client on macOS and it works quite well. As you can see it’s more or less chat-focused as well by default, but you can open a contact list window if you want to see all of available/all clients. Only issue I personally have at the moment is, that it seems to have problems with ejabberd: in the contact list and account preferences I see the accounts/contacts with ejabberd going offline/online every few minutes. There are some log entries in ejabberd that seem to be timeout related. I’m not sure whether this is an issue with ejabberd or with BeagleIM – or a rare combination of both.

iOS

ChatSecure

ChatSecure is one of my first XMPP clients on iOS I installed and used for a long time. It works mostly very well, supports OMEMO (like all the other clients I mention here) and it seems to be able to work well with bookmarks (i.e. use a list of MUCs to join). Only issues I have with ChatSecure currently are: 1) when ChatSecure comes to front after a deep sleep state of the client on iPhone it presents an empty screen and no accounts in settings. You need to quit ChatSecure and restart it to have it working again. Quite annoying. 2) when restarted it polls all messages again from MAM (message archives) over and over again. A small annoying where you can decide if it’s better to have duplicated messages or may miss a message.

Monal

What was valid for Monal Catalyst on macOS is also (more or less) true for Monal on iOS. As said: they share the same code base. It is usuable, but has sometimes issues with joining MUCs: it appears as if you can’t join a MUC, but suddenly you receive a message in the MUC and then it is listed under Chats and you can use it.

SiskinIM

Siskin is the iOS client from Tigase. It also seems to be very mature, but has some special caveats: in the settings you can configure Push Notifications and HTTP Uploads for each and every clients. Other clients make this automatically and I leave it to you to decide whether this is a nice feature that you can configure it or if it is a little bit annoying, because when you don’t know that, you will be wondering why you can’t upload files/fotos in a chat. Maybe uploading files will work with Tigase XMPP server, but it doesn’t seem to work on my servers.

So, in the end, there are good/promising clients on iOS and macOS, but every client seem to have its own pitfalls. On iOS all three clients do support and use Apple Push Notifications, but you should choose carefully for which one you want to enable it. I can tell you it’s a little bit annoying to test three clients and have Push Notifications turned on for all of them and have joined in several MUCs and get all notifications three times for every message… 😉

MUCs are a special topic I need to investigate a little more in the future: when your server supports Bookmarks for MUCs I would assume that it should be working for all supporting clients and you only need to join MUC on one client and have that MUC at least in your list of bookmarks. If you want to join that MUC on every client might be another story. But I don’t know if this is the intended behaviour of the XEP in question or if my assumption how it should work is just wrong.

In the end the situation for XMPP clients on macOS and iOS is much better than it was 1-2 years ago. Though, it is not as good as on Android, but you can help improving the situation by testing the available clients and give feedback to the developers by either joining the approrpriate MUCs or – even better – file issues on their Github pages!

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       90%     50113         60067424
# 2  Short offline       Completed without error       00%      3346

After the RAID-Sync-Sunday last weekend I removed sda from my RAIDs today and started a “smartctl -t long /dev/sda“. This test was quickly aborted because it already ran into an read error after just a few minutes. Currently I’m still running a “badblocks -w” test and this is the result so far:

# badblocks -s -c 65536 -w /dev/sda
Testing with pattern 0xaa: done
Reading and comparing: 42731372done, 4:57:27 elapsed. (0/0/0 errors)
42731373done, 4:57:30 elapsed. (1/0/0 errors)
42731374done, 4:57:33 elapsed. (2/0/0 errors)
42731375done, 4:57:36 elapsed. (3/0/0 errors)
46.82% done, 6:44:41 elapsed. (4/0/0 errors)

Long story short: I already ordered a replacement disk!

But what’s also interesting is this:

I removed the disk today at approx. 12:00 and you can see the immediate effect on the other disks/LVs (the high blue graph from sda shows the badblocks test), although the RAID10 is now in degraded mode. Interesting what effect (currently) 4 defect blocks can have to a RAID10 performance without smartctl taking notice of this. Smartctl only reported an issue after issueing the selftest. It’s also strange that the latency and high utilization slowly increased over time, like 6 months or so.

The other problem I complained last month about was missing software in Debian. There is binkd and ifcico as mailer software and crashmail and ifmail as a tosser, but no reader software. So how did I get started again? First, I got into mood by watching all parts of the BBS documentary about BBSes:

It’s a nice watch, so even when you don’t plan to start a BBS or join Fidonet like I did, you can see Tom Jennings and others talking about BBSes in general and Fidonet. It’s somewhat a nice way-back machine and it made me to actually start my comeback to Fidonet. I tried to compile some projects from Sourceforge like fidoip or GoldEdPlus, but all projects were in a state where they didn’t compile without additional work under Debian. At least with those included debian/rules that have. 

So I decided to reactivate my old Fidonet software on my Amiga. Instead of GMS_Mailer I found AmiBinkd on Aminet which runs quite well. With that setup I was able to call to other Fidonet nodes and do some filerequests. That way I found out that 2:2452/250 is one of the still reachable Fidonet boxes in Germany and soon I became 2:2452/413. Still running on my Amiga with Mailmanager as Tosser and Reader and AmiBinkd as a mailer. Using Fidonet is quite different nowadays as you don’t need to call out via phone line anymore, but use Internet connections instead. Although this is nice and much faster and with no additional costs and you can use “crash mail”, it’s not the same fun as dialing into a mailbox by modem and hear the typical sqeaking sound of a modem connecting. So I bought a Zyxel U-1496E modem on Ebay for € 5.50 and connected it to my FritzBox 7490. This works quite well and I could place calls via the modem using TrapDoor as a mailer on my Amiga.

Anyway, using my Amiga was only a temporary solution to get me up & running again. The goal is to run a full featured Fidonet node on Debian on my colocated server in the datacenter and in the meanwhile I was able to switch the DNS record from my Amiga to the server in the datacenter, running with binkd from Debian and Husky suite as tosser.

Husky is complete Fidonet suite, including tosser, areafix, filefix, tic-file processor, etc. However there are no Debian packages available – at least not easily to find. Philipp Giebel pointed me in an Fidonet echoarea to his own personal repository for Debian and Raspbian: 

https://www.kuehlbox.wtf/index.php#repo

He was very helpful in getting me started on Linux with Husky and shared many of his config files with me. Big thanks for that! He also used our discussions to write a blog article about this. Although it’s German only you can find the necessary config files. You can find that on:

https://www.stimpyrama.org/blog/17-computer/138-ftnsetup

It covers nearly all necessary aspects:

• how to setup his repo in your apt sources
• install the necessary packages
• configuration of husky, binkd and goldedplus with example configs
• some tips & tricks like some keyboard shortcuts for goldedplus, etc.

So, this is really helpful for everyone that wants to join Fidonet as well.

You can use goldedplus as a reader for Fidonet, or when you just want to be a point and not a full node, you might want to try OpenXP on Linux. OpenXP includes everything you’ll need for a point, like a mailer, reader and tosser. You can even use it as a mail reader via POP3/IMAP or to read Internet News (aka newsgroups).

It’s still possible to run a Fidonet node on Amiga, on Linux and of course other operations systems like Windows and even OS/2. And with HotdogEd there is even Fidonet software available on your Android smartphone!

But why Fidonet if you already have the Internet at your fingertips? Well, this is something you need to decide for yourself, but for me there are several reasons why I joined Fidonet after 17 years of inactivity again:

• It’s not the Internet! 🙂  This means basically no spam mails. At least I didn’t experience any spam so far.
• It’s a small and welcoming community.
• There is not only Fidonet itself (with zone 1:* to 5:*), but other zones as well, like for example AmigaNet with zone 39:* or fsxNet with zone 21:*. FTN technology makes it easy to setup a own network based on a certain topic. 
• It’s a technology that enabled people to communicate worldwide with each other, long before the Internet was available for everyone! This is some kind of technical heritage I find worthwhile to preserve.
• Although most people of us can enjoy a free and open Internet, this is not valid for everyone in the world. Nowadays some regimes decide to block and censor the Internet for their citizens. Fidonet or FTN technology can enable those citizens to still communicate free and without censorship when even Tor is not working anymore because the Internet at all has been taken down in a country. Often enough you can still use phone lines and therefor you can use modems to connect to mailboxes and exchange mails and files. FTN is optimized for this kind of dialup connections and this is one of the main reasons why I don’t want to only offer connections via Internet but also by modem to my Fidonet node.

So, be invited to join Fidonet as well!

Today the server crashed several times and I was able to collect some more information than just the screenshots from IPMI/KVM console as shown in my last blog entry (full netconsole output is attached as a file): 

May 12 11:56:39 31.172.31.251 [829681.040596] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16.0-4-amd64 #1 Debian 3.16.7-ckt25-2
May 12 11:56:39 31.172.31.251 [829681.040647] Hardware name: Supermicro X9SRE/X9SRE-3F/X9SRi/X9SRi-3F/X9SRE/X9SRE-3F/X9SRi/X9SRi-3F, BIOS 3.0a 01/03/2014
May 12 11:56:39 31.172.31.251 [829681.040701] task: ffffffff8181a460 ti: ffffffff81800000 task.ti: ffffffff81800000
May 12 11:56:39 31.172.31.251 [829681.040749] RIP: e030:[<ffffffff812b7e56>]
May 12 11:56:39 31.172.31.251  [<ffffffff812b7e56>] memcpy+0x6/0x110
May 12 11:56:39 31.172.31.251 [829681.040802] RSP: e02b:ffff880280e03a58  EFLAGS: 00010286
May 12 11:56:39 31.172.31.251 [829681.040834] RAX: ffff88026eec9070 RBX: ffff88023c8f6b00 RCX: 00000000000000ee
May 12 11:56:39 31.172.31.251 [829681.040880] RDX: 00000000000004a0 RSI: ffff88006cd1f000 RDI: ffff88026eec9422
May 12 11:56:39 31.172.31.251 [829681.040927] RBP: ffff880280e03b38 R08: 00000000000006c0 R09: ffff88026eec9062
May 12 11:56:39 31.172.31.251 [829681.040973] R10: 0100000000000000 R11: 00000000af9a2116 R12: ffff88023f440d00
May 12 11:56:39 31.172.31.251 [829681.041020] R13: ffff88006cd1ec66 R14: ffff88025dcf1cc0 R15: 00000000000004a8
May 12 11:56:39 31.172.31.251 [829681.041075] FS:  0000000000000000(0000) GS:ffff880280e00000(0000) knlGS:ffff880280e00000
May 12 11:56:39 31.172.31.251 [829681.041124] CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033
May 12 11:56:39 31.172.31.251 [829681.041153] CR2: ffff88006cd1f000 CR3: 0000000271ae8000 CR4: 0000000000042660
May 12 11:56:39 31.172.31.251 [829681.041202] Stack:
May 12 11:56:39 31.172.31.251 [829681.041225]  ffffffff814d38ff
May 12 11:56:39 31.172.31.251  ffff88025b5fa400
May 12 11:56:39 31.172.31.251  ffff880280e03aa8
May 12 11:56:39 31.172.31.251  9401294600a7012a
May 12 11:56:39 31.172.31.251 
May 12 11:56:39 31.172.31.251 [829681.041287]  0100000000000000
May 12 11:56:39 31.172.31.251  ffffffff814a000a
May 12 11:56:39 31.172.31.251  000000008181a460
May 12 11:56:39 31.172.31.251  00000000000080fe
May 12 11:56:39 31.172.31.251 
May 12 11:56:39 31.172.31.251 [829681.041346]  1ad902feff7ac40e
May 12 11:56:39 31.172.31.251  ffff88006c5fd980
May 12 11:56:39 31.172.31.251  ffff224afc3e1600
May 12 11:56:39 31.172.31.251  ffff88023f440d00
May 12 11:56:39 31.172.31.251 
May 12 11:56:39 31.172.31.251 [829681.041407] Call Trace:
May 12 11:56:39 31.172.31.251 [829681.041435]  <IRQ>
May 12 11:56:39 31.172.31.251 
May 12 11:56:39 31.172.31.251 [829681.041441]
May 12 11:56:39 31.172.31.251  [<ffffffff814d38ff>] ? ndisc_send_redirect+0x3bf/0x410
May 12 11:56:39 31.172.31.251 [829681.041506]  [<ffffffff814a000a>] ? ipmr_device_event+0x7a/0xd0
May 12 11:56:39 31.172.31.251 [829681.041548]  [<ffffffff814bc74c>] ? ip6_forward+0x71c/0x850
May 12 11:56:39 31.172.31.251 [829681.041585]  [<ffffffff814c9e54>] ? ip6_route_input+0xa4/0xd0
May 12 11:56:39 31.172.31.251 [829681.041621]  [<ffffffff8141f1a3>] ? __netif_receive_skb_core+0x543/0x750
May 12 11:56:39 31.172.31.251 [829681.041729]  [<ffffffff8141f42f>] ? netif_receive_skb_internal+0x1f/0x80
May 12 11:56:39 31.172.31.251 [829681.041771]  [<ffffffffa0585eb2>] ? br_handle_frame_finish+0x1c2/0x3c0 [bridge]
May 12 11:56:39 31.172.31.251 [829681.041821]  [<ffffffffa058c757>] ? br_nf_pre_routing_finish_ipv6+0xc7/0x160 [bridge]
May 12 11:56:39 31.172.31.251 [829681.041872]  [<ffffffffa058d0e2>] ? br_nf_pre_routing+0x562/0x630 [bridge]
May 12 11:56:39 31.172.31.251 [829681.041907]  [<ffffffffa0585cf0>] ? br_handle_local_finish+0x80/0x80 [bridge]
May 12 11:56:39 31.172.31.251 [829681.041955]  [<ffffffff8144fb65>] ? nf_iterate+0x65/0xa0
May 12 11:56:39 31.172.31.251 [829681.041987]  [<ffffffffa0585cf0>] ? br_handle_local_finish+0x80/0x80 [bridge]
May 12 11:56:39 31.172.31.251 [829681.042035]  [<ffffffff8144fc16>] ? nf_hook_slow+0x76/0x130
May 12 11:56:39 31.172.31.251 [829681.042067]  [<ffffffffa0585cf0>] ? br_handle_local_finish+0x80/0x80 [bridge]
May 12 11:56:39 31.172.31.251 [829681.042116]  [<ffffffffa0586220>] ? br_handle_frame+0x170/0x240 [bridge]
May 12 11:56:39 31.172.31.251 [829681.042148]  [<ffffffff8141ee24>] ? __netif_receive_skb_core+0x1c4/0x750
May 12 11:56:39 31.172.31.251 [829681.042185]  [<ffffffff81009f9c>] ? xen_clocksource_get_cycles+0x1c/0x20
May 12 11:56:39 31.172.31.251 [829681.042217]  [<ffffffff8141f42f>] ? netif_receive_skb_internal+0x1f/0x80
May 12 11:56:39 31.172.31.251 [829681.042251]  [<ffffffffa063f50f>] ? xenvif_tx_action+0x49f/0x920 [xen_netback]
May 12 11:56:39 31.172.31.251 [829681.042299]  [<ffffffffa06422f8>] ? xenvif_poll+0x28/0x70 [xen_netback]
May 12 11:56:39 31.172.31.251 [829681.042331]  [<ffffffff8141f7b0>] ? net_rx_action+0x140/0x240
May 12 11:56:39 31.172.31.251 [829681.042367]  [<ffffffff8106c6a1>] ? __do_softirq+0xf1/0x290
May 12 11:56:39 31.172.31.251 [829681.042397]  [<ffffffff8106ca75>] ? irq_exit+0x95/0xa0
May 12 11:56:39 31.172.31.251 [829681.042432]  [<ffffffff8135a285>] ? xen_evtchn_do_upcall+0x35/0x50
May 12 11:56:39 31.172.31.251 [829681.042469]  [<ffffffff8151669e>] ? xen_do_hypervisor_callback+0x1e/0x30
May 12 11:56:39 31.172.31.251 [829681.042499]  <EOI>
May 12 11:56:39 31.172.31.251 
May 12 11:56:39 31.172.31.251 [829681.042506]
May 12 11:56:39 31.172.31.251  [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
May 12 11:56:39 31.172.31.251 [829681.042561]  [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
May 12 11:56:39 31.172.31.251 [829681.042592]  [<ffffffff81009e7c>] ? xen_safe_halt+0xc/0x20
May 12 11:56:39 31.172.31.251 [829681.042627]  [<ffffffff8101c8c9>] ? default_idle+0x19/0xb0
May 12 11:56:39 31.172.31.251 [829681.042666]  [<ffffffff810a83e0>] ? cpu_startup_entry+0x340/0x400
May 12 11:56:39 31.172.31.251 [829681.042705]  [<ffffffff81903076>] ? start_kernel+0x497/0x4a2
May 12 11:56:39 31.172.31.251 [829681.042735]  [<ffffffff81902a04>] ? set_init_arg+0x4e/0x4e
May 12 11:56:39 31.172.31.251 [829681.042767]  [<ffffffff81904f69>] ? xen_start_kernel+0x569/0x573
May 12 11:56:39 31.172.31.251 [829681.042797] Code:
May 12 11:56:39 31.172.31.251  <f3>
May 12 11:56:39 31.172.31.251 
May 12 11:56:39 31.172.31.251 [829681.043113] RIP
May 12 11:56:39 31.172.31.251  [<ffffffff812b7e56>] memcpy+0x6/0x110
May 12 11:56:39 31.172.31.251 [829681.043145]  RSP <ffff880280e03a58>
May 12 11:56:39 31.172.31.251 [829681.043170] CR2: ffff88006cd1f000
May 12 11:56:39 31.172.31.251 [829681.043488] —[ end trace 1838cb62fe32daad ]—
May 12 11:56:39 31.172.31.251 [829681.048905] Kernel panic – not syncing: Fatal exception in interrupt
May 12 11:56:39 31.172.31.251 [829681.048978] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)

I’m not that good at reading this kind of output, but to me it seems that ndisc_send_redirect is at fault. When googling for “ndisc_send_redirect” you can find a patch on lkml.org and Debian bug #804079, both seem to be related to IPv6.

When looking at the linux kernel source mentioned in the lkml patch I see that this patch is already applied (line 1510): 

        if (ha) 
                ndisc_fill_addr_option(buff, ND_OPT_TARGET_LL_ADDR, ha);

So, when the patch was intended to prevent “leading to data corruption or in the worst case a panic when the skb_put failed” it does not help in my case or in the case of #804079.

Any tips are appreciated!

PS: I’ll contribute to that bug in the BTS, of course!

So, my setup is as following after I solved the GlusterFS issue with rpcbind binding to all interfaces, although it has been configured to only listen to certain interfaces (solution was: simply remove all NFS related stuff):

On Dom0 (or the host machine) I run GlusterFS as a server on a small 1 GB LVM as part of a replicate with the VM that will do the actual Letsencrypt work: 

Volume Name: le
Type: Replicate
Status: Started
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: 192.168.x.254:/srv/gfs/le
Brick2: 192.168.x.1:/srv/gfs/le

This is to ensure that on reboot of the machine every other VM using Letsencrypt certs can mount the GlusterFS share, because the host machine will be there for sure whereas the other VM generating the certs with the letsencrypt.sh script might still be booting. And when the GlusterFS share is missing services will not start on the other VMs because of the missing certs, of course. So, the replica on the virtualization host (Dom0) is only acting as some kind of always-being-available network share, because, well, the other VM will not always be there… for example during a kernel update when a reboot is required.

The same setup is on my mailserver, acting as the second GlusterFS brick of that replica drive. The mailserver hosts the bind9 nameserver as well and I might do something that new domains with Letsencrypt certs get added to my DNSSEC setup as well. Of course, when the letsencrypt.sh script creates or updates the certs, it needs the certs being mounted in that configured location, so I needed to add a line to /etc/fstab: 

192.168.x.254:/le /etc/letsencrypt.sh/certs glusterfs noexec,nodev,_netdev 0 0

Basically the same needs to be done on the other VMs where you want to use the certs as well, but you may want to mount the share as read-only there.

The next step was a little more tricky. When letsencrypt.sh generates new certs, Letsencrypt will contact the webserver for that domain to respond to the ACME challenge. This requires that on each VM you want to use letsencrypt you have to run a webserver. Well, actually at least that there is somewhere a webserver that can answer these requests for that specific domain…

Now, the setup of the webserver (Apache in my case) is like this: 

I’m using the Apache macro module to make it more easy, so I generated two small configs in /etc/apache/conf-available and enabled them bei a2enconf: letsencrypt-proxy.conf to do some setup for proxying the ACME challenges to a common website called acme.example.org. And then letsencrypt-sslredir.conf to setup SSL redirection when everything is in place and the domain can be switched over to HTTPS-only.

letsencrypt-proxy.conf: 

<Macro le_proxy>
     ProxyRequests Off
     <Proxy *>
            Order deny,allow
            Allow from all
     </Proxy>
     ProxyPass /.well-known/acme-challenge/ http://acme.windfluechter.net/
     ProxyPassReverse / http://%{HTTP_HOST}/.well-known/acme-challenge/
</Macro>

letsencrypt-sslredir.conf:

<Macro le_sslredir>
    RewriteEngine on
    RewriteCond %{HTTPS} !=on
    RewriteRule . https://%{HTTP_HOST}%{REQUEST_URI}  [L]
</Macro>

So, after all the setup of a virtual host for Apache looks like this: 

<Macro example.org>
(lots of setup stuff)
</Macro>
<VirtualHost 31.172.31.x:443 [2a01:a700:4629:x::1]:443>
        Header always set Strict-Transport-Security “max-age=31556926; includeSubDomains”
        SSLEngine on
        # letsencrypt certs:
        SSLCertificateFile /etc/letsencrypt.sh/certs/example.org/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt.sh/certs/example.org/privkey.pem
        SSLHonorCipherOrder On
    Use example.org
    Use le_proxy
</VirtualHost>
<VirtualHost 31.172.31.x:80 [2a01:a700:4629:x::1]:80>
    Use example.org
    Use le_proxy
    Use le_sslredir
</VirtualHost>

le_sslredir is only needed when you are sure that you want all traffic being redirected to HTTPS. For example when your blog is listed on planet.debian.org or other Planets you might want to omit this from your HTTP config because bug #813313 is not yet solved. 

In the end, when creating a new Letsencrypt cert, you need to add the le_proxy macro to your website, add the domain to letsencrypt.sh config in /etc/letsencrypt.sh/domains.txt and then the scripts will request a new cert from Letsencrypt, handling the ACME challenge stuff via the URL redirection in le_proxy being redirected to your acme.exmaple.org site and finally writes your new cert to the GlusterFS share. From that share you can then use the new cert on all needed VMs, be it your mailserver, webserver or XMPP/SIP server VMs. 

At least this works for me.

UPDATE:
Of course you should be careful about your file permissions on that GlusterFS share, so that the automatic key renewal works, but also without too many permissions granted that everyone can obtain your private keys.

Whereas Bind9 is well-known, well documented and serving my zones well for years. But I got the impression that DNSSEC is a more or less a mess with Bind9 as it was added on top of it without being well integrated. On the contrary, DNSSEC support is built into PowerDNS as if it was well integrated from scratch on a design level. But on the other hand there doesn’t seem much ressources available on the net about PowerDNS. There’s the official documentation, of course, but this is not as good as the Bind9 documentation. On the plus side you can operate PowerDNS in Bind mode, i.e. using the Bind9 configuration and zone files, even in hybrid-mode that enables you to additionally run a database-based setup.

So, I’m somewhat undecided about how to proceed. Either stay with Bind9 and DNSSEC, completely migrate to PowerDNS and a database setup or use PowerDNS with bind backend? Feel free to comment or respond by your own blog post about your experience. 🙂

UPDATE: Problem solved, please read DNSSEC – Part 2

Debian-ports.org shows now that we’re from 20% keeping up to about 60% keeping up. The installed packages went from ~1900 to about 3800 and we even triggered 200 packages from BD-uninstallable to Needs-Build: 

  wanna-build statistics - Fri Jan 18 06:52:36 CET 2013
  -----------------------------------------------------

Distribution unstable:
---------------------
Installed       :  3868 (buildd_m68k-ara5: 488, buildd_m68k-arrakis: 20,
                         buildd_m68k-elgar: 106, buildd_m68k-vivaldi: 80,
                         tg: 1412, unknown: 1761, wouter: 1)
Needs-Build     :  3500
Building        :    26 (buildd_m68k-ara5: 1, buildd_m68k-elgar: 1,
                         buildd_m68k-vivaldi: 1, tg: 23)
Built           :     0
Uploaded        :     1 (tg: 1)
Failed          :    34 (buildd_m68k-ara5: 17, tg: 17)
Dep-Wait        :     4 (tg: 4)
Reupload-Wait   :     0
Install-Wait    :     0
Failed-Removed  :     0
Dep-Wait-Removed:     0
BD-Uninstallable:  2320
Auto-Not-For-Us :   188
Not-For-Us      :     9
total           :  9975

 38.78% (3868) up-to-date,  38.79% (3869) including uploaded
 35.09% (3500) need building
  0.26% ( 26) currently building
  0.00% (  0) already built, but not uploaded
  0.38% ( 38) failed/dep-wait
  0.00% (  0) old failed/dep-wait
 23.26% (2320) not installable, because of missing build-dep
  1.88% (188) need porting or cause the buildd serious grief (Auto)
  0.09% (  9) need porting or cause the buildd serious grief

So, overall we’re performing fine. The mention on Slashdot even brought up new donors of hardware. Someone offered SCSI/SCA disks up to 73 GB in size and another person even offered several Amigas, from which we’ll using a Amiga 2000 with Blizzard 2060 accellerator card as a new buildd.

This leads me to a medium-sized drawback: we actually have several Amigas with a Blizzard 2060 as buildds. Unfortunately there’s no SCSI driver in current kernels for that kind of hardware. This results in the effect that we can’t use as many machines as we could. Currently we are using 3 active buildds and some Aranym VMs running on Thorsten Glasers hosts. We could add 4 more buildds when there would be a working SCSI driver.

So, if anyone likes to contribute to the m68k port and loves kernel hacking, this would be a great way to help us. 🙂 

Panopticon from Tim Weskamp on Vimeo.

Bei INDECT handelt es sich um ein System, bei dem verschiedene Überwachungssysteme gekoppelt und zusammengeführt werden. Also zum Beispiel diverse Überwachungskamera, anhand derer man verdächtige Personen aus Menschenmengen herausfiltern und verfolgen will. Gleichzeitig sollen auch diverse andere Quellen im Internet angezapft und durchsucht werden. Zudem sollen auch Überwachungsdrohnen zum Verfolgen von verdächtigen Personen eingesetzt werden. Das ganze natürlich vollautomatisch.

Ich glaube, ich muss nicht betonen, daß dies ein Albtraum in Sachen Privatsphäre, Rechtsstaatlichkeit und Bürgerrechte ist. Alles Hirngespinste? Mitnichten! Laut Futurezone soll INDECT zur diesjährigen Fußball-EM in Polen in einem Testlauf starten.

Es ist Zeit zum Handeln!