Joomla100 Support Forum
Archiv => Joomla! - Grundlagen => Thema gestartet von: nehcregit am 23.06.2006 21:19 Uhr
-
Hallo, ich hatte eben mit dem Download-Mod des TinyPortals ein merkwürdiges Phänomen, welches laut Bloc wohl nicht am TP liegt. Daher möchte ich dies einfach mal hier ansprechen...
Zur Situation: Ein Mitglied bemerkte heute plötzlich, dass alle im Downloadtool des TP angebotenen Dateien beim Download die Größe 0 kB aufweisen. Ich ging dem nach, und siehe da, er hatte recht. Neu hochgeladene Dateien gingen aber, und ich bin mir sicher, dass es vor einigen Tagen auch mit den alten problemlos funktionierte.
Wie in diesem Thread (http://www.tinyportal.net/smf/index.php?topic=5876.0) zu lesen ist, waren die besagten Dateien auf 600 gesetzt. Das Problem konnte also dadurch behoben werden, dass ich den Ordner TP-Downloads samt aller Unterverzeichnisse/-dateien auf 755 gesetzt habe.
Wie kann es dazu kommen? Bloc meinte, es dürfte eigentlich nicht am TP liegen, sondern müsse ein Serverproblem sein... Ich möchte ja nur verhindern, dass ich jeden Tag die Rechte dieses Verzeichnisses prüfen muss. :-\
-
Der Ordner sollte CHMOD 777 haben, damit die Dateien dort hineingeschrieben werden können. Weiterhin sollten die Dateien mit CHMOD 644 abgelegt werden, damit diese gelesen werden können. Gibt es eine Config-Möglichkeit, dass Dateien mit CHMOD 644 auf dem Server abgelegt werden? Wenn die Dateien per FTP hochgeladen werden, besteht das Problem von vornherein nicht, da dann die Dateien automatisch mit 644 abgelegt werden.
-
Gibt es eine Config-Möglichkeit, dass Dateien mit CHMOD 644 auf dem Server abgelegt werden?
Nicht, dass ich wüsste. Ich benutze die TP-Möglichkeiten zum Upload...
-
Dann liegt es auch am Skript. Entweder man hat das wwwrun-Problem, dann gibt es bei den hochgeladenen Dateien keine Probleme, oder man hat eben das wwwrun-Problem nicht (insbesondere bei Joomla von Vorteil, beim SMF evtl. nicht ganz so schlimm) und Dateien mit CHMOD 600 sind dann später ggf. nicht mehr lesbar. Bei Joomla gibt es eben eine Konfigurationtsmöglichkeit im Backend, wie die Dateien auf dem Server abzulegen sind (CHMOD new Files to: 644), womit dann keine Probleme mehr entstehen.
-
Dachte ich mir schon irgendwie. Aus welchem Grund sollte der Server den Dateien plötzlich die Rechte wegnehmen?
Ich werde es beobachten und auf die nächste TP-Version warten...
-
Sodele... Nun tritt das gleiche Problem auch mit DOCMan unter Joomla 1.1.10 auf. Die Dateien, die gestern noch in Ordnung waren, sind jetzt beim Download nurmehr 1 kB groß und natürlich defekt. Auf dem Server sind die Dateien aber noch vorhanden.
Und nun? :-\
-
Das ist der "§R$"$§" Docman. Die Dateien brauchen CHMOD 644 oder müssen per FTP hochgeladen werden. Beim Upload per FTP gibt es überhauptkeine Probleme, nur über die Maske vom Docman gibt es dann das Problem. :(
-
Das ist doch s... >:(
Ich kann doch meinem Team nicht FTP-Rechte geben?
Sicher, dass es diesmal am DOCMan liegt? Ich weiß nicht, da das Problem ja auch bereits mit TP auftauchte, und dass beide den gleichen Fehler aufweisen, und das nur bei mir...?!?
Edit: Bringt es was, in der Global Config unter dem Reiter "Server" einzustellen, dass neue Dateien auf 644 gesetzt werden? Oder greift das nicht gescheit?
-
Oder notfalls auf Remository umsteigen, da gibts die Probleme nicht, wenn in der Config von Joomla steht: Chmod new Files to 644. Remository kapiert das, aber Docman nicht. Hatte schon Kontakt mit dem Entwickler deswegen, der meinte nur lapidar: Pech gehabt...
-
Na toll, Remository hab ich nicht zum Laufen bekommen :-[
-
Wo lag das Problem?
-
Weiß ich schon nicht mehr. ::) Ich setze das CHMOD für neue Files in Joomla mal aktiv, mal schauen, vielleicht hilft es was. Habe von Hand allen Dateien jetzt 644 gegeben, und schon geht es wieder. Wenn das nochmal auftritt, muss ich wohl doch nochmal auf Remository wechseln, obwohl mir Docman schon alleine wegen des JCE-Plugins sehr gut gefällt.
Und wenn es dann mit Remository auch noch auftritt, müssen wir uns was einfallen lassen. ;)
-
Jetzt weiß ich es wieder...
Es gab für reg. Benutzer keinen Uploadbutton... Gleichzeitig war es Gästen nicht möglich, Dateien downzuloaden, obwohl so eingestellt... Habs jetzt trotzdem nochmals installiert, finde es aber sehr unübersichtlich...
Edit: Tjo, altes Problem: Keine Upload-Möglichkeit für reg. Benutzer ???
-
Welche Version hast Du denn installiert? Kann ich mal in den Admin-Bereich, um mir die Konfigurationsmöglichkeiten anzuschauen?
-
PN ist unterwegs...
-
Upload hat geklappt, bei Remository hab ich ein JPEG hochgeladen.
-
Ja, aber wie? Mit welcher Funktion? Im Frontend gibts doch keinerlei Möglichkeit, eine Datei hochzuladen?
Edit: Häh? Wieso ist denn der Uploadbutton jetzt da? Hast du was in der Config geändert?
-
Doch, natürlich. Logg dich mal als registrierter Benutzer ein und geh auf "Remository", da ist doch ein dicker fetter Button "Datei hochladen" bzw. "Upload File"
-
Der war direkt nach der Installation aber nicht da! >:(
-
Deshalb wollte ich ja Admin-Login, weil man das über die Konfiguration der Komponente so einstellen kann. 8)
-
Also hatte ich doch noch was falsch eingestellt? :-[
Ih, jetzt können ja sogar Gäste Dateien hochladen... Das sollen aber nur reg. Benutzer können... ::)
Edit: Also, ich habe die Vorschlagsfunktion jetzt nochmal ausgeschaltet, mit dem Ergebnis, dass nun der Upload-Button für Gäste UND reg. Benutzer verschwindet. Gibt also nur zwei Möglichkeiten:
1) Gäste UND Benutzer dürfen uploaden.
2) Weder Gäste noch Benutzer dürfen uploaden.
Kann das sein? Denn die Kategorien sind so eingestellt, dass Besucher nur anschauen, Benutzer aber beides (Anschauen und Hochladen) dürfen...
-
Schau doch mal in die Konfiguration der Komponente, da steht doch alles was möglich ist.
-
Ja sicher, wie ich oben beschrieben habe...
In den einzelnen Kategorien ist eingestellt, dass Gäste nur downloaden dürfen, Benutzer beides. Trotzdem erscheint beim angemeldeten Benutzer kein Upload-Button! Dieser erscheint nur, wenn ich in der Konfig einstelle, dass Dateien vorgeschlagen werden dürfen. Dann dürfen sowohl Gäste als auch Benutzer uploaden, die Kategorien-Einstellungen werden dabei also übergangen. Setze ich in der Konfig das Vorschlagswesen außer Kraft, kann niemand (weder Gäste noch angemeldete Benutzer) mehr uploaden.
Fazit:
Vorschlag aktiv = Upload für Gäste und Benutzer
Vorschlag nicht aktiv = Kein Upload für beide
Kategorieneinstellungen = für die Füße
-
Aber die Uploads müssen ja noch freigeschaltet werden, wenn Du das entsprechend konfigurierst. Oder sollen die direkt freigeschaltet werden? Wie ich sehe, ist das auch noch 3.24, es gibt doch 3.25 oder?
-
Tja, die Versionsnummer. Meine Zipdatei heißt 3.25, und das war auch die Versionsnummer beim Download. In der im Paket enthaltenen readme.txt steht:
3.25 - release
10 March, 2006
Ich möchte es eigentlich so, dass alle registrierten Benutzer direkt uploaden dürfen, Gäste sollen downloaden dürfen. Eine vorherige Prüfung und Freischaltung ist unnötig. Das scheint Remository aber nicht zu können, hm?
-
Ja, da scheint was nicht zu stimmen. Was sagen denn die Entwickler in deren Forum dazu?
-
Noch nichts, da ich ja bisher Docman verwendet hatte... Werd heute abend da mal forschen.
-
Sorry nochmal...
Diesmal direkt die 3.25 von der Entwicklerseite versucht, und nun bereits bei der Installation folgende Fehlermeldungen:
Warning: copy(/srv/www/htdocs/web78/html/cms/administrator/images/approve.png): failed to open stream: Permission denied in /srv/www/htdocs/web78/html/cms/administrator/components/com_remository/install.remository.php on line 34
Warning: copy(/srv/www/htdocs/web78/html/cms/administrator/images/approve_f2.png): failed to open stream: Permission denied in /srv/www/htdocs/web78/html/cms/administrator/components/com_remository/install.remository.php on line 35
Download path is: /srv/www/htdocs/web78/html/cms/downloads
This directory exists.
And it is writable by Remository, which should therefore function correctly
Warning: copy(/srv/www/htdocs/web78/html/cms/downloads/index.html): failed to open stream: Permission denied in /srv/www/htdocs/web78/html/cms/administrator/components/com_remository/install.remository.php on line 68
Upload path is: /srv/www/htdocs/web78/html/cms/downloads/uploads
This directory exists.
But it is not writable by Remository, which will prevent it working.
Wenn ich das recht verstehe, konnte er einige Dateien nicht installieren?
-
Ja, für die Installation braucht der Ordner /administrator/images kurzzeitig CHMOD 777, danach aber wieder auf 755 setzen.
-
Naja, wenns nur Images sind, kann ich die von Hand auf den Server schieben. Ich teste dann heut abend nochmal mein Phänomen, habe aber keine große Hoffnung...
-
Nein, selbes Phänomen wie zuvor auch... Kein Upload-Button. Ich werd das mal im Entwicklerforum posten... ::)
-
Tja, dort scheint man keine Lösung zu finden. Zumindest meldet sich niemand mehr in meinem Thread dort... :(
Könnte man über einen Job immer nachts einmal die Rechte des Download-Verzeichnisses und der darin liegenden Dateien frisch setzen? Das wäre echt super, und so ein kleiner kurzer Job des Nachts wird ja keinen Server auslasten? Ich könnte dann wenigstens wieder ruhig schlafen und nächste Woche in Urlaub fahren...
-
Das kannst Du über Dein Crontab machen, sollte kein Problem sein.
-
Ehrlich? Klasse... Gibts dazu ne Anleitung? :-*
-
www.cronjob.de ;)
-
Hm, mit Hilfe von Google hab ich mir selbst ein Skript gebastelt, traue mich aber nicht. Denkst du, das würde funktionieren? Muss wohl direkt im Rootverzeichnis abgelegt werden und mit Crontab gestartet werden:
#!/bin/sh
# Täglicher CHMOD des Downloadverzeichnisses und der darin enthaltenen Dateien für DocMan
cd html
chmod 755 downloads
cd downloads
chmod 644 *
Gespeichert habe ich sie unter cron1.sh. Nur, wie rufe ich sie mit Crontab auf?
Edit: Habe mich jetzt bei www.cronjob.de registriert, kann ich dort als aufzurufende URL einfach das obige Skript angeben? Will ja nix zum Absturz bringen... :-X
-
Übrigens: http://www.joomlaos.de/Downloads/Joomla_und_Mambo_Komponenten/Remository_3.4.html
Taugt das was?
-
Ich bin von Remository relativ enttäuscht... Das Backend ist mehr als unübersichtlich... Und mein Problem war auch mit dieser Version nicht in den Griff zu bekommen...##
Edit: Danke für die Cronjob-Hilfe, erste Sahne!!! :)
-
So, hier mal der Text, wie ich ihn auch beim Joomlaportal geschrieben habe. Da wir die nächste Woche aber in Urlaub sind, hat das 8 Tage Zeit ;)
Hallo zusammen,
ich habe ein leidiges Problem mit DOCMan, welches sich wohl nur dadurch lösen lässt, dass einmal pro Stunde die Dateien im Verzeichnis "Download" auf dem Server auf 644 gesetzt werden.
Dies versuche ich mit einem Cronjob zu lösen, allerdings schlugen sämtliche Versuche bisher fehl. Ich versuche, das mal für euch verständlich zu beschreiben.
1) Ich habe mich nach Zecke's Vorschlag bei www.cronjob.de registriert und dort rufe ich mittels Cronjob folgende URL auf: http://www.smfportal.de/cron1.php.
2) Inhalt der PHP-Datei ist folgender:
<?php
set_time_limit(0);
ignore_user_abort(true);
$cmd = "/cron1.sh";
system($cmd,$return_value);
?>
3) Dieser Code soll eine .sh-Datei aufrufen, die im gleichen Verzeichnis wie die PHP-Datei liegt. Inhalt der .sh-Datei ist dieser:
#!/bin/sh
# Täglicher CHMOD des Downloadverzeichnisses und der darin enthaltenen Dateien für DocMan
chmod 755 downloads
cd downloads
chmod 644 *.*
Diesen Code habe ich mir nach Informationen gebastelt, die ich mittels Google gefunden habe. Er soll alle Dateien im Verzeichnis "downloads" auf 644 setzen, während das Verzeichnis selbst auf 755 gesetzt werden soll. Er funktioniert leider nicht, und bisher kann mir niemand sagen, woran es liegt (nicht mal die Jungs von cronjob.de, die sehr sehr hilfsbereit waren).
Hat jemand von euch die rettende Idee?
-
Schade, dann muss ich nochmal googlen... :( Beim Joomlaportal will mir auch niemand helfen...
-
Wir sind mit diesem Problem inzwischen bei PHP, aber auch das funktioniert nicht. Kann mir wirklich niemand helfen?