[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: hochgenervt....



Hallo Lars,

lars wrote on 22.09.2003 (d.m.y):

> nach zwei tagen herumprobierens mit thttpd habe ich den schon mal
> aufgegeben; das teil brachte ich nicht zum laufen; apache 2 gezogen,
> ./configure und make install -läuft gut, inklusive virtualHost.

Tut es der "im Lieferumfang" befindliche apache nicht?
Da haettest Du dann auch den Vorteil, dass Du auf einfachste Weise
Patches einspielen koenntest...
 
> erste merkwürdige erscheinung: unter suse hatte ich meine websiten auf dem
> mac erstellt, per netatalk oder samba auf das documentRoot geschoben, und
> fertig war die laube d.h. die Website.

Halte ich fuer keine so richtig gute Idee - das mit der
gleichzeitigen Freigabe eines Verzeichnisses mit samba und netatalk.
 
> unter dem debian ging erstmal gar nichts.

Inwiefern waren die Versionen der eingesetzten Software (speziell
netatalk) auf dem Suse-System anders?
 
> dieselben html-dateien, die auf der  suse-kiste liefen, musste ich auf der
> debian3 / httpd-2.0.45-kiste (httpd 2.0.45 selbst kompiliert warŽs aber
> schon unter suse - erfolgreich!) jetzt alle per chown nobody:nogroup erstmal
> lesbar machen. folge: einfaches updaten der dateien und rüberschieben ins
> DocumentRoot per AppleTalk (so habe ich es ein Jahr lang gemacht) geht nicht
> mehr - ich muss alle Dateien per chown ummodeln :-(
> 
> das kannŽs doch irgendwie nicht sein.... unter suse war ich der owner und
> die seiten waren lesbar.

Koennte evtl. auch an der Apache-Konfiguration liegen.
Sicherheitshalber waeren aber die Zugriffs- und
EIgentumsvrhaeltnisse der entsprechenden Verzeichnisse auf dem
Suse-System einen vergleich mit denen von der Debian-Seite wert...
 
> zweite sache: diverse Dateien im documentRoot haben auf einmal ein ._ vorweg
> - für mich nicht erkennbar, warum und nach welchem system - also alles
> wieder umbenennen :-((

Diese Dateien entsprechen den Ressource-Forks der "zweigeteilten"
Mac-Dateien. Bei HTML-Dateien duerfte dort nichts essentielles
drinstehen.
Darin legt der Mac sonst Metadaten wie "Type" und "Creator" ab, die
ihm sagen, mit welchem Programm er die eigentlichen Dateien oeffnen
soll. Bei "normalen" Dateien findet sich die eigentliche "Nutzlast"
dann in der Data Fork.
Wichtig wird die Resource Fork hingegen bei Programmen, aber auch
bei Zeichensaetzen.
 
> netatalk und samba zeigen ebenfalls eigenartige erscheinungen: die
> netatalk-verzeichnisse auf meinem rechner verschwinden plötzlich, werden
> aber als gemountet angezeigt, samba weigert sich bei grösseren dateien,
> diese zu kopieren - alles sehr strange :-(((

In Sachen netatalk empfiehlt es sich immer, ein halbes Auge auf die
Mailinglisten zu haben - in der letzten Zeit war die
Entwicklergemeinde sehr aktiv und hat diverse Updates und
Neuversionen hervorgebracht.
-> <http://netatalk.sourceforge.net>
Darueberhinaus diskutieren in <news://de.comp.sys.mac.lokale-netze>
einige sehr versierte AFP-"Anwender" mit, die auch viel von netatalk
verstehen.
 
> die kiste, auf der das ganze sich abspielt, lief unter suse monatelang ganz
> gut, es sollte also kein hardwarefehler sein (aber wer weiss).
> 
> dass ich mich beim  kompilieren gleich dreier programme verhauen habe,
> erscheint mir auch unwahrscheinlich.

Und was spricht gegen die Verwendung der mit Woody paketierten
Programme?
 
> es gibt ja auch keine fehlermeldungen von wegen fehlender module oder
> dergleichen - es ist alles plötzlich nur sehr, sehr mühselig und mit
> unerklärlichen phänomenen behaftet.
> 
> mit Linux kann ich immerhin soweit umgehen, dass ich unter Suse einige
> Dutzend produktiver Server zum laufen gebracht habe.

Wo Du "produktiv" sagst: Wegen der Eigenheiten der Mac-Daten ist es
_keine_ gute Idee, dieselben Verzeichnisse sowohl mit netatalk als
auch mit samba zur Verfuegung zu stellen:
Werden die Daten via SMB (oder auch per mv) umherbewegt, so werden
die RessourceForks dabei _nicht_ beruecksichtigt und "verwaisen"
quasi.
Gleichzeitig haben die netatalk-Entwickler viel Energie aufgewandt,
um netatalk mit einem Unterbau zu versehen, der fuer konsistente DIDs
(Directory IDs, die das MacOS zur "internen Referenzierung" von
Dateien, z.B. zur Zuordnung von Aliassen zu ihren Originalen
verwendet) sorgt. Und ebendieser Mechanismus funktioniert _nur_,
wenn die entsprechenden Daten via AFP umherbewegt werden.

Sprich: Auf Dauer zerblaest man sich _mindestens_ diese DID-Zuordnung
total, wenn netatalk und samba die gleichen Sharepoints beackern.
 
> arbeiten tu ich übrigens grundsätzlich auf der konsole, also nix X oder so.

Das hat damit _ueberhaupt nichts_ zu tun.

> die grundsätzlichen sachen (iptables, cron, syslogd) laufen auch auf dem
> debian.
> 
> warŽs ein fehler, auf debian umzusteigen? 

Generell wuerde ich hierauf mit einem "nein" antworten.
Ob es aber der Koenigsweg ist, das stabile System dann mit
"externer" Software zu "veredeln", wage ich mal zu bezweifeln.

> oder hattet ihr auch diese
> probleme am anfang...?

Nun. gerade bei netatalk kann man viel falsch machen - wobei samba
dank der Vielfalt der Konfigurationsparameter auch gerne genommen
wird. ;-)

btw: Die "dotfiles" kannst Du der Regie von samba recht einfach
entziehen: Schau mal in man smb.conf nach "veto files".

Gruss,
Christian
-- 
Christian Schmidt | Germany
christian.schmidt@chemie.uni-hamburg.de



Reply to: