PHP auf der Kommandozeile bei Strato

Versucht man die Kommandozeilentools von NextCloud occ und updater.phar bei Strato zu benutzen dann bekommt man so nette Fehlermeldungen:

> php updater/updater.phar
Nextcloud Updater - version: v20.0.0beta4-11-g68fa0d4
Current version is 20.0.3.
Update to Nextcloud 20.0.12 available. (channel: "stable")
Following file will be downloaded automatically: https://download.nextcloud.com/server/releases/nextcloud-20.0.12.zip
Open changelog ↗
Steps that will be executed:
[ ] Check for expected files
[ ] Check for write permissions
[ ] Create backup
[ ] Downloading
[ ] Verify integrity
[ ] Extracting
[ ] Enable maintenance mode
[ ] Replace entry points
[ ] Delete old files
[ ] Move new files in place
[ ] Done
Start update? [y/N] PHP Warning:  Use of undefined constant STDIN - assumed 'STDIN' (this will throw an Error in a future version of PHP) in phar:///mnt/web120/e2/56/510XXX56/htdocs/cloud/updater/updater.phar/vendor/symfony/console/Helper/QuestionHelper.php on line 117
PHP Warning:  fgets() expects parameter 1 to be resource, string given in phar:///mnt/web120/e2/56/510XXX56/htdocs/cloud/updater/updater.phar/vendor/symfony/console/Helper/QuestionHelper.php on line 133
[RuntimeException]
Aborted
update [--no-backup]
X-Powered-By: PHP/7.4.23
Content-type: text/html

oder bei occ:

php occ upgrade
X-Powered-By: PHP/7.4.23
Content-type: text/html
An unhandled exception has been thrown:
TypeError: Return value of OC\AppFramework\Http\Request::getScriptName() must be of the type string, null returned in /mnt/web120/e2/56/51008256/htdocs/WordPress-WH3/cloud/lib/private/AppFramework/Http/Request.php:837
Stack trace:
#0 /mnt/web120/e2/56/510XXX56/htdocs/cloud/lib/base.php(163): OC\AppFramework\Http\Request->getScriptName()
#1 /mnt/web120/e2/56/510XXX56/htdocs/cloud/lib/base.php(576): OC::initPaths()
#2 /mnt/web120/e2/56/510XXX56/htdocs/cloud/lib/base.php(1091): OC::init()
#3 /mnt/web120/e2/56/510XXX56/htdocs/cloud/console.php(49): require_once('/mnt/web120/e2/...')
#4 /mnt/web120/e2/56/510XXX56/htdocs/cloud/occ(11): require_once('/mnt/web120/e2/...')
#5 {main}

Dazu kommt, dass die PHP-Version nicht unbedingt zur Version passt, die für den Webspace eingestellt ist (in diesem Fall wäre es eigentlich PHP 7.3 gewesen).

Ein funktionierendes PHP-Binary findet man unter /opt/ in einem Versionsspezifischen Ordner:

/opt/RZphp73/bin/php-cli occ db:add-missing-indices
The current PHP memory limit is below the recommended value of 512MB.
Check indices of the share table.
Check indices of the filecache table.
Adding additional size index to the filecache table, this can take some time...
Filecache table updated successfully.
Check indices of the twofactor_providers table.
Check indices of the login_flow_v2 table.
Check indices of the whats_new table.
Check indices of the cards table.
Check indices of the cards_properties table.
Check indices of the calendarobjects_props table.
Check indices of the schedulingobjects table.
Check indices of the oc_properties table.

Damit funktionieren sowohl occ als auch updater.phar einwandfrei 🙂

PHP Fehlerdiagnose

Bei PHP-Installationen ist meistens die Fehlerausgabe deaktiviert, was bei Produktivumgebungen in der Regel auch sinnvoll ist. Während der Entwicklung oder bei der Fehlerdiagnose ist das jedoch eher hinderlich.

error_reporting(E_ALL ^ E_NOTICE); // Alle Fehler ausser Hinweisen anzeigen
ini_set("display_errors", 1); // Fehler im Script selbst anzeigen

Wenn man die Fehler nicht ausgeben möchte (z.B. in einem Produktivsystem) kann man sie auch im Fehlerprotokoll des Webservers sehen.

Bei manchen Webspace Hostern hat man allerdings keine Möglichkeit auf das Fehlerprotokoll des Webservers zuzugreifen. Möchte man trotzdem PHP Fehlermeldungen sehen kann man das Log auf eine eigene Datei umbiegen:

ini_set("log_errors", 1); // Fehler ins Protokoll schreiben
ini_set("error_log", "/path/to/php_errorlog.log"); // Pfad zu eigenem Fehlerprotokoll setzen

Natürlich funktioniert das nur wenn der Hoster die Benutzung des ini_set Befehls erlaubt, einige Hoster verbieten das.

Active Directory LDAP-Zugriffe mit mehreren Domain Controllern

Auch in einer Windows-Domänen Umgebung kommt man früher oder später darauf, dass es eine Anwendung gibt die nicht auf Windows und IIS, sondern auf einem Apache läuft, vielleicht mit PHP oder einer anderen Skriptsprache. Sowohl PHP als auch der Apache direkt bieten über LDAP die Möglichkeit einen Domain Controller abzufragen, Beispielsweise zur Authentifizierung.

Spätestens wenn ausgerechnet der Domain-Controller ausgefallen (oder wegen Wartungsarbeiten nicht erreichbar) ist, den die PHP-Scripte zur Authentifizierung benutzen, stellt sich die Frage wie man es einrichtet dass irgend ein verfügbarer Domain Controller genutzt wird. Glücklicherweise sind sowohl PHP als auch das Apache-Modul für diesen Fall vorbereitet, und nutzen sogar das gleiche Prinzip dafür. Man muss lediglich an der Stelle wo der Servername steht mehrere Adressen durch Leerzeichen getrennt eintragen.

PHP-Aufruf:

$conn = ldap_connect("dc01.domain.local dc02.domain.local");
ldap_bind($conn, $username, $password);

Eintrag in der Apache-Konfiguration:

AuthLDAPUrl "ldap://dc01.domain.local:3268 dc02.domain.local:3268/dc=domain,dc=local?sAMAccountName?sub?(objectClass=*)" STARTTLS

Hier muss man darauf achten dass der LDAP-String in Anführungszeichen steht (solange kein Leerzeichen vorkommt funktioniert es auch ohne).

Auf diese Art werden alle angegebenen Server durchprobiert bis einer gefunden wird der erreichbar ist.

Quellen: mod_auth_ldap Dokumentation, Kommentar in der PHP-Dokumentation zu ldap_connect()

iCal for Events Manager anpassen

Das WordPress-Plugin Events Manager hat mit der Version 5 mal wieder die Datenbank-Struktur angepasst, so dass das iCal-Plugin nicht mehr funktioniert. Das letzte Mal konnte ich die Änderungen die ich gemacht habe auf der Seite des Entwicklers posten, mittlerweile hat er das leider unterbunden.

Falls noch jemand Probleme mit dem Plugin hat, hier meine Änderungen für die Version 5.1.5 vom EM:

    $queryEvents = "SELECT event_id AS id, event_name AS eventTitle, e.post_content AS eventDescription, ";
$queryEvents .= "location_name AS eventLocation, ";
$queryEvents .= "event_start_date AS eventStartDate, event_start_time AS eventStartTime,  ";
$queryEvents .= "event_end_date AS eventEndDate, event_end_time AS eventEndTime ";
$queryEvents .= "FROM ".$wpdb->prefix."em_events e, ".$wpdb->prefix."em_locations l ";
$queryEvents .= "WHERE event_id > 0 AND e.location_id = l.location_id ";
$queryEvents .= "ORDER BY event_start_date DESC";

Active Directory Primärgruppe eines Users mit PHP finden

Versucht man über LDAP Infos über Benutzeraccounts aus dem Active Directory zu laden, dann wird ein nicht ganz unwichtiges Detail unterschlagen: Die Primary Group des Benutzers. Eine LDAP-Abfrage nach memberOf liefert alle Gruppen, mit Ausnahme der primären. Stattdessen wird im Benutzer-Objekt eine numerische primaryGroupID abgespeichert. Diese ID taucht jedoch im Objekt der Gruppe auf den ersten Blick nicht auf. Das ganze geht sogar noch weiter: Gruppen enthalten mit dem member-Attribut alle Mitglieder. Es liegt also nahe, mit der Abfrage “(&(member=$userDN)(objectType=group))” alle Gruppen zu finden in denen sich der Benutzer befindet. Leider macht uns das Active Directory hier auch einen Strich durch die Rechnung, es liefert wieder nur alle Gruppen ohne die Primärgruppe. Active Directory Primärgruppe eines Users mit PHP finden weiterlesen

Mehrere SQL Queries in PHP

Laut der PHP-Dokumentation lässt sich mit mysql_query(); immer nur ein einzelner SQL-Query ausführen, mehrere durch Semikolon getrennte Queries sind nicht erlaubt.

Es geht jedoch wenn man beim mysql_connect(); ein entsprechendes Client-Flag setzt:

mysql_connect($server, $user, $pass, false, 65536);

65536 ist in MySQL als CLIENT_MULTI_STATEMENTS definiert und erlaubt damit mehrere Statements in einem einzelnen Query.

Diese Möglichkeit ist jedoch mit Vorsicht zu genießen, sie öffnet SQL Injections Tür und Tor.

Quelle: Benutzer-Kommentar in der PHP-Dokumentation