Beiträge von ThomasChr

Die Pending Time ist die Zeit die der Server braucht um die Seite zu rendern.
(sollte ich mich irren, hier bitte korrigieren )

Das heißt:
- PHP Interpreter starten
- Datenbankverbindung aufbauen
- Tabellen abfragen
- Daten an PHP liefern
- Seite generieren

Was hier langsam ist, kannst nur du wissen

Ich würde als einfachstes mal das MySQL Slowlog aktivieren und schauen ob du Abfragen hast die lange dauern.
Tja und dann würde ich mal im htop beobachten was der Prozess denn in den 5 Sekunden so macht.

Ich bin sicher es gibt da noch viele Tools die dir viel genauer aufzeigen können wo dein PHP seine Zeit verbringt, entweder kommt hier im Forum einer ums Eck der was weiß (ich bin auch gespannt!) oder du googelst mal danach.

Thomas

Ich denke das chown kannst weglassen - die Befehle waren nur als Beispiel dafür gedacht wie man Owncloud auf einem vServer installiert.
Ich denke wenn du über den Webhosting-SSH drin bist müssten die Benutzerrechte (hoffentlich) schon passen. Aber notfalls würde Owncloud da meckern.

Auch die Datenbank und den Datenbankuser musst du nicht über die Befehle anlegen, sondern im Webhostingpanel von netcup.
Wenn Owncloud dann mal läuft (mit der Mysql-Datenbank) kannste den Kalender anlegen (als ersten Kalender, damit er die ID '1' bekommt) und dann die SQL-Datei importieren.
Das sollte nicht mehr kompliziert sein.

Thomas

Produkte->Auf die Lupe->rDNS

Normalerweise sollte das einfache Ändern des rDNS reichen.
Trotzdem mal die SMTP-Diagnostics machen um zu sehen ob du noch etwas ändern solltest.

Eventuell sollte der Banner des Mailservers noch dazupassen. Der Hostname muss eigentlich nicht unbedingt passen.

Thomas

Hallo omexlu,

wenn du dir den Beitrag komplett durchliest - da steht die Lösung sicherlich schon mehrmals drin.

Du musst den rDNS auf deine tatäschliche Domain zeigen lassen.

rDNS für IP 123.123.123.123 z.B: mail.tolledomain.de

Natürlich muss nun mail.tolledomain.de mit A Eintrag auf die IP 123.123.123.123 zeigen.

Testen kannst du das ganze hier: Email Server Test - Online SMTP diagnostics tool - MxToolbox

Thomas

Ich hab dazu mal einen Issue beim SourceCode Repository von Owncloud erstellt:
Importing large Calender (.ics) files fails silently on shared Webhosting

Mal sehen was die dazu sagen...

Thomas

Hallo Nicola,

das scheint hier ja ein ziemliches Chaos zu sein...
Ich würde dir gerne auf Anhieb eine Lösung liefern, aber wie du ja selber siehst ist das nicht so einfach.

Zusammenfassend kann ich dir sagen dass das kopieren von irgendwelchen Datenbankdateien als Backup meistens eine schlechte Idee ist. Das kann erstaunlicherweise klappen, meistens aber eher nicht.

Bei dir sieht es momentan so aus als wäre die Datei /var/lib/mysql/ibdata1 nicht vorhanden, deswegen will MySQL nicht starten.
Sollten die Daten deiner Datenbank nicht kritisch (privat) sein, kannst du mir mal dein Backup schicken (oder mir anderweitig Zugriff verschaffen) und ich versuche mein Glück.

Sollten deine Daten natürlich privat sein wirst du hier weiter rumprobieren müssen. Ein steiniger Weg bei dem man aber viel lernen kann

Alles in allem scheint dieser Artikel schon recht gut zu sein: Backup › MySQL › Wiki › ubuntuusers.de

Probier mal ihm so genau wie möglich zu folgen!

Grüße,

Thomas

Eventuell erlaubt dein DNS Server keine Anfragen von außerhalb?
Teste doch mal hier wenn du deinen Nameserver einträgst: http://www.kloth.net/services/nslookup-de.php

Thomas

Hallo fieseline,

gute Nachricht, das Problem ist gefunden.

Es ist schlicht und einfach dass das importieren deiner Events-Datei mit 3 MB und 5687 Events ca. 5 - 10 Minuten dauern würde.
Würde weil netcup nach 60 Sekunden den Import abbricht. Da sind dann gerade mal 600 Events importiert.

Macht aber nix, weil Workaround kriegen wir hin. Das einfachste ist wenn du Owncloud neu installierst und diesmal eine MySQL-Datenbank als Backend angibst.
Wenn du auf der Shell installieren würdest geht das so:

1. Schritt: Runterladen von Owncloud und entpacken der Datei in den Ordner wos hinsoll:

wget https://download.owncloud.org/community/owncloud-8.2.2.tar.bz2 --no-check-certificate
tar -xjf owncloud-8.2.2.tar.bz2
rm owncloud-8.2.2.tar.bz2
chown -R www-data:www-data ./owncloud

2. Schritt: Anmelden im webhostingscontrolpanel von netcup und eine neue Datenbank anlegen.

create database owncloud;
grant usage on *.* to owncloud@localhost identified by 'owncloudpass';
grant all privileges on owncloud.* to owncloud@localhost ;

3. Schritt: Aufrufen der URL, eintippen eines Admin-Usernames und eines Adminpassworts.
ACHTUNG: Nun auf "Speicher & Datenbank" klicken und dann auf "MySQL/MariaDB".
Daten eintragen:
Datenbank-Benutzer: k43877_owncloud
Datenbank-Passwort: xxxxxxxx
Datenbank-Name: k43877_owncloud
Datenbank-Host: 10.35.249.59

So, und nun kannst du alles einrichten in Owncloud (vorallem den Kalender aktivieren) und dann über das webhostingcontrolpanel dich mit der Datenbank (phpmyadmin) verbinden.
Von dort aus kannst du den Datenbankdump den ich mit deinen Events gemacht habe direkt in die DB laden - da gibts dann kein Problem mit dem Timeout!

Einzig und allein kann es sein dass wir in der Tabelle oc_clndr_objects noch die calenderid von den Events ändern müssen - das sehen wir dann.

Den Dump hab ich dir auf meine tcplay-Cloud hochgeladen, die Zugangsdaten müsstest du haben.

Mfg,

Thomas

Hallo fieseline,

keine einzige der Fehlermeldungen deutet irgendwie auf die Möglichkeit hin dass deine Dateien verloren gehen. Da würde ich mir jetzt nicht sooo viele Sorgen machen.
Sobald du Owncloud aber mal wirklich "produktiv" einsetzt, solltest du auf jeden Fall Backups haben. Nicht nur weil Owncloud was verbummelt, sondern evtl. löscht auch du irgendwas ausversehen was du noch gebraucht hättest!

Ich würde ja deine .ics-Datei testen, aber dafür müsstest du sie mir auf irgendeinem Weg schicken - außerdem ists gut möglich dass da einige private Informationen drin stehen.
Also entweder vertraust du mir einfach in der Richtung und ich probiere mal ob ich finden kann was mit deiner Datei nicht in Ordnung ist, oder aber du versuchst selbst die Datei so lange in Hälften zu schneiden bis du genauer eingrenzen kannst wo der Fehler liegt. Im Debugging Jargon nennt sich das "Divide and Conquer" - "Teile und Hersche".

Thomas

Hallo fieseline,

also wenn dir geholfen werden soll, müsstet du schon manchmal etwas genauer sein.
Ich musste nun raussuchen wie man die Kalenderapp aktiviert, und dann raussuchen wie man .ics-Dateien importiert, und dann musste ich noch eine .ics-Datei bauen - denn ich hab keine.

Naja, jedenfalls hab ich diese Datei nach Owncloud hochgeladen, dann auf importieren geklickt und schon war der Termin da - wie gesagt in einem Webhosting Paket "Web Expert L".

Das heißt entweder ist an deiner Datei was komisch, oder es stimmt doch etwas mit deiner Installation nicht. Aber ohne Zugriff auf deine Installation werde ich hier nicht mehr weiter helfen können.
Du kannst gerne die Zugangsdaten für meine Testinstallation haben (schreib mir ne PM) und die .ics-Datei die ich zum Testen genommen habe (ist ein vom Jahr verändertes Beispiel aus der Wikipedia) hab ich dir angehängt.

Was dir übrigens die anderen Beiträge sagen wollten - vor allem der Beitrag 14 in dem verlinkten Thread von Felix ist doch relativ eindeutig:
>>>
Die Warnmeldungen sind zwar da, aber es funktioniert trotzdem alles (wichtige).
<<<
Zitat felix:

Zitat

Ich selber habe privat ein Owncloud auf einem shared Webhosting am
laufen. Die Warnungen (siehe letzten Post von mir) sind mir bekannt.
Fehler gibt es jedoch keine.

Auch ich konnte bei meiner Testinstallation zwar die Fehler sehen, funktionieren tut aber trotzdem alles.

Kurzum: Das einzige Problem dass du tatsächlich hast ist das importieren des Kalenderereignisses - und wenn du mir einen Account bei deiner Owncloud einrichtest und mir deine .ics-Datei gibst kann ich testen ob ich den Fehler nachstellen kann. Das wird aber natürlich sehr schwer denn ich bräuchte zum richtigen Debuggen Administratorzugriff auf Owncloud, die Logfiles von Owncloud und die Programmcodes.

Mfg,
Thomas

Um mit root zu arbeiten hilft "sudo -i" und dem Postfix ist dein Hostname ziemlich egal, der hat ne eigene config wo man ihm auch ganz andere Daten geben kann. Trotzdem ist einfacher wenn der Hostname passt

Ich persönlich nehm keine Keys, außer für automatikabläufe.

Sollte ich Dateien von root per FTP wollen kommen die ins Userdir und bekommen als Owner den User.
Bekanntlich sollte man sowieso so selten wie möglich mit root arbeiten.

Wobei man -meiner Meinung nach- doch sagen muss dass es mit der Absicherung gerne übertrieben wird. Da liest man dann von Leuten die:
a) SSH auf einem anderen Port haben,
b) SSH nur mit Keys erlauben,
c) SSH sowieso nur nach Portknocking erlauben,
d) root garnicht per SSH erlauben...

Ich denke man kann es auch übertreiben!

Wichtig ist:
- Das du niemals irgendwo ein schwaches Passwort verwendest,
- Genau weißt was auf deinem Server läuft,
- Und gerade alle Arten von Websoftware (CMS, Forum, ...) immer aktuell hälst

Damit hat man schon die 99% der automatischen Angriffe weg. Und wenns doch mal das letzte Prozent (also der wirklich intelligente Hacker) auf dich abgesehen hat, hast du sowieso fast keine Chance. Wenn der Weg durch due Vordertür gut gesichert ist nutzt man halt den Kellereingang. Spear Fishing oder Social Engineering...

Und außerdem ist ein Linux direkt nach der Installation erstmal sicher. Solange man also nicht wild irgendwas installiert sondern vorsichtig vorgeht und sich informiert hat man ned gleich unfreiwillig nen HoneyPott. Ein Ubuntu mit nem starken Passwort für alle User sowie der Standardinstallation aus den Paketquellen für Apache, Mysql, PHP und Postfix ist immer noch sicher. Bis zu dem Moment wo man Einstellungen verändert die man nicht versteht!

Thomas

Hallo Tolive,

danke für die Info, man lernt halt nie aus

Thomas

Also Zertifikate gelten eigentlich meistens nur für eine Domain! (manchmal ists sogar ein Unterschied ob mit oder ohne www.).
Es gibt Zertifikate die gelten für eine Domain und alle Subdomains (wildcard) aber die sind Schweineteuer!

Was dein Mailen betrifft so wette ich darauf dass du den Reverse-DNS für die IP deines Mailservers nicht richtig gesetzt hast!

Google mal nach "mx toolbox" geh auf die Seite und klick auf "diagnostics". Wenn du dort die Adresse (Ip oder Domain) deines Mailservers eintippst sagen die dir was falsch ist - weswegen manche deine Mails ablehnen. Gerade die großen Maildienste sind da sehr penibel!

Thomas

Oder aber Kunden welche einen Fehler in irgendeiner netcup Anwendung gefunden und vielleicht sogar mit Lösungshinweis gemeldet haben?

So ode so ist dass doch etwas was man sowieso beides machen sollte!

Thomas

Sorry: Hatte nen kleinen Fehler. Der Insgesamtspeicherplatz von Web Expert M ist nicht 100 GB sondern 50 GB !

Thomas

Ich würde vermuten dass die Emails zum Speicherplatz von 100 GB dazu zählen.
Das heißt also ein Postfach mit 100 GB, oder zwei mit 50 GB - wenn du keine Webseitedaten hast

Thomas

Problem 1: /dev/urandom ist nicht lesbar:
Tatsache, ein PHP-Aufruf von "@file_exists('/dev/urandom')" liefert ein False zurück. Aber nur auf dem Webspace mit Aufruf über URL, wenn über die Bash PHP aufgerufen wird geht es.
Problem nachstellen:

<?php
    if(@file_exists('/dev/urandom')) {
   	 echo "file da<br>";
    } else {
   	 echo "file nicht da<br>";
    }

    $file = fopen('/dev/urandom', 'rb');
    if($file) {
   	 echo "file open<br>";
   	 fclose($file);
   	 return true;
    } else {
   	 echo "file nicht open<br>";   	 
    }    
?>

Problem 2: Der Server denkt er sei offline:
Da gibt es schon einen ausführlichen BUG-Case dafür: Error: server is not connected to the internet message - but I am, or so I think ... · Issue #16255 · owncloud/core · GitHub
Problem nachstellen:

<?php




function doCurl($url) {
	$ch = curl_init($url);
	curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
	$result = curl_exec($ch);
	$code = curl_getinfo($ch, CURLINFO_HTTP_CODE);
	curl_close($ch);
	return $code;
}
echo "HTTP Status: ".doCurl("https://owncloud.org")."\n";
echo "HTTP Status: ".doCurl("https://www.owncloud.org")."\n";




?>

-> Die zweite Zeile gibt einen Error '400'
--> Es scheint hier ein Problem mit der Curl/PHP-Version zu geben, das kann sicher nur der Hoster beheben
---> Wenn ichs aber richtig im Überblick habe wird diese Funktion hauptächlich zum installieren von Apps für Owncloud genutzt.
Bei unserer Owncloud ist der gleiche Fehler, aber das Dateisynchronisieren macht keine Problem - sonst nutzen wir aber auch nichts von Owncloud.

Was die Kalenderapp betrifft, so müsste ich wissen welche Kalenderapp um hier debuggen zu können.