Beiträge von zdia

Ach, es ist Rosenmontag

Habe soeben nach Erasers Anleitung das Module rewrite auf einem TS109pro (Apache 1.0) zum Laufen gebracht.

Um in Textpattern eine "clean url" zu bekommen, ist keine weitere Modifikation von .htaccess im Ordner /textpattern mehr nötig.

Vgl. auch die Anleitung auf:

http://forum.qnap.com/viewtopic.php?f=32&t=3512

Infos erhältlich unter: http://textpattern.com/

Ich habe schon Joomla, Wordpress und Dokuwiki installiert, aber sie liefen auf meinem kleinen Qnäppchen recht dröge.

Textpattern mit der wirklich effizienten Markupsprache Textile dagegen läuft verzögerungsfrei. Es ist ein kleines PHP-Programm, das auf der Mysql-Datenbank aufsetzt. Die Installation ist kinderleicht und gut beschrieben.

Das Programm ist etwas für Bastler, die mit CSS-Kenntnissen ausgestattet, ihr System bauen können. Ein Blog aber ist ruckzuck eingerichet.

Wenn man in der /etc/config/apache.conf die Zeile

ServerTokens Prod

einfügt, um dem apache seine Geschwätzigkeit abzugewöhnen, bleibt das ohne Wirkung.

ServerSignature Off

funktioniert dagegen.

Hat da jemand schon Erfahrungen mit dieser Einstellung?

Schreibberechtigung auf nfs-gemounteten Verzeichnissen ist nur möglich, wenn die UIDs der Dateibesitzer auf den jeweiligen Rechnern übereinstimmen.

Hier soll der Weg gezeigt werden, im TS109pro einen User mit einer passenden UID anzulegen, da er dort im Grunde nur eine Platzmarke für Speicherplatz ist, während die User auf den (Linux-)Clients Besitzer von vielen Systemdateien sind, die erst umständlich gefunden werden müssen. Da das Webinterface keine Kontrolle über die UID bietet, muss man den User manuell anlegen:

Zunächst das Einrichten des unix-Users mit einer passenden UID und der Option -u UID;

# adduser -h /share/HDA_DATA/newuser -s /bin/sh -u 1000 -G everyone -p geheim newuser

Dann das Einrichten des smb-Users:

# /mnt/ext/usr/local/samba/bin/smbpasswd -a newuser

Das Mounten per nfs kann dann wie im Forum beschrieben mit automount erfolgen.

Ja, ich habe mir die Pro-Version extra wegen des NFS-Supports gekauft, aber der ist unbefriedigend wegen der uid-Problematik bei schreibendem Zugriff.

Hierzu habe ich schon einmal einen Beitrag im englischsprachigen Qnap-Forum erstellt, habe aber bisher noch keine Antwort erhalten, vgl.

NFS file owner/permission issues: http://forum.qnap.com/viewtopic.php?f=35&t=6564&start=0

Qnaps erster User hat die uid=500, die gängigen Linux-Distributionen beginnen bei 1000. Extra für den Qnap jetzt alle meine UIDs auf den Clients auf den Wert 500 umzustellen, ist mir zuviel unprofessionelles Gefrickel mit unvorhersehbaren Seiteneffekten.

Könnte man im Qnap linuxmäßig in der exportfs mit der Option anonuid arbeiten, gäbe es eine saubere Lösung, die wird aber immer von dem Html-Interface der Web-Administration überschrieben!

Qnaps allein mögliche Lösung lautet:

"/share/HDA_DATA/dia" 192.168.178.25(rw,async,no_root_squash)

und die lässt nur die Lösung zu, dass ich als root zugreife. Die Option no_root_squash ist eigentlich eine ganz gefährliche, die normalerweise in den Linux Distris deaktiviert ist. Die Problematik mit den vielen UIDs könnte eigentlich nur NIS lösen, da gibt es aber, glaube ich, keine ipkg für den Qnap.

Die Qnap-NAS wollte ich eigentlich als zentralen Fileserver für alle meine Linux-Clients einsetzen, die ich mit unison synchronisieren wollte, aber von diesem Ziel bin ich noch weit entfernt

Auf meinem Zenwalk 6.0-Client ist nur noch der cifs-Zugriff möglich, smbfs ist nicht mehr im Kernel enthalten, mount.cifs aber verwehrt unverständlicherweise Schreibzugriffe, auch openOffice erlaubt kein Schreiben auf cifs-gemountete Verzeichnisse, da ist im Moment ein großer Wurm am Wühlen...

Ich werde doch wohl reumütig zu nfs zurückkehren...

Problem:
Auf meinem Qnap TS109pro ist Samba Version 3.0.23d installiert. Nach einem mount per smbfs auf meinen Linux-Clients hatte ich trotz erfolgreicher Authentifikation und vorliegender Schreibrechte auf der Datei keinen schreibenden Zugriff.

Lösung:
Das Problem konnte durch eine Modifikation der smb.conf behoben werden.

#       map read only = yes         map read only = permissions

Zur Erläuterung ein Auszug aus der manpage:

This is a new parameter introduced in Samba version 3.0.21.      Permissions - The read only DOS attribute is mapped to the effective permissions of the connecting user, as evaluated by smbd(8) by reading the unix permissions and POSIX ACL (if present). If the connecting user does not have permission to modify the file, the read only attribute is reported as being set on the file.

Da auch die DOS-Bits gesetzt sind:

map archive = yes                                                                                              map system = yes                                                                                               map hidden = yes

die Linux-Dateien ausführbar machen, was bei einer Datei-Synchronisation etwa mit unison zu Fehlermeldungen führt, ist es hilfreich, sie mit dem Parameter fmask=644 auszumaskieren

# mount -t smbfs //server/share /mnt/ -o username=user,password=xxxx,uid=client,fmask=644

Hallo,

in Fedora kenne ich mich nicht aus. Aber vielleicht geht es so wie in Suse: Im Browser statt http:// einfach smb:// eintippen.

Das Lesen der Dateien ist in der Regel kein Problem, die Probleme beginnen meistens beim schreibenden Zugriff...

klaus_ph:

Vielen Dank für den Tipp: ipkg install mlocate ... und das war's. Den midnight-commander und locate installieren, dann lebt es sich gleich leichter. Und wenn ich jetzt noch unison zum Laufen bekomme, dann lässt es sich mit dem Maschinchen gut leben.

Was Christian wahrscheinlich mit der Bemerkung meinte, locate brauche keiner, bezieht sich auf die Tatsache, dass der Markt windows-beherrscht ist und die Windows-Nutzer brauchen so etwas wie locate nicht. Immerhin verleugnen die Qnap-Leute nicht, dass im Untergrund ein Linux-System werkelt. Ich verstehe vom Marketing nicht so viel, aber vermutlich sichert die Windows-Orientierung das Überleben auf dem Markt.

Generell sehe ich die Tendenz eh so, dass das Betriebssystem keine Rolle mehr spielt und die Maschinen nur über ein Web-Interface, bzw. eine Management Console bedient werden (so wie das Qnap jetzt macht). Finde ich nicht gut, diese Entwicklung, aber es ist wohl so.

Mir ist eine gut kommentierte Konfigurationsdatei allemal lieber als ein Webinterface, das sich nur auf ein paar Optionen beschränkt und umständlich ausgelesen werden muss.

Ich habe einen TS-109pro und ebenfalls nach Weihnachten 2.1.2 Build 1114T eingespielt. Der Bittorrent-Client funktioniert nicht mehr. Die Zustandsliste zeigt nur den WAIT-Status. Die Ports auf dem Router sind offen. Auf meinen Linux-Rechner läuft bittorrent mit derselben Datei-Anforderung ohne Probleme.

Kann man den Bug irgendwo melden?

Zitat

ich bin nun soweit vorgedrungen, dass ich bei xmail einen pop ext User anlegen will---?

probiere das lieber mit phpxmail. Das Wiki http://wiki.qnap.com/wiki/Category:XDove erklärt alles im Detail.

Zitat

Was muss ich genau beim Outlok eingeben?

Leider benutze ich Windows nur noch zum Spielen. Bei Thunderbird könnte ich dir helfen.

Das Projekt in diesem Thread ist für mich beendet. Ich arbeite jetzt nur noch mit dem neuen XDove-Paket.

Zitat von "wiedis"

2. Wie geht denn das mit dovecot weiter? Erfahrungen? Ich habe gesehen, dass man per ipkg auch einen cyrus-imapd auf dem NAS installieren kann. Geht
Imap in Verbindung mit Thuderbird auch damit?

Ich habe im Moment wenig Zeit. Dann werde ich mit dovecot weiterarbeiten. Im Moment habe ich bei den Neben-Clients Thunderbird angewiesen, die Mails auf dem xmail-Server nicht zu löschen, es sei denn die, die ich explizit lösche. Nur bei Abholung durch den Thunderbird auf dem Haupt-client werden die Mails auf dem xmail-Server auch gelöscht. Damit kann ich gut leben.

Zitat

Auf dem pop3 lagen ca. 140 Mails mit ca. 15MB Platzbedarf.
Der Xmail-Account war per default auf 10MB Mailspace begrenzt (habe ich jetzt auf 1000MB hochgesetzt).
PhpXmail zeigt mir aber nur 77 Mails mit 10.2MB Platz an - wo ist der Rest???

Ich fürchte, im Daten-Nirwana, aber vielleicht hilft dir etwas googeln in xmail-Foren. Viel Glück.

Ganz kurz noch die Parameter für phpxmail:

Beim Login:

Server name: meindyndns-name
User name: admin
Password: password

Unter server domains wird das grüne Kreuz new domain angeklickt.
Als Name für die neue Domain wird das dyndns-Schema meinname.homelinux.org nur in der Form homelinux.org akzeptiert.
In der domain können dann neue User angelegt werden. Im Menüpunkt ext POP3 wird der externe Mailserver definiert, bei mir pop.gmx.net. Der Spam-Filter funktioniert dort sehr gut.

Wie komme ich an meine Post in meinem xmail-Postfach?

Mit Thunderbird habe ich ein neues Konto angelegt
Als Pop-Server auf Port 110 habe ich die Home-IP des Qnap-Servers für die soeben mit phpxmail angelegte emailadresse eingetragen.
Den Smpt-Server habe ich bei gmx mit meiner echten gmx-emailadresse gelassen, da gmx keine mails von mailservern mit dynamischer IP-Adresse empfängt.

Jetzt ist nur der pop3 Status quo erreicht. Ziel ist ja eigentlich der IMAP-Modus, so dass von allen Home-Clients aus die elektronische Post abgeholt werden kann.

Gratulation an QNAPAndy und silas für die gelungene Implementation von xmail und phpxmail!

Mal sehen, wie das mit dovecot weitegeht ...

Zitat

shell-init: error retrieving current directory

Also da komme ich nicht weiter. Es scheint sich auch hier wieder um ein
chroot-Problem zu handeln, genauer um ein Problem in der Routine chroot_init, die in kompilierter Form vorliegt und daher nicht analysiert werden kann.:
Sie legt etwas im Flash-Speicher ab und da, meine ich, müssten die Entwickler ran. Der XMail-Dämon läuft aber wie gesagt trotz der zwei Fehler-Meldungen ordentlich.

# /sbin/chroot_init --help
Usage: flash_nasconf_trans
Transfer/Fix NAS Config partition in Flash. (e.g. Use offset:327680 to store MAC Addr)

Da lasse ich lieber die Finger davon ...
Nur noch zum Einkreisen des Problems:

# /etc/init.d/xmail.sh stop
Shutting down xmail... # xmail.sh ruft /sbin/chroot_init "/etc/init.d/xmail-main.sh" stop
# chroot_ini wechselt zum neuen Root-Verzeichnis ROOTFS=/mnt/HDA_ROOT/rootfs_2_3_6
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
Beginn xmai-mainl.sh # Eine kleine von mir eingefügte Echo-Meldung zu Beiginn des xmail-main.sh
Stopping XMail server: XMail.

[/] # chroot /share/HDA_DATA/.qpkg/XMail/chroot: cannot execute /bin/sh: No such file or directory

Nach etwas Googlen hat sich herausgestellt, dass chroot deswegen nicht funktionieren kann, weil sich im neuen root-Ordner / ja keine /bin/sh-Datei befindet, sondern nur folgende ausführbare Dateien:

[/share/HDA_DATA/.qpkg/XMail/bin] # ls
CtrlClnt* MkMachDep* MkUsers* XMCrypt* XMail*

QNAPAndy hat in seinem Forumsbeitrag in seiner Quelldatei vermutlich alles Nötige in den neuen root-Ordner gepackt
ftp://csdread:csdread@ftp.qnap.com/NAS/ThirdPartyApp/xmail-1.24_phpxmail-1.5_ARM-chroot-tsx09.tar.gz
Die Datei ist übrigens nicht mehr vorhanden, sodass ich das nicht überprüfen kann.

Der Grund für die Unmöglichkeit, sich einzuloggen, liegt wohl eher darin, das phpxmail auf Port 6017 auf den xmail-Dämon lauschen will, der ist aber nicht da.
# ps ax |grep Xmail
8960 admin 476 S grep Xmail

Na, dann starten wir ihn mal:

# /etc/init.d/xmail.sh startshell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directoryshell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directoryStarting XMail server: /usr/bin/XMail: error while loading shared libraries: libssl.so.0.9.7: cannot open shared object file: No such file or directorycat: /var/run/XMail.pid: No such file or directoryXMail.[ ]

Hoppla ...

Frase hatte hier im qnap-Club das Problem auch:

Zitat

guck dir das mal an http://forum.qnap.com/viewtopic.php?p=36549#p36549 da steht wie man eine fehlene lib nachinstalliert hab bei mir auch geklappt.

Auf Seite 3 hat silas dort in einem Forumsbeitrag sehr schön beschrieben, wie man diese Bibliothek nachinstalliert. Mit Hilfe des mc ging das auch recht schnell

# /etc/init.d/xmail.sh start
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
Starting XMail server: XMail.[ 9167 ]
# ps ax | grep XMail
 9167 admin      1760 S   /usr/bin/XMail
 9218 admin       508 S   grep XMail

:thumb:

Eine kleine Kontrolle durch einen erneuten Login-Versuch bei phpxmail:

:thumb:

Die zwei Directory-Fehler werde ich beim nächsten Mal analysieren. Und dann wird die Post abgeholt ...

Hallo Gemeinde,

ich will es wagen...

Warum?
Thunderbird, bzw. Icedove, auf einem Client akzeptiert ohne Verrenkungen kein Mailverzeichnis auf einem Netzlaufwerk. Kmail verlangt die Installation von vielen KDE-Bibliotheken und der Kontact-Suite, claws-mail akzeptiert nur lokale Ordner. Ich würde, wie schon mehrmals in den Foren geäußert, gerne von verschiedenen Clients aus Zugriff auf meine Post haben. Als Lösung bietet sich die Installation eines pop3-Holdienstes (xmail) und eines imap-Bereitstellungsdienstes (dovecot) an.

Bisherige Installationsschritte:

Basis waren diese Links:
http://forum.qnapclub.de/viewt…&p=6303&hilit=xmail#p6303
http://forum.qnap.com/viewtopic.php?f=86&t=991

Ich habe zunächst das ipkg mit Hilfe des qpkg-Dienstes erfolgreich installiert (Lehnsessel-Variante "sit back")
Vorsichtshalber habe ich gleich noch das php- und das phpadmin-Modul installiert.

Danach wurde die Datei http://219.87.144.196/QPKG/TS-109/XMail_1.24_TS-109.qpkg installiert.

Der Qweb-Server ist aktiviert.
Eine dyndns-Adresse liegt vor, der Router weiß davon und die Ports für xmail, smtp und pop3 sind auf die IP-Adresse des Qnap in meinem Heimnetzwerk weitergeleitet.

Ein kurzer Test mit Aufruf meiner dyndns-ip zeigt, dass der Qnap-Webserver antwortet.
Auch die Browser-Eingabe qnap-homeIP/phpxmail zeigt das gewünschte Web-Interface.

Ab jetzt wird es hakelig:
Das Formular Server hinzufügen bekommt folgende Infos:

dyndns-Name
homeIP des Qnap-Servers
6017
admin
password

Das wird brav akzeptiert, aber der nun mögliche Login als admin scheitert:

Fehlermeldungen werden keine ausgegeben.

Erste Kontrolle der Logindaten:

[/] # cat /share/HDA_DATA/.qpkg/XMail/var/MailRoot/ctrlaccounts.tabadmin   15041616120a1701

So soll es per default auch sein...
Merkwürdig ist auch:

[/] # chroot /share/HDA_DATA/.qpkg/XMail/
chroot: cannot execute /bin/sh: No such file or directory

Wahrscheinlich findet auch phpxmail die Datei ctrlaccounts.tab nicht ...

Bisher hat also alles recht schön geklappt. Jetzt muss ich doch hinab in die Linux-Tiefen (Es ist ja nicht so, dass man sich nicht gerne auch als Linux-Anwender von windows-orientierten Installationsskripten verwöhnen ließe). Zuvor wollte ich nur noch kurz fragen, ob jemand schon Erfahrungen mit dem XMail_1.24_TS-109.qpkg-Paket gemacht hat und mir vielleicht ein paar Tipps geben könnte?

Schönen Dank schon mal

Hallo Stachel,

vielen Dank für deine Mühe.

Auf meinem Notebook habe ich zenwalk, ein Slackware-Derivat: klein, schnell, zuverlässig und ohne Schnickschnack. Leider erfordert dort der Minimalismus etwas mehr Installationsaufwand. Den habe ich hier beschrieben: http://support.zenwalk.org/viewtopic.php?f=16&t=19008

Auf meinem großen Rechner läuft opensuse 10.3 und da war die Installation tatsächlich ein Kinderspiel:

Zunächst /etc/auto.master und /etc/auto.misc anpassen:

cat /etc/auto.master/NAS    /etc/auto.misc

cat /etc/auto.misc


dia             -rw                     192.168.178.24:/dia

Die Option -fstype=nfs ist default und muss nicht angegeben werden. Die Slackware-Version kennt noch das Uralt-Verhalten des Automounters, nämlich nichts anzuzeigen, bis das Unterverzeichnis, das wie gesagt unsichtbar ist, aufgerufen wird. Die Implementation der suse-Fraktion zeigt auch das leere virtuelle Verzeichnis an. Alle Achtung, insgesamt sehr saubere Implementation.

Zuletzt in suse den Runlevel-Editor öffnen und das Kästchen autofs anklicken, um den Dämon dauerhaft zu installieren.

Statt /NAS könnte man auch /C: eingeben

Mit meiner Hitachi P7K500 läuft der kleine Server unhörbar, wird nur handwarm und verbraucht (hoffentlich) nur 13 Watt. Das hätte ich mit einem Linux-Barebone für 280 € nicht hingekriegt...

Als Linuxer hat man es mit dem kleinen NAS-Server wahrlich nicht so leicht wie die Windows-Fraktion:

Das NAS-Laufwerk ist unter Windows bequem über einen Laufwerksbuchstaben erreichbar, während man als Linuxer zunächst mal aus der Wäsche schaut. Kein freundlicher Hinweis, kein Link auf eine Internet-Seite mit Tipps für Linux-User, nichts. Der Werbehinweis auf das verwendete Dateisystem ext3 entpuppt sich als heiße Luft.

Genug gegrummelt, hier der Lagebericht:

Die Dateisysteme lassen sich vom Client aus manuell schön einbinden, als nfs oder als smbfs

mount -t nfs 192.168.178.24:/dia /mnt/dia
oder:
mount -t smbfs -o username=dia,password=???? //192.168.178.24/dia /mnt/dia

Da die qnap-Station über einen Wlan-Router eingebunden ist, klappt das Einbinden per fstab nicht, da das Wlan auf dem Client erst nach dem Einbinden der Festplatten installiert wird.

Hat jemand Erfahrung mit dem Aufruf von automount, das beim Betreten des Dateipfades zur Laufzeit das entsprechende Verzeichnis einbindet? (Damit wir es so schön haben wie die Windows-User, auch wenn wir mehr bezahlen müssen)