Informationen
Tine 2.0 Update Fehler
Während des letzten Updates von Tine 2.0 kam es zu folgendem Fehler
root@intranet2:/var/www/html/tine# php setup.php --update PHP Fatal error: Uncaught Tinebase_Exception: waited for Action Queue to become empty for more than 300 sec in /var/www/html/tine/Setup/Controller.php:738 Stack trace: #0 /var/www/html/tine/Setup/Controller.php(600): Setup_Controller->_prepareUpdate(Object(Tinebase_Model_FullUser)) #1 /var/www/html/tine/Setup/Controller.php(486): Setup_Controller->updateApplication(Object(Tinebase_Model_Application), '12') #2 /var/www/html/tine/Setup/Frontend/Cli.php(544): Setup_Controller->updateApplications(Object(Tinebase_Record_RecordSet)) #3 /var/www/html/tine/Setup/Frontend/Cli.php(500): Setup_Frontend_Cli->_updateApplications() #4 /var/www/html/tine/Setup/Frontend/Cli.php(73): Setup_Frontend_Cli->_update(Object(Zend_Console_Getopt)) #5 /var/www/html/tine/Setup/Server/Cli.php(132): Setup_Frontend_Cli->handle(Object(Zend_Console_Getopt)) #6 /var/www/html/tine/Setup/Core.php(115): Setup_Server_Cli->handle() #7 /var/www/html/tine/setup.php(14): Setup_Core::dispatchRequest() #8 {main} thrown in /var/www/html/tine/Setup/Controller.php on line 738 Fatal error: Uncaught Tinebase_Exception: waited for Action Queue to become empty for more than 300 sec in /var/www/html/tine/Setup/Controller.php:738 Stack trace: #0 /var/www/html/tine/Setup/Controller.php(600): Setup_Controller->_prepareUpdate(Object(Tinebase_Model_FullUser)) #1 /var/www/html/tine/Setup/Controller.php(486): Setup_Controller->updateApplication(Object(Tinebase_Model_Application), '12') #2 /var/www/html/tine/Setup/Frontend/Cli.php(544): Setup_Controller->updateApplications(Object(Tinebase_Record_RecordSet)) #3 /var/www/html/tine/Setup/Frontend/Cli.php(500): Setup_Frontend_Cli->_updateApplications() #4 /var/www/html/tine/Setup/Frontend/Cli.php(73): Setup_Frontend_Cli->_update(Object(Zend_Console_Getopt)) #5 /var/www/html/tine/Setup/Server/Cli.php(132): Setup_Frontend_Cli->handle(Object(Zend_Console_Getopt)) #6 /var/www/html/tine/Setup/Core.php(115): Setup_Server_Cli->handle() #7 /var/www/html/tine/setup.php(14): Setup_Core::dispatchRequest() #8 {main} thrown in /var/www/html/tine/Setup/Controller.php on line 738
Der Fehler entsteht nach einigem recherchieren von dem verwendeten Redis Cache. Diesen kann man sich mittels
root@intranet2:/var/www/html/tine# redis-cli keys '*TinebaseQueue*'
anzeigen lassen.
root@intranet2:/var/www/html/tine# redis-cli keys '*TinebaseQueue*' 1) "TinebaseQueueQueue" 2) "TinebaseQueueData:5f998404d4d11fc752691eccde71b84e77d0d630" 3) "TinebaseQueueData:ec56ebe18300fa762fd63c90d2a4d469913af622" 4) "TinebaseQueueData:35a8af20e85660ec7092a7ebc641f242de972730" 5) "TinebaseQueueData:e2b4dc4fe742c7ce3b2b19893d6388309295c018" 6) "TinebaseQueueData:e6fc468aed8cb24caa93dd2523714c77eac58966" 7) "TinebaseQueueData:c85f9df51b8fbf6f7169307a83c2391c538e7326" 8) "TinebaseQueueData:8d66c4776ff85cfc3392a037e10d8a1e2f8807ca" 9) "TinebaseQueueData:7515a531e78592abb667a68a8389a068eb472ba5" 10) "TinebaseQueueData:3b09dc4cc911c4f80610a2bcdd7917f56aea3b7a" 11) "TinebaseQueueData:f884a02af18f4a11294c48849b26491d9063481e" 12) "TinebaseQueueData:4fad47f2d2212c0e0203b85eb2b731a9d41793f5" 13) "TinebaseQueueData:45fa79b2f8fefec2395aae8deeefcc257e16d813" 14) "TinebaseQueueData:750ea50ea43c905f5c4fa8819afed587cea6277b" 15) "TinebaseQueueData:0480421b7a79fbc16e623a10bf39d834799e0491" 16) "TinebaseQueueData:d9c201f2f9c82ea7e02b5fa1122581f1f9cdc6b7" 17) "TinebaseQueueData:525081aa7829544afdeb1ca1310cdb98f8070c5b" 18) "TinebaseQueueData:a817d6f81a7bd1ae383adb9c102799a55915fd02" 19) "TinebaseQueueData:9706cb5e9453fd123cd1a79a36feee0e5e6a9509" 20) "TinebaseQueueData:6bbf1da83f5c632582635b61f2462b1ec4bd9bc8" 21) "TinebaseQueueData:23be84d1ee8feaf503edd7e188caf7d1d9491307" 22) "TinebaseQueueData:ff1d16d7d227c9dcf311bcbe0688fc971b571512" 23) "TinebaseQueueData:4cc58d3d4fd822c64bee5018564f38a570f12e6a" 24) "TinebaseQueueData:9c0f3f89a6fa83b82963115365dee332dfe3c662" 25) "TinebaseQueueData:c22c02a98ea9d9b384867d0b965abc5c573ef4bd" 26) "TinebaseQueueData:3b58519ea6404aecd98c15e2371980676e26597f" 27) "TinebaseQueueData:a14dfc4a92d62d4d9f8dd7dbc98dedfd81f3504d" 28) "TinebaseQueueData:02716763f8f3317d12598b7dcd0bd602e5745412" 29) "TinebaseQueueData:5b047725a2e5b90f5464fa9544c5c0ecd1542831" 30) "TinebaseQueueData:75b00a99b095e9065c89ce500f687e97886ddf83" 31) "TinebaseQueueData:22ba67cbc09eeb008145c24892d1e0c009685390" 32) "TinebaseQueueData:880ad659ceca6bb36cf0aec6d030c4a6dd0c87c7" 33) "TinebaseQueueData:73871e6c39dc55c1ee25d408901b98ec7770307f" 34) "TinebaseQueueData:0e293a6194276d351bda5b570af80780a50e7427" 35) "TinebaseQueueData:88fcae23579f29ac5428b7c98c13f4ed003f28aa" 36) "TinebaseQueueData:bbf027ddbfc6cb064b1de67dc4d78d833df81602" 37) "TinebaseQueueData:3d52d5fdca11f2ed1cbcd50c5b056afcca9ae977" 38) "TinebaseQueueData:116983bdb84439440f59e4414209c7e6da2189cb" 39) "TinebaseQueueData:048489e90a2cb8e230c4db3deb2ebfde0c3d3046" 40) "TinebaseQueueData:68a1cfa1145cef7d34d282c98c669efd0b2ab0f0" 41) "TinebaseQueueData:ccc825a39308e40ba17a5fadb07da9ba601fa56d" 42) "TinebaseQueueData:498a99be0469374281d43ef974781fbdf620b719" 43) "TinebaseQueueData:5e4b2218c08b2400283a1fbe9b6d3ecb4a9cd027"
Sollten Einträge vorhanden sein, kann man diese mittels
root@intranet2:/var/www/html/tine# redis-cli flushdb OK
entfernen. Ist der Cache gelöscht, klappt das Update via GUI und CLI.
Roundcube Logo austauschen
Logo auf dem Server in das Verzeichnis
/usr/share/roundcube/skins/larry/images
laden. Wenn man ein anderes Design verwendet, Pfad anpassen. Konfiguration von Roundcube anpassen
vim /etc/roundcube/config.inc.php
folgende Zeile einfügen oder anpassen wenn vorhanden.
[...] $config['skin_logo'] = "/images/logo.png"; [...]
root ohne Schreibrechte im Webverzeichnis
Seit ISPconfig 3 wird standardmäßig das sogenannte immutable Flag gesetzt. Das bedeutet, dass gewisse Dateien nicht modifiziert, umbenannt oder gelöscht werden können. Dieser Schutz betrifft auch den „Standard“ root Benutzer.
Man kann diesen Schutzmechanismus global deaktivieren. Davon raten wir aber dringendst ab! Die Einstellung findet man in ISPconfig bei den Servereinstellungen.
Wir empfehlen, wenn man wirklich in den geschützten Verzeichnissen arbeiten muss, zum temporären deaktivieren des Flags. Dies geschieht mit dem Befehl chattr.
Zum kurzzeitigen deaktivieren kann man das Flag mittels
chattr -i /var/www/reichardt.it/
entfernen und nach de Arbeiten mittels
chattr +i /var/www/reichardt.it/
wieder setzen.
Timeouts und langsame Verbindung IPv6
Bei zwei Servern aus einem Rechenzentrum in Frankfurt ist aufgefallen, dass der Verbindungsaufbau via IPv6 mehr als wackelig läuft. Selbst die Verbindungen innerhalb des Rechenzentrums waren sehr langsam oder wurden garnicht erst aufgebaut. Aufgefallen ist das ganze bei der Installation von Software mittels apt.
Abhilfe schafft die Priorisierung zurück auf IPv4. Dazu die Konfigurationsdatei von getaddrinfo bearbeiten.
# vim /etc/gai.conf
Darin den Eintrag
# For sites which prefer IPv4 connections change the last line to # #precedence ::ffff:0:0/96 100
ändern in
# For sites which prefer IPv4 connections change the last line to # precedence ::ffff:0:0/96 100
Damit hat IPv4 wieder den Vorrang und die Routen liefen wieder flüssig.
Befehlssammlung Windows 95
Nostalgie? Nein. Einige Maschinen die wir betreuen laufen noch mit diesem hochbetagten Betriebssystem.
Wer mag kann sich diesen Artikel gerne zu Gemüte führen. Ich selbst muss gestehen das es mitunter Spaßig ist, in die Vergangenheit der Betriebssysteme zu schauen. Mal abgesehen davon, dass Windows 95 auf einem alten Toshiba Laptop mit irgend was um die 100 MB RAM innerhalb 10 Sekunden startet. Da können sich andere Betriebssysteme eine Scheibe abschneiden ;)