i live in my own little world, but it's ok… they know me here

nach meiner ersten erfahrung mit dem eTicket des RMV, gestern meine zweite:

die kontrolleure  waren in der sbahn unterwegs. nachdem ich meine tolle rfid  plastickkarte gezueckt hatte, hat der kontrolletti einfach abgewunken  und ist weiter gegangen.
ok, ich werde mich nicht darauf verlassen, dass das jedes mal so klappt.

was manche hersteller heute (2016!) noch in ihre software einbauen… unglaublich. bei einem dieser mistigen programme kann man beim setup z.b. “ODBC and Access Support” auswaehlen, was wohl den zugriff auf irgendwelche datenbanken erlauben soll. eigentlich fand ich den beschreibenden hinweis ganz nett:

“These Components are probably already on your system, but there is no harm in checking”

… schadet also nix sollte man meinen.

aber was dann damit ins windows/system32 verzeichnis installiert wird, laesst die kinnlade erstmal runter klappen:

dll’s usw. aus dem jahre 1996… darunter ne vba runtime 3.0.. au backe. das mag ich schon als grob fahrlaessig bezeichnen.

auf diaspora* gesehen… das darf man der restlichen welt nicht vorenthalten. da koennt ich mich wegschmeissen.

yeah.. im cyber-angst-mach-fernsehen (hier: ncis) ist auch endlich das ipv6 zeitalter angebrochen. wie auch schon zu ipv4 zeiten natuerlich mit ungueltigen ip adressen

😉

wann wird diese mistige software endlich eingestampft?

gerade im mail.log gefunden:

Feb 29 21:17:50 mx amavis[3809]: (03809-12) check_header: 8, Header field occurs more than once: “MIME-Version” occurs 3 times

und im header nachgesehen…

Date: Mon, 29 Feb 2016 21:17:46 +0100
[…]
MIME-Version: 1.0
Subject: AW: 3.3.
X-Mailer: IBM Notes Traveler 9.0.1.0 Build 201401251817
X-MIMETrack: Itemize by Notes Server on *******/***/****-***(Release 9.0.1|October 14, 2013) at
29.02.2016 21:17:46,
Serialize by Router on *******/***/****-*** at 29.02.2016 21:17:47
MIME-Version: 1.0
MIME-Version: 1.0
Content-Type: multipart/mixed;

wtf? drei mal die mime version macht nix besser…

aus einer buchungsbestaetigung:

ich dachte, dass kleine kinder das saucool finden. aber jetzt ist der “trend” scheinbar bei jugendlichen angekommen

jedes unternehmen hat unentdeckte sicherheitslecks. nicht nur eins. insofern ists ja fast wieder richtig, weil das jedes vierte und eins impliziert. 😉

jede 4. werbeagentur macht eine scheiss werbung… na? genauso doof. das machense naemlich alle.

mein opsview hat die tage wieder mal gestreikt. ich erinnerte mich, doch irgendwo schonmal was aufgeschrieben zu haben. in den entwuerfen meines blogs bin ich fuendig geworden. wie man am datum der logeintraege sehen kann, ists schon ein paar tage her. ich hab das ganze mal aktualisiert und voila.. da isses:

####

heute morgen hat mein nagios bzw. opsview seinen dienst quittiert. im logfile waren solche eintraege zu finden:

[2015/04/12 02:09:45] [import_ndologsd] [FATAL] Error for 1428796429.397065 in handle_SERVICECHECKDATA: Insert failed: The table ‘nagios_servicechecks’ is full
[2015/04/12 02:09:45] [import_ndologsd] [WARN] Failed to import 1428796429.397065
[2015/04/12 02:09:45] [import_ndologsd] [FATAL] Error for 1428796433.896315 in handle_SERVICECHECKDATA: Insert failed: The table ‘nagios_servicechecks’ is full
[2015/04/12 02:09:45] [import_ndologsd] [WARN] Failed to import 1428796[2015/04/12 07:38:50] [nrd] [WARN] 2015/04/12-07:38:50 Server closing!

ok, die mysql datenbank ist 22GB gross und die tabelle ‘nagios_servicechecks’ hat rund 60 millionen eintraege. was der limitierende faktor war, konnte ich auf die schnelle nicht rausfinden. normalerweise sollten in dieser tabelle nur daten von einer woche vorgehalten werden. also in mysql den befehl ausfuehren:

DELETE FROM nagios_servicechecks WHERE start_time <= '2014-07-01 00:00:00';

ursache: fehlende cronjobs! bei der letzten migration auf einen anderen server sind die entsprechenden crontab eintraege fuer den nagios user "verloren" gegangen.
dieser cronjob sollte fuer den user nagios eingerichtet sein:

11 4 * * * . /usr/local/nagios/bin/opsview_master_housekeep

aus “seo gruenden” wegen pagerank und performance und so werden gerne bilder von einer anderen oder einer subdomain ausgeliefert.
wie man das mit einfachen mitteln mit wordpress macht, beschreibe ich hier.

frueher gabs in wordpress in den einstellungen unter “media” diese beiden werte:

mit irgendeiner version verschwanden diese aus der gui. um diese trotzdem wieder zu setzen, kann man sich unterschiedlicher methoden bedienen. man kann z.b. ein plugin wie “WP Original Media Path” nutzen, welches diese beiden felder wieder herstellt. das plugin kann man nach dem setzen wieder deinstallieren.

oder aber man setzt einfach diese beiden werte in der datenbank in der “options” tabelle:

weiterhin muss man noch einen neuen vhost im webserver anlegen. im beispiel ist es “img.sd.vc”. das document root dieses vhosts ist identisch mit dem der wordpress installation plus dem verzeichnis “wp-content/uploads“. wenn das document root der wordpress installation also “/var/www/domain.tld/” ist, dann ists fuer den vhost fuer die media dateien “/var/www/domain.tld/wp-content/uploads/”

da diese einstellungen nur bei neuen posts und pages greifen, funktioniert das wordpress erstmal weiter wie gehabt. um die alten eintraege anzupassen, muss man die image urls direkt in der datenbank aendern. ein beispiel hier:

UPDATE wp_posts SET post_content = REPLACE(post_content,'https://www.domain.tld/wp-content/uploads/','https://img.domain.tld/')

das wars.. garnicht so schwer 😉