Familienbesuch beim Arzt

Ein Besuch beim Arzt kann ausvielen Gründen sehr aufschlußreich sein. Zum Einem bekommt Aufklärung über sein eigenes Leiden, zum Anderen ist das Wartezimmer ein Spiegel der Gesellschaft. Gesellschaft ist auch das heutige Thema. Vor einigen Jahren hatte ein Arzt in seiner Praxis mal dein Schild aufgehängt, das muslimischen Besuchern rät, Ihre Familien zu Hause zu lassen, da es im Wartezimmer ohnehin schon so beengt zugeht. Der Hinweis war seiner Meinung nach nötig, da muslimische Familien mit Kind und Kegel anreisen würden. Es kam wie es kommen mußte, jemand zog die Rassismuskarte und die neue Kuh wurde durchs Dorf getrieben. Am Ende verschwand das Schild, aber das Problem blieb.

Heute sahs ich im Wartezimmer und mußte feststellen, das Opa,Mutter,Kind und Vater,Mutter und Kind, oder Mutter,Bruder, Kind eintraten. Nicht einer davon war Muslime, das nur am Rande vermerkt. Die Unsitte, mit der ganzen Familie und/oder dem Freundeskreis zum Arzt zugehen, setzt sich offenbar durch. Demnächst lädt man noch seine Facebookfreunde dazu ein.

Leute, das ist ein Arzt, keine Begegnungsstätte. Alleine ist sicher langweilig, aber zum Arzt sollten Erwachsene Menschen alleine gehen können. Wieso muß da ständig einer mitgehen? In vier Stunden waren grademal vier Menschen alleine da, der Rest kam mit Verstärkung. In so einem Wartezimmer ist es so schon ungemütlich, aber mit all dem Geplapper kommt man sich vor wie in der Schule auf dem Pausenhof. Es hilft auch nicht, den Namen desjenigen zu verstehen, der aufgerufen wird.

Mein Aufruf an Sie lautet, gehen Sie man ganz alleine zum Arzt. Eine neue Erfahrung wartet auf Sie. Da Sie Ihr Handy mitnehmen werden, sind Sie sowieso nicht alleine.

Updateprobleme mit der libdvdcss2 beheben

Stört Sie diese Meldung auch grade ?

--> Abhängigkeitsauflösung beendet
Fehler: Paket: libdvdcss2-1.2.13-7.fc20.x86_64 (@/libdvdcss2-1.2.13-7.fc20.x86_64)
Benötigt: /usr/sbin/ldconfig
Entfernen: glibc-2.18-12.fc20.i686 (@updates)
Nicht gefunden
Aktualisiert durch: glibc-2.18-14.fc20.i686 (updates)
Nicht gefunden
Sie können versuchen, mit --skip-broken das Problem zu umgehen.

Der Hinweis, der nie funktioniert, ist das mit dem Skipbroken 🙂

Heute machen wir es kurz, hier die Lösung:

1. Auf dieser Webseite die libdvdcss und libdvdcss2 RPM Dateien runterladen :

ftp://rpmfind.net/linux/atrpms/f20-x86_64/atrpms/stable/

2. sudo  yum erase libdvdcss*

3. yum -y update

4. yum install libdvdcss*rpm

Das wars schon. Die Abhängigkeit wird beim Installieren gesetzt. Im eigentlichen RPM ist gar keine drin.

Tomcat: Manager App nicht verfügbar

Kleine Ursache, großes Tralala

Einer meiner Tomcats hat mich heute mit der Meldung beglückt, daß er die Resource „/manager/html“ nicht zur Verfügung stellen könne, obwohl die Anwendung installiert ist. Das ist ist immer, da diese zum Defaultzustand eines Tomcats dazugehört. Darüber lassen sich Webanwendungen als WAR File installieren.

Jetzt findet man im Netz alle erdenklichen Ansätze, leider half heute nicht einer.

Das erste was auffiel war, daß das Manager Verzeichnis zwar da war, aber die anderen normalen Verzeichnisse im webapps Verzeichnis  nicht:

drwxr-xr-x  5 root root     4096 13. Aug 2013  host-manager
drwxr-xr-x  5 root root     4096 13. Aug 2013  manager
drwxr-xr-x  3 root root     4096 18. Feb 2012  plattform
drwxr-xr-x  3 root root     4096 13. Aug 2013  ROOT

Wenn das nicht der Fall ist, kann es gehen, muß aber nicht. Diese holt man sich aus dem Tomcat ZIP/TGZ File. Wenn man dies nicht mehr zur Hand hat, einfach nochmal von der Webseite runterladen.

Die eigentliche Störungsquelle

Damit habe ich dann nicht gerechnet. Die eigentliche Störungsquelle war trivialer Natur. Die früher installierte Webanwendung war defekt und verhinderte den korrekten Start des Tomcats, obwohl im Logfile dazu kein Hinweis stand! Mit sowas rechnet man nicht, daß bis dato die Webanwendung lief.

In dem Fall einfach von Hand die alte WAR Datei aus dem Webapps Verzeichnis entfernen und den Tomcat neustarten.

Danach war auch der Manager wieder erreichbar.

 

 

 

 

 

 

Error 2006: Server has gone away

Diese falsche Fehlermeldung eines MySQL Servers, verleitet einen unweigerlich dazu an einen echten Fehler des Servers zu denken. Glücklicherweise kann es auch andere Fehlergründe geben. Einen davon, zeigen wir Ihnen heute:

Wenn Sie einen SQL DUMP importieren, der 2,4 MB groß ist, aber sqlmäßig nur aus einer Zeile des Schemas:

insert into datentabelle ( spalte1,spalte2,spalte3) values (1,2,3),(2,3,4) ,(3,4,5) ,(4,5,6) ,(2384,4233,5674),..... 2 MB später ... ;

besteht, müssen Sie sich nicht wundern, wenn es nicht geht. Die Zeile ist schlicht intern zu lang.

Abhilfe schafft der MySQL eigene Befehl replace :

 replace ")," ");insert into datentabelle  ( spalte1, spalte2, spalte3 ) values " --  /tmp/output-1.sql

Wenn Sie diesen neuen SQL Dump einspielen, wird dies anstandslos verarbeitet werden.

Schlecht: Mit dem DoD prahlen …

Also an machen Tagen muß man wahrlich am Verstand der Spammer zweifeln. Nun war mir das schon lange klar, aber was heute reingekommen ist, ist an Dämlichkeit fast schon nicht mehr zu überbieten 🙂

Der Mailheader

Return-path: <bestellung@otto.de>
Envelope-to: XXX
Delivery-date: Tue, 09 Sep 2014 12:52:25 +0200
Received: from ns3436350.ip-188-165-196.eu ([188.165.196.19])
	by XXXXX with smtp (Exim 4.80.1)
	(envelope-from <bestellung@otto.de>)
	id 1XRJyD-0004oD-Cv
	for XXX; Tue, 09 Sep 2014 12:50:25 +0200
Received: from pfjkqmlf (7.148.90.216)
	by ns3436350.ip-188-165-196.eu; Tue, 9 Sep 2014 12:51:01 +0200
Date: Tue, 9 Sep 2014 12:51:01 +0200
From:  <bestellung@otto.de>
X-Mailer: The Bat! (v2.01)
Reply-To:  <datenschutz@otto.de>
Message-ID: <023872403.20140518152630@otto.de>
To:

Das es sich hierbei um einen Versand eines als ZIP gepackten Trojaners für Windows handelt, sei nur am Rande erwähnt, da es nicht wichtig ist für die Geschichte.

Wie man im Header sieht, gibt es zwei Received-Zeilen. Jetzt muß man die von OBEN nach UNTEN lesen, die oberste ist die LETZTE Stelle, also die, welche die Email angenommen hat auf unserem Server.

Folglich hat unser Server die Mail von „188.165.196.19“ bekommen, einem Server bei OVH in Frankreich. Selbiger dürfte gehackt sein und als Spamschleuder mißbraucht worden sein.

Nun sagt aber der zweite Received-Header, daß OVH die Email von 7.148.90.216 bekommen haben will, und hier wirds spannend. Das ist nicht irgendein Server im Netz!

 

NetRange:       7.0.0.0 – 7.255.255.255
CIDR:           7.0.0.0/8
OriginAS:
NetName:        DISANET7
NetHandle:      NET-7-0-0-0-1
Parent:
NetType:        Direct Allocation
RegDate:        1997-11-24
Updated:        2006-04-28
Ref:            http://whois.arin.net/rest/net/NET-7-0-0-0-1

OrgName:        DoD Network Information Center
OrgId:          DNIC
Address:        3990 E. Broad Street
City:           Columbus
StateProv:      OH
PostalCode:     43218
Country:        US

DoD Network Information Center steht für Department of Defense und damit für das US Verteidigungsministerium, sprich das Pentagon. Vermutlich ist es eine Außenstelle.

Was läßt jetzt Zweifel an der Story aufkommen ?

Received: from ns3436350.ip-188-165-196.eu ([188.165.196.19])
	by XXXXX with smtp (Exim 4.80.1)
	(envelope-from <bestellung@otto.de>)
	id 1XRJyD-0004oD-Cv
	for XXX; Tue, 09 Sep 2014 12:50:25 +0200
Received: from pfjkqmlf (7.148.90.216)
	by ns3436350.ip-188-165-196.eu; Tue, 9 Sep 2014 12:51:01 +0200
Date: Tue, 9 Sep 2014 12:51:01 +0200

Wenn man jetzt weiß, daß der oberste der Letzte in der Kette ist, wie kann er kann VOR dem Ersten in der Kette, die Email bekommen haben ?  Antwort: Hat er nicht. Der Spammer hat das einfach erfunden um von sich abzulenken.

Jetzt wäre jede andere IP auf der Erde sinnvoller gewesen als die vom DoD, weil dadurch wird jetzt jemand mit guten Kontakten bei OVH anfragen und die eigentlichen Täter ermitteln wollen. Deswegen kann man nur raten: Keine Ips vom Pentagon benutzen, die nehmen das sehr persönlich 😉