Archiv 25. Mai 2014

Sonntag, 25. Mai 2014

Einem mit puPHPet aufgesetztem Vagrant schreibenden Zugriff auf das synchronisierte wwwroot des Host-Systems geben

Das Web ist voll von Diskussionen zu diesem Thema, und einige Tipps erfordern zeitintensive Eingriffe in die Konfiguration:

Folgende Konfigurationsanpassung in der Vagrantfile-Konfigurationsdatei hat bei mir das Problem gelöst, dass Apache im VMBox-Container nicht in das synchronisierte wwwroot auf meinem Mac OS X-Host schreiben konnte:

...
data['vm']['synced_folder'].each do |i, folder|
    if folder['source'] != '' && folder['target'] != ''
      nfs = (folder['nfs'] == "true") ? "nfs" : nil
      if nfs == "nfs"
        config.vm.synced_folder "#{folder['source']}", "#{folder['target']}", id: "#{i}", type: nfs
      else
        config.vm.synced_folder "#{folder['source']}", "#{folder['target']}", id: "#{i}", type: nfs,
          group: 'www-data', user: 'www-data', mount_options: ["dmode=777", "fmode=777"]
      end
    end
  end
...

Mit dem Parameter mount_options: ["dmode=777", "fmode=777"] schreiben die Web-Applikationen ihre Cache-Dateien munter und fröhlich in das wwwroot des Host-Systems.

Und ja, mir ist ehrlich gesagt schnurz, wenn die Entwickler ideologisch-religiöse Gründe vorbringen, wieso dies eine ganz, ganz schlechte Idee ist … ich verwende Vagrant, um genau solchen Konfigurationsalpträume aus dem Weg zu gehen und innert Minuten auf all meinen Entwicklungssystemen eine homogene Entwicklungsumgebung zu haben.

Etwas gutes hatten die Probleme aber: Ich habe eine meiner Web-Applikationen so angepasst, dass sie nun beim Starten auch prüft, ob sie überhaupt Schreibberechtigung auf das Cache-Verzeichnis hat.

Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 25. Mai 2014

lftp mit Zertifikatsproblemen

Wenn lftp auf Grund von Zertifikatsproblemen bockt …

Certificate verification: subjectAltName does not match »domain.tld«

… wechselt man folgendermassen auf unsichere FTP-Verbindungen:

$ lftp -e 'set ftp:ssl-allow off; cd public_html; put index.php; bye' www.domain.tld

Via: Lftp Fatal Error: Certificate Verification: Not Trusted

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 25. Mai 2014

curlftpfs unter Mac OS X

Ergänzungen meiner IT-Installation machten es kürzlich nötig, dass ich neu auch unter Mac OS X curlftpfs einsetze, um per FTP von bestimmten Web-Sites Sicherheitskopien anzufertigen (Stichwort: Vagrant und puPHPet, dank an Christian für die „Erleuchtung“!)

Entweder hat sich curlftpfs in der Zwischenzeit weiterentwickelt, oder unter Mac OS X läuft der „Karren“ etwas anders. Auf jeden Fall habe ich bei der Adaptierung meiner Linux-Scripte unter Mac OS X folgendes gelernt:

MacPorts

curlftpfs installiert man sich folgendermassen:

# port install curlftpfs

Wenn man curlftpfs dann zum ersten Mal ausführt, warnt einem Mac OS X (hier: 10.9 Mavericks), dass man eine Kernelextension aktiviert, welche von einem unbekannte Entwickler kompiliert wurde. Henusode … (NSA lässt grüssen). Die Warnung ist seither nie mehr aufgetaucht; ich hoffe, dass dies auch nach einem Reboot so bleibt.

Geduldiges mounten

In Tests hat sich herausgestellt, das das Mounten von FTP-Volumen längert dauert als unter Linux. Meinem Script habe ich deshalb folgendermassen Geduld beigebracht:

...
MAXIMUMITERATIONS=5000
...
TIME=$(date +%H:%M:%S)
echo -n "Checking whether mountpoint is populated ($TIME): "

COUNTER=0
while [ ! -d "$SOURCE" ]
do
	let COUNTER=COUNTER+1
	echo -n "."
	
	if [ "$COUNTER" -eq "$MAXIMUMITERATIONS" ]
	then
		echo "Mountpoint still not available after $COUNTER iterations. Aborting."
		exit 1
	fi
done
...

In der Variable $SOURCE ist der Pfad zu einem auf dem FTP-Server vorhandenen Unterordner gespeichert. Sobald bash meldet, dass dieser nun verfügbar ist, kann ich mit den Kopieraktionen beginnen.

Zugriff verweigert

Bei den Tests traf ich auch auf ein Berechtigungsproblem: Manchmal wurde rsync beim Traversieren von FTP-Ordnerstrukturen der Zugriff verweigert. Nach einigem Pröbeln realisierte ich, dass einige Ordner auf den FTP-Servern das Execution-Bit nur für den Owner gesetzt hatten, nicht aber für die Gruppe oder gar Dritte. In einem Fall passte ich die Berechtigungen über den FTP-Client meiner Wahl an, in einem anderen Fall war ich mir todsicher, dass ich allen Serverbenutzern definitiv keine Berechtigung zum Lesen aller meiner Dateien geben wollte. Was nun?

Folgende Option verhindert, dass curlftpfs respektive FUSE bei FTP-Verbindungen Berechtigungschecks durchführen (dies ist hier Aufgabe des FTP-Servers — gibt dieser Zugriff auf eine Datei, hat definitiv schon eine zuverlässige Authentifizierung und Authorisierung stattgefunden):

$ curlftpfs -o defer_permissions ...

Zeichensalat

In meinem älteren Blog-Artikel zu curlftpfs habe ich gezeigt, wie der Zeichensatzproblematik unter Linux begegnen kann. Unter Mac OS X klappt dies so nicht. Stattdessen sind folgende Werte an curlftpfs zu übergeben:

$ curlftpfs -o modules=iconv,from_code=latin1

Quelle: International characters (e.g. Swedish åäö) in remote file system folder names makes Finder hang #71

Den Ausgabezeichensatz finden FUSE respektive curlftpfs offenbar selber heraus.

Dem Parameter from_code ist natürlich der Zeichensatz des FTP-Servers mitzugeben. Es sind alle iconv bekannten Zeichensätze konfigurierbar:

$ iconv -l

In Verbindung mit rsync führt dies aber zum unerwünschten Verhalten, dass Verzeichnisse und Dateien mit Umlauten im Namen bei jeder Synchronisation erneut heruntergeladen werden (ich bin unschuldig, das war ein anderer Benutzer des Servers!).

Tags: , , , , ,
Labels: Apple, Linux

Keine Kommentare | neuen Kommentar verfassen