da_beatmasta

Betreibe eine aktuelle Smoothwall, weil sich bei IPCop in Sachen Updates und IDS seit einiger Zeit nix mehr tut. Seit dem Wechsel funzen aber einige Sachen nicht mehr so wie früher. Auf dem Server läuft ein transparenter Webproxy. Habe entsprechende cgi- Skripte so angepasst, dass weiter Port 3128 verwendet werden kann und den Proxy auf transparent im Webinterface gestellt. Auf meinem Client- Rechner habe ich in den Netzwerkeinstellungen die Smoothwall als Standardgateway und dritten DNS (nach den beiden internen Domain Controllern) eingetragen. Hab mal zwei Probleme: 1. Seit ich Smoothwall in Betrieb habe, funzt das Ansteuern von internen Webservern nicht mehr. Er versucht's immer über Smoothwall eine Anfrage nach draußen zu stellen. Ich muss jedes Mal erst die Proxyeinstellungen raus machen, um einen internen Webserver anzusteuern. Obwohl ich Proxy ignorieren für folgende Fälle im Firefox eingetragen habe: localhost, 127.0.0.1, 192.168.1.0/24 2. Die Transparenz funzt irgendwie nicht. Ich kann immer nur mit eingeschaltetem Proxy über Port 3128 arbeiten. Bei IPCop ging das ohne Probleme. Kann mir da jemand mal helfen?

Mittlerweile denke ich, hat's bei mir geklappt. Die Ursache ist wahrscheinlich in dem kleinen Absatz der README.TXT der Collection extension zu suchen "Note that the MediaWiki must be accessible from the render server, i.e. if your MediaWiki is behind a firewall you cannot use the public render server." Mein Server läuft auch nur in einem lokalen Netz, dass nach außen durch eine Firewall geschützt ist. Hilft nix, muss ein lokaler Renderserver her. Bei meinem Ubuntu- Server hat das was gebracht: http://edutechwiki.unige.ch/en/Mediawiki_collection_extension_installation#mwlib_installation_on_Ubuntu http://edutechwiki.unige.ch/en/Mediawiki_collection_extension_installation#mw-serv Evtl. sind noch Pfade und Rechte bei Dir anzupassen. Bei mir hat das auf jeden Fall mit PDF und ODF funktioniert.

Ja so habe ich den Versuch bei tar.gz- Dateien gemacht. Bei Bändern fällt der -z- Parameter weg und statt einer Datei halt /dev/st0 Dateiarchive sind vorhanden und da der Banddurchlauf mit -t funzt, scheint auch dort was drauf zu sein. tar und gzip sind definitiv installiert. Sonst würde gar nix funktionieren

Na danke trotzdem. Vielleicht hat ja jmd. anders noch einen Geistesblitz

Schon komisch Nur zum Verständnis: Vor dem open und mkdir Zeugs steht dann immer der Pfad oder Dateiname natürlich. Und weil ich nicht '-p' mache, kann es ja auch keine Besitzerprobleme o.ä. geben. Selbst wenn, schreibt Linux glaube nur die IDs beim 'ls' bin. Ja im Pfad sind Umlaute und Leerzeichen mit drin. Das kannste den Mitarbeitern 10x sagen, dass sie das nicht machen sollen und sie machen's trotzdem . Deshalb entpacke ich häufig auch immer das komplette Archiv/ Band.

Ich habe zum Glück die Bildschirmausgabe parallel in eine Logdatei schreiben lassen. Dort steht die wiederherzustellende Datei drin, wenn ich 'less' mache und dann danach suchen lasse. An den Bändern selbst kann es auch nicht liegen. Die sind erst vor kurzem getauscht worden und auch das Bandlaufwerk wurde parallel dabei gereinigt.

tar mit dem Parameter '-t' ist ohne Probleme durchgelaufen.

Ich schieb's mal über Nacht an. Dauert ja doch 'ne Weile :schlaf: Die Tapes nehm ich eigentlich auch nur, um von vergangenen Wochen die Daten wiederherzustellen. Sonst wird in ein tar.gz- File jeden So die Komplett- und Mo-Fr eine Teilsicherung mit Snapshots gemacht. Manchmal fällt's den Kollegen doch bissel später als bei der Komplettsicherung ein, wenn'se eine Datei versaut haben

Bringt natürlich das Archivlisting vom Tape. Is nur zu viel, um das hier einfach mal zu posten

Das mit dem GZIP- Komprimieren in eine Datei und nicht auf Band ist schon richtig. Die Rücksicherung vom Band dauert so schon einen halben Tag. Mit Komprimierung würde das noch mehr Zeit beanspruchen und die Bandgröße ist vollkommen ausreichend für eine unkomprimierte Sicherung. Das Listing mit dem Parameter -t vom Band klappt. 'mt -f /dev/st0 status' bringt nach dem letzten Wiederherstellungsvorgang folgende Ausgabe: drive type = Generic SCSI-2 tape drive status = -2130705408 sense key error = 0 residue count = 0 file number = 0 block number = 0 Tape block size 1024 bytes. Density code 0x81 (DLT 15GB compressed). Soft error count since last status=0 General status bits on (41010000): BOT ONLINE IM_REP_EN 'mt -f /dev/st0 rewind' bringt keine Meldung, d.h. keinen Fehler hervor. Das schlimme ist, gerade die Datei, die ich zum Wiederherstellen brauche, entpackt mir das Ding nicht

ls? das ist doch nur zum Anzeigen von Dateien in einen Verzeichnis, ähnlich wie 'dir' unter DOS. :confused: Falls Du damit das Verzeichnis meinst, wo ich die Dateien hin entpackt habe, das würde den Rahmen sprengen, sind 10tausende Dateien. Ansonsten habe ich zum Entpacken vom Band folgenden Befehl genommen: tar -xvf /dev/st0 -C /tmp/test Für das Entpacken aus einem Dateiarchiv folgenden Befehl: tar -xzvf backup.tar.gz -C /tmp/test Hoffe, es hilft trotzdem.

Hallo, wenn ich .tar.gz- bzw. tar Band- Archive entpacke, bekomme ich bei einigen Einträgen Fehlermeldungen: Kann open nicht ausführen: Datei oder Verzeichnis nicht gefunden Kann mkdir nicht ausführen: Datei oder Verzeichnis nicht gefunden Die Dateien werden auch tatsächlich nicht entpackt, was natürlich für eine Datenwiederherstellung schlecht wäre. Wer kennt das Problem und kann mir die Ursache bzw. eine Lösung drauf sagen. Vielen Dank schon mal im voraus.

locale-gen gibt es leider nicht unter OpenSuSE. Den Link zur YaST- Doku hab ich studiert und mal die Alias- Variante ausprobiert. Da geht es natürlich in der englischen Version im PuTTY. Aber auf der realen Konsole am Server sieht's trotzdem noch kryptisch aus, egal ob mit UTF-8, euro, ISO-8859-1, latin1, CP437 oder CP850. Kann irgendwie vom Display- Treiber oder über den Grub noch irgendwas Zeichentechnisches kommen?

Im PuTTY nicht ganz so schlimm heißt, dass zumindest die Rahmen im Textmodus ordentlich dargestellt werden. Umlaute und Sonderzeichen aber weiterhin kryptisch dargestellt sind. Was meinst Du mit "locales neu generieren lassen"? Hab testweise mal im YaST unter Sprache den Haken bei "UTF-8- Kodierung verwenden" gesetzt und eine neue PuTTY- Sitzung aufgemacht. Brachte aber das gleiche Ergebnis bei YaST. Habe ja irgendwie die Vermutung, dass YaST separat noch einmal für sich die Zeichenkodierung verwaltet, weil es, wie gesagt, auf normalen Konsolenausgaben funktioniert.

Und das ist das seltsame, mc oder auch Umlaute bei Konsolenausgaben (z.B. Dateilistings mit "ls") sind ohne Probleme lesbar. Bei PuTTY- Verbindungen sieht das Schriftbild nicht ganz so schlimm aus. Ist aber dennoch zerstört. Hier mal die beiden gewünschten Ausgaben: locale LANG=de_DE@euro LC_CTYPE=de_DE@euro LC_NUMERIC="de_DE@euro" LC_TIME="de_DE@euro" LC_COLLATE="de_DE@euro" LC_MONETARY="de_DE@euro" LC_MESSAGES="de_DE@euro" LC_PAPER="de_DE@euro" LC_NAME="de_DE@euro" LC_ADDRESS="de_DE@euro" LC_TELEPHONE="de_DE@euro" LC_MEASUREMENT="de_DE@euro" LC_IDENTIFICATION="de_DE@euro" LC_ALL= grep LANG | env LESSKEY=/etc/lesskey.bin NNTPSERVER=news MANPATH=/usr/lib/mpi/gcc/openmpi/share/man:/usr/share/man:/usr/local/man:/usr/lo cal/share/man HOSTNAME=xxx XKEYSYMDB=/usr/share/X11/XKeysymDB HOST=xxx TERM=xterm SHELL=/bin/bash PROFILEREAD=true HISTSIZE=1000 SSH_CLIENT=xxx.xxx.xxx.xxx 3550 22 MORE=-sl QTDIR=/usr/lib/qt3 SSH_TTY=/dev/pts/0 http_proxy=http://xxx.xxx.xxx.xxx:xxxx JRE_HOME=/usr/lib/jvm/jre USER=root LS_COLORS=no=00:fi=00:di=01;34:ln=00;32:pi=40;33:so=01;35:do=01;35:bd=40;33;01:c d=40;33;01:or=40;31:ex=00;32:*.cmd=00;32:*.exe=01;32:*.com=01;32:*.bat=01;32:*.b tm=01;32:*.dll=01;32:*.tar=00;31:*.tbz=00;31:*.tgz=00;31:*.rpm=00;31:*.deb=00;31 :*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.zip=00;31:*.zoo=00;31:*.z=00;31:*.Z=00;31 :*.gz=00;31:*.bz2=00;31:*.tb2=00;31:*.tz2=00;31:*.tbz2=00;31:*.avi=01;35:*.bmp=0 1;35:*.fli=01;35:*.gif=01;35:*.jpg=01;35:*.jpeg=01;35:*.mng=01;35:*.mov=01;35:*. mpg=01;35:*.pcx=01;35:*.pbm=01;35:*.pgm=01;35:*.png=01;35:*.ppm=01;35:*.tga=01;3 5:*.tif=01;35:*.xbm=01;35:*.xpm=01;35:*.dl=01;35:*.gl=01;35:*.aiff=00;32:*.au=00 ;32:*.mid=00;32:*.mp3=00;32:*.ogg=00;32:*.voc=00;32:*.wav=00;32: LD_LIBRARY_PATH=/usr/lib/mpi/gcc/openmpi/lib XNLSPATH=/usr/X11R6/lib/X11/nls ENV=/etc/bash.bashrc HOSTTYPE=i386 ftp_proxy=http://xxx.xxx.xxx.xxx:xxxx FROM_HEADER= PAGER=less CSHEDIT=emacs XDG_CONFIG_DIRS=/etc/xdg MINICOM=-c on MAIL=/var/mail/root PATH=/usr/lib/mpi/gcc/openmpi/bin:/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr /local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/jvm/jr e/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin CPU=i686 JAVA_BINDIR=/usr/lib/jvm/jre/bin INPUTRC=/etc/inputrc PWD=/root JAVA_HOME=/usr/lib/jvm/jre EDITOR=joe LANG=de_DE@euro PYTHONSTARTUP=/etc/pythonstart https_proxy=http://xxx.xxx.xxx.xxx:xxxx QT_SYSTEM_DIR=/usr/share/desktop-data SHLVL=1 HOME=/root LESS_ADVANCED_PREPROCESSOR=no OSTYPE=linux LS_OPTIONS=-A -N --color=tty -T 0 XCURSOR_THEME=crystalwhite no_proxy=localhost WINDOWMANAGER=/usr/X11R6/bin/kde G_FILENAME_ENCODING=@locale,UTF-8,ISO-8859-15,CP1252 LESS=-M -I MACHTYPE=i686-suse-linux LOGNAME=root CVS_RSH=ssh XDG_DATA_DIRS=/usr/share LC_CTYPE=de_DE@euro SSH_CONNECTION=xxx.xxx.xxx.xxx 3550 xxx.xxx.xxx.xxx 22 LESSOPEN=lessopen.sh %s LESSCLOSE=lessclose.sh %s %s G_BROKEN_FILENAMES=1 JAVA_ROOT=/usr/lib/jvm/jre COLORTERM=1 mc=() { . /usr/share/mc/bin/mc-wrapper.sh } _=/usr/bin/env OLDPWD=/root