Search Results for: content

“locked content”

man ist ja schon gewohnt, dass auf es einem auf irgendwelchen webseiten schwer gemacht wird, das zu sehen, was man ueber eine suchmaschine gefunden hat. aber bei sowas platzt mir ja fast der kragen:

20160125_wait300seconds

ja wie bitte?? 5 minuten warten, bis der scheiss angezeigt wird? oder eben auf social media kack teilen/folgen/whatever. es gibt doch bestimmt auch leute, die diesen social media kram nicht mit machen? ich mache da zwar teilweise sehr wenig mit, aber ich werde mich mit sicherheit nicht noetigen lassen, da nen knopf zu druecken… und schon garnicht werde ich 5 minuten warten um den dreck anzusehen. tab cloesd… fertig.

fritzbox reboot mit cronjob

seit super vectoring spinnt meine fritzbox 7590 alle paar wochen mal rum. dann hat das entertain tv aussetzer und laeuter so spaesschen. also ein kleines scriptchen auf einen der linux server drauf, welches die fritzbox regelmaessig neu starten soll. auf der fritzbox extra einen user “reboot” dafuer angelegt und ihm die Berechtigung “FRITZ!Box Einstellungen” gegeben, den port 49000 zur fritzbox in der firewall freigeschaltet und einen woechentlichen cronjob dafuer angelegt. und hier das script:

#!/bin/bash

IP="10.10.10.1"
FRITZUSER="reboot"
FRITZPW="strongpassword"
location="/upnp/control/deviceconfig"
uri="urn:dslforum-org:service:DeviceConfig:1"
action='Reboot'

curl -k -m 5 --anyauth -u "$FRITZUSER:$FRITZPW" http://$IP:49000$location -H 'Content-Type: text/xml; charset="utf-8"' -H "SoapAction:$uri#$action" -d "" -s > /dev/null

(nicht selbst erfunden, sondern irgendwo abgeschaut. finde bloss nicht mehr wo…)

apache2 “Negotiation: discovered file(s) matching request: None could be negotiated”

neulich… beim umzug einer fotogalerie auf einem anderen webserver kam neben der entsprechenden fehlermeldung im browser (file not found) diese fehlermeldung im error.log:

AH00687: Negotiation: discovered file(s) matching request: /var/www/htdocs/domain.tld/index (None could be negotiated)., referer: http://domain.tld/

nach etwas googlen war mir klar, dass das mit der option “MultiViews” zusammenhaengt.

die apache webseite weiss dazu:

The effect of MultiViews is as follows: if the server receives a request for /some/dir/foo, if /some/dir has MultiViews enabled, and /some/dir/foo does not exist, then the server reads the directory looking for files named foo.*, and effectively fakes up a type map which names all those files, assigning them the same media types and content-encodings it would have if the client had asked for one of them by name. It then chooses the best match to the client’s requirements.

heisst also… beim aufruf von “http://domain.tld/index” schaut der webserver, ob er eine datei “index” mit einer irgendeiner dateiendung findet. er haette eigentlich in diesem falle die vorhanden index.php finden und nehmen sollen…. hat er aber nicht. grund dafuer war, dass der webserver nicht wusste, was er mit der dateianedung “php” anfangen soll.

bei einem debian stretch wird der umgang mit den mimetypes mit dem apache modul “mime” geregelt. am anfang der datei /etc/apache2/mods-available/mime.conf steht geschrieben:



   TypesConfig points to the file containing the list of mappings from
   filename extension to MIME-type.
   #
   TypesConfig /etc/mime.types

also husch in der /etc/mime.types geschaut und gesehen, dass diese zeile auskommentiert ist:

# application/x-httpd-php      phtml pht php

kommentarzeichen davor weg, speichern, apache neu starten und gut.

kaffeespezialitaeten mit milch enthalten laktose

falls du es noch nicht wusstest… kaffeespezialitaeten mit milch enthalten laktose. OMG. muss man das echt draufschreiben? ach ja. gibt ja auch kaffeebecher mit der aufschrift “caution – hot content”.. und in mikrowellen darf man keine tiere trocknen.

domino/notes bitte in die tonne

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…

wordpress: bilder von einer subdomain ausliefern

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:

20160219_wp_media_settings

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:

20160219_db

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 😉

nur noch ssl bitte – HSTS aktivieren und prüfen

um HSTS zu aktivieren, muss man einfach in die .htaccess datei folgendes reinschreiben:


# HSTS (mod_headers is required) (15768000 seconds = 6 months)
Header always add Strict-Transport-Security "max-age=15768000"

falls der apache das headers modul noch nicht geladen hat, auf der commandline ausfuehren:

a2enmod headers

sofern das notwendig war, bitte den apache neu starten.

und dann einfach pruefen mit diesem befehl:

curl -si sd.vc | grep Strict

der output sollte so aussehen:

Strict-Transport-Security: max-age=15768000

uzr sicherheit, falls doch ein browser ankommt, der kein HSTS unterstuetzt noch diesen spruch in die .htaccess:


RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule .* https://ww.sd.vc%{REQUEST_URI} [last]

zusammen mit ein paar wichtigen einstellungen an den ciphers etc. (spaeter mehr dazu) gibt das beim Test von Qualys SSL Labs ein A+ ranking 🙂

20150618_aplus

damit die ganze seite dann nur noch ueber https geht, muss man in den einstellungen von wordpress (settings -> general) die url auch noch auf https anpassen:

20150618_wordpress_https

und da wordpress die dumme eigenheit hat, die eigenen urls (bilder, links) als absolute links abszuspeichern, muss man die auch noch aendern.

UPDATE wp_posts SET post_content = REPLACE(post_content,'http://ww.sd.vc','https://ww.sd.vc')

postfix: hostname des mailservers als absender- oder empfaengerdomain

mir kam schon ein paar mal ein postfix unter, der komische sachen mit email headern gemacht hat. da stand z.b. sowas drin:

To: “irgendwas@domain.tld”@mein.mailserver.tld

das kann z.b. auftreten, wenn man amavis als contentfilter in der master.cf eingebunden hat. dann sollte man in der master.cf beim eintrag des smtp-servers von amavis folgende option mitgeben:

-o local_header_rewrite_clients=

ursache dafuer ist der standardwert “local_header_rewrite_clients=permit_inet_interfaces”, der zutrifft, wenn die mails von amavis auf localhost:10025 wieder rein kommen.

firefox addon: flashblock und youtube

das flashblock addon fuer den firefox ist echt gold wert. es spart nicht nur nerven, sondern schont auch unterwegs den akku des notebooks. seit irgendeinem update funktioniert das flashblock addon fuer den firefox allerdings noch besser als es eigentlich soll. mir war es naemlich nicht mehr moeglich, auf youtube.com videos anzusehen. auch eine aufnahme von “https://www.youtube.com” in die liste der ausnahmen hat nichts gebracht. abhilfe geht wie folgt:

den firefox profile ordner oeffnen. den findet man am einfachsten so (hier anhand FF auf OSX):

im menue auf “Hilfe” klicken, dann auf “Informationen zur Fehlerbehebung”

20150403_ff1

“Profilordner” -> “Im Finder anzeigen”

20150403_ff2

der profilordner hat einen zufaelligen namen. in meinem falle sowas wie “suxl3axc.default”. diesen ordner oeffnen und darin den ordner “chrome” oeffnen. falls der ordner “chrome” nicht exisitert, dann einen mit diesem namen erstellen.

danach eine datei mit dem namen “userContent.css” anlegen und mit diesem inhalt befuellen:

#theater-background {display:none}

die datei speichern und firefox neu starten. that’s it.

made my day: fileshare-terror-nofly-win-win

muhahaha…

20150401_winwin

echt… also… eine win-win situation! so haelt man normale menschen davon ab, filesharing zu machen… schliesselich wollen sie ja irgendwann in den urlaub. mit gefaengnisstrafen kann man ja niemanden abschrecken. und die terroristen machen kein filesharing mehr, weil sie ja unbedingt fliegen muessen um terror zu machen. die content mafia kommt also an ihr geld, weil es terroristen gibt. oder geht nun der terrorismus zurueck, weil die nicht auf die neuesten lieder von lady gaga verzichten koennen und kein geld haben, sich diese zu kaufen? bwhaaa.. es gibt NUR gewinner dabei 😉