Aber sehr mysteriöse Pfadwahl: Der will nach /opt/norman (legt da sogar sein temp Verzeichnis ab, grmpf, dabei hab ich /opt r/o mounted) und nach /usr/bin und nach /usr/local/man.
Quark. Dieses komische /opt ist so ziemlich der größte Schwachsinn, den ich bisher gesehen habe und der auch noch von vereinzelten Distributionen unsinnigerweise verwendet wird.
Entweder Software unterliegt sauber meiner Paketverwaltung, dann gehört die Soft nach /usr, die Configdateien nach /etc und die variablen Daten nach /var.
Oder es ist selbst zusammengeschusterte Soft, dann gehört sie ausschließlich nach /usr/local (Wie der Name schon sagt.) Allerdings sollten auch hier /etc und /var entsprechend genutzt werden.
Such mal ein Programm in /usr und diversen Unterverzeichnissen.
dpkg -L [paket]
Da wirste kirre!
Keinesfalls In Opt finde ich jedes Programm, weil es da einen eigenen Pfad hat.
Was soll daran schlecht sein?
... dass es auf Unix-Systemen einfach unüblich ist. Bei BeOS oder MacOS mag es normal sein. Aber auf einem Unix-System (abgesehen von OSX) läuft das nicht von hause aus: Du muss entweder PATH erweitern oder Symlinks legen, Du musst entweder LD_LIBRARY_PATH erweitern oder /etc/ld.so.conf erweitern etc. pp.
Eine vernünftige Paketverwaltung weiß von jeder Datei, zu welchem Paket sie gehört, deshalb exisitiert das von Dir benannte Problem nicht.
Und wenn man Sachen von Hand kompiliert, dann gibt es immer noch GNU stow.
Im Übrigen ist das Norman-Paket wirklich dermaßen beschissen paketiert, dass man schreien möchte. Dass ein- und dasselbe Paket sich über /opt, /usr und /usr/local verteilt ist ein absolut hirntotes Layout.
Es gibt nix schlimmeres, als Distributionen, die alles Blind nach /usr hauen. Und dabei /usr/X11 noch übersehen. "Softwaremoster" wir mozilla, openoffice sollten nach /opt in _eigene_ Verzeichnisse. Die haben /usr nicht vollzumüllen. Gleiches gilt für Sofware, für die es keinen Quellcode gibt, wie z.B. acrobat reader.
P.S.: Ob /usr "user" oder "unix system resources" als Ursprung hat, ist nicht geklärt. Es gab beides.
Stimmt nicht. Acrobat will entweder nach /usr/Acrobat, /usr/local/Acrobat oder (bei vielen Distributionen) nach /usr/lib/Acrobat.
Stell Dir vor - einige Distributionen haben nichtmal ein /opt, und bloß weil SuSE das vor einiger Zeit mal eingeführt hat, muß es nicht Standard werden. Davon abgesehen - was spricht dagegen /opt r/o zu mounten? Darf analog bei Euch auch jedes Programm auf /usr rummüllen, wenn es Lust hat? rw Daten gehören nach /tmp oder /var, aber nicht nach /opt oder /usr.
Von BuBuMacher am Mi, 26. November 2003 um 21:35 #
Nun mal langsam mit den jungen Pferden.
/opt ist ganz normal UNIX und für fremde Programmpakete vorgesehen. /usr heisst UNIX System Runtimes und dort gehören eben die ausführbaren Systemdateien hinein.
Hmm - das ändert aber nix daran, das sich - zumindest bei mir (RH 9.0a) alle Programme standardmäßig unter /usr (+ Unterverzeichnisse wie share, lib, local, ...) installieren - ein /opt Verzeichnis habe ich nicht.
Stell dir vor dann ist diese Distribution nicht LSB konform. Es ist LSB standard und somit für mich ein Standard.
Auszug aus LSB: Applications may either install a message catalog in the MO format as specified by the info page in version 0.10.40 of the gettext source package, or the application may execute the msgfmt command during it's installation to compile the message catalog. In either case, the resulting output must be located in the package's private area under /opt, and the application may use bindtextdomain() to specify this location.
Das es in der LSB dazu bestimmt wurde, heisst noch lange nicht, das die LSB in allen Teilen sinnvoll ist. Leider hat da Suse zu viel Einfluss genommen.
Nicht alles, was als Standard bezeichnet wird, ist es Wert, es zu übernehmen. Windows ist ja auch "Standard" ...
Von 0xdeadbeef am Do, 27. November 2003 um 02:13 #
Das hat mit der LSB wenig bis nichts zu tun. Der hier ausschlaggebende Standard ist der FHS (File System Hierarchy Standard). Der sieht zwar ein /opt vor, allerdings kann so ziemlich alles, was danach unter /opt liegen soll, genausogut unter /usr gepackt werden. Dementsprechend erschließt sich mir der Sinn von /opt nicht wirklich, und einige Distris sehen das scheinbar so wie ich. Debian zum Beispiel hat zwar ein /opt-Verzeichnis, um dem Standard Genüge zu tun, allerdings ist es chronisch leer.
Ich für meinen Teil denke, dass der /opt-Tree wenig Sinn und das System im Zweifel unübersichtlicher macht. Am Beispiel von Slackware sieht man das sehr gut; die lassen so ziemlich jedes Paket selbst entscheiden, wo es denn hin will. Das führt dazu, dass zwar KDE in /opt, aber Gnome in /usr liegt, obwohl es dafür keinen (mir bekannten) vernünftigen Grund gibt. Sowas verkompliziert das System unnötig.
Von Thorsten M. am Do, 27. November 2003 um 09:05 #
Debian zum Beispiel hat zwar ein /opt-Verzeichnis, um dem Standard Genüge zu tun, allerdings ist es chronisch leer.
Aha... So wie ich die man-pages verstanden habe (hab grade keine Lust, das raus zu wühlen) installiert man unter debian nach /opt eben die Sachen, für die man kein Paket bauen möchte / kein Paket hat. Bei mir ist das die neueste OpenOffice-Variante, die neuesten drei Mozilla-Varianten (die neueste von /opt/bin/mozilla aus verlinkt, die älteren von /opt/bin/mozilla-x.y aus verlinkt) sowie einige andere Sachen, für die ich keine Pakete habe. Damit habe selbst installierte libs und dergleichen komplett enwirrt von irgendwelchen Dingen, dpkg so gerne installieren/löschen möchte.
Aha... So wie ich die man-pages verstanden habe (hab grade keine Lust, das raus zu wühlen) installiert man unter debian nach /opt eben die Sachen, für die man kein Paket bauen möchte / kein Paket hat.
Nee, dafür ist /usr/local (am besten verwaltet mit GNU Stow) da.
/opt hat nichts mit Freiheit zu tun. SuSE etwa packt dort kde und GNOME hin. Die Debian-Policy verzichtet schlicht und einfach auf /opt, weil sie ein einheitliches und klares Layout (alles nach /usr) bevorzugt. Es gibt schlicht und einfach keine klaren Kriterien dafür, wofür /opt eigentlich da ist.
Trotzdem bin ich nicht prinzipiell dagegen. Allerdings ist es völlig krank und hirntot, wenn ein Paket wie das von Norman gleichzeitig /opt, /usr und /usr/local nutzt. Kein Deb hat irgendetwas in /usr/local zu installieren. Dorthin gehört ausschließlich händisch installierte/kompilierte SW.
/opt für Virenscanner ist doch gang und gäbe: Kaspersky, Symantec, Bitdefender, NOD32 und jetzt halt auch Norman machen das so... ausserdem muss ich bei den meisten nur das Verzeichnis wegkopieren und gut ist. Die Konfig ist mit dabei. Also bei Virenscannern find ich's echt vernünftig...
/opt hat schon sonst ne Daseinsberechtigung. So ne gesamte DE wie KDE ist in /opt/kde mit sämtlichen apps einfach besser aufgehoben [Slackware]. Da find ich schneller etwas wenn ich was suche zum ändern ... sonst hätte ich 1000 andere Dateien im /usr/bin oder /usr/share
Grundsätzlich habe ich auch nichts gegen /opt, im Gegenteil - unter meinem Redhat hab ich es schon längst angelegt (ebenso in den frühreren Versionen) - was mich aber stört ist, daß Norman dort sein temporäres Verzeichnis anlegt und mich quasi zwingt, dort schreibenden Zugriff zu erlauben. Ein tempöräres Verzeichnis kann ich unter /var gelten lassen, aber doch nicht unter /opt! Außerdem ist es ziemlich blödsinnig, dann noch die manpages in /usr/local/man zu verstauen - ein Paket einmal quer durch das System!
Und was das LSB betrifft, so bin ich der Meinung, daß es lediglich eine Empfehlung darstellt. SuSE oder Slack hat/haben vor einiger Zeit damit angefangen, als LSB noch gar nicht verabschiedet wurde. Damals lief das allerdings völlig entgegen zu den anderen Distributionen.
Ja toll, symlinken wir doch quer durch das System.. Bei der Gelegenheit machen wir auch /usr/local/man zu /usr/share/man und meditieren eine Runde darüber, was das AV Programm eigentlich in /usr will, wenn es doch /opt haben kann ;)
Ich find's halt blödsinnig. Aber mit dem command line switch ist das okay.
\begin{schwarzmal} Jetzt werden Virenscanner für Linux bald kommerziell, folglich müssen irgendwann, die in den Virenherstellerlabor liegenden Linuxviren auf freien Fuß gesetzt werde. \end{schwarzmal}
*hey* könnte man argumentieren das linux endlich desktop-tauglich ist, weil es einen virenscanner gibt? weil es gar viren gibt? jetzt brauchen wir nur noch 0190dailer und spezielle Anti-dailer und Linux IST Desktop-tauglich
Also ich würde ja sagen dass es im Netz auch so schon genug Idioten gibt dies auch ohne "Auftrag" erledigen. Man könnte das ganze auch weiterspinnen und diverse Geheimdienste mit einbeziehen...
Jetzt, wo RAV von Microsoft aufgekauft wurde, suche ich nach einer Alternative, die im .deb-Format vorliegt und mit qmail zurechtkommt. Kennt da jemand was vernünftiges?
Mal unabhängig vom Linux-System eine Frage: Kann ich unter Debian nicht auch rpms einspielen??? Das sollte doch auch gehen. Oder widerspricht das dem apt-get-Gedanken?
Was die Lizenz betrifft, so habe ich mich auch vergeblich um Klärung bemüht. Ich maintaine für Debian ein Paket namens f-prot-installer, das f-prot herunterlädt und installiert. Da ich stattdessen lieber das eigentliche Programm paketiert hätte, habe dort angefragt, bzgl. der Bedingungen zur Weitergabe.
Ich habe die Leute ungefähr zehnmal angemailt. Ich habe keine einzige Antwort, nicht einmal ein "keine Zeit, wir melden uns später" bekommen.
Ich habe mithin den Eindruck, dass sie selbst nicht so genau wissen bzw. wissen wollen, was erlaubt ist und was nicht.
Wer es mit Lizenzen nicht so genau nimmt, wie Debian, der verteilt f-prot munter drauf los (z.B. die diversen Recovery-CDs, die der c't beilagen). Das ist Frisk Software schätzungsweise ganz recht, weil es die Popularität erhöht. Aber trotzdem ist das strenggenommen illegal, weil die Lizenz sich über das Thema Weiterverteilung ausschweigt. Und was nicht erlaubt ist, ist verboten.
Ich finde auf der Webseite von Norman nirgendwo einen Hinweis, dass die Lizenz ohne Einschränkung unter Linux genutzt werden kann. Hat jemand vielleicht den genauen Link? Die Downloadseite habe ich ja gefunden.
Von Denny Schierz am Do, 27. November 2003 um 11:06 #
Umgebung testen. Wir verwenden den Norman Linux Scanner bereits seit langer Zeit(Win/Linux beta) und immer wieder gab es Probleme mit Archiven (insbesondere Rar Dateien). Der Scanner hinterließ nur allzu oft ein "Schlachtfeld", weil dieser einen undefinierten Zustand einnahm was Amavis garnicht mochte. Am Ende ging nicht eine Mail mehr durch. Auch seine Speicher Anforderungen sollten noch gezügelt werden. Ich empfehle bevor er in einer wichtigen Umgebung eingesetzt wird, ihn ausführlichst zu testen. Ein gravierender Nachteil, wie ich finde, ist die Konfiguration per Java. Da ich leider nicht weiß, wie man Apache dazu bringt, das Java Interface aufzurufen, muss zur Konfiguration eine X System installiert werden. Da ich auf meinem Server kein X zur Verfügung steht, habe ich die Konfiguration auf einem Client vorgenommen und die *.cf Dateien auf den Server kopiert. Hier wäre ein Konsolen Interface wesentlich angebrachter. Auch der Support der Linux Version lässt etwas zu wünschen übrig. Diese Version wird noch etwas Stiefmütterlich behandelt. Ein Grund weshalb sie die Version ein Jahr kostenlos vergeben, wird wohl ein großangelegter "Beta" Test sein. Mal sehen, was daraus wird.
Von Neuromancer am Do, 27. November 2003 um 17:09 #
Der Norman Virus Scanner hat(te) in der Windows-Welt nicht unbedingt einen guten Ruf. Ich hab die letzten Tests darüber zwar vor zwei Jahen gelesen, aber da ist er ziemlich abgewertet worden ... Ich geb aber ehrlich zu, dass ich nicht mehr auf dem Laufenden bin, was die aktuelle Entwicklung angeht, da ich komplett auf Linux umgestiegen bin. Vielleicht kann da ja auch jemand mal was dazu sagen.
Aber sehr mysteriöse Pfadwahl:
Der will nach /opt/norman (legt da sogar sein temp Verzeichnis ab, grmpf, dabei hab ich /opt r/o mounted) und nach /usr/bin und nach /usr/local/man.
So einen Schwachfug kenn ich sonst nur von SuSE..
optionale sachen gehoeren halt nach /opt
mfg, atomical - http://www.linuxbasis.de
Entweder Software unterliegt sauber meiner Paketverwaltung, dann gehört die Soft nach /usr, die Configdateien nach /etc und die variablen Daten nach /var.
Oder es ist selbst zusammengeschusterte Soft, dann gehört sie ausschließlich nach /usr/local (Wie der Name schon sagt.) Allerdings sollten auch hier /etc und /var entsprechend genutzt werden.
Gruß
Mowgli
Such mal ein Programm in /usr und diversen Unterverzeichnissen.
Da wirste kirre!
In Opt finde ich jedes Programm, weil es da einen eigenen Pfad hat.
Was soll daran schlecht sein?
dpkg -L [paket]
Da wirste kirre!
Keinesfalls
In Opt finde ich jedes Programm, weil es da einen eigenen Pfad hat.
Was soll daran schlecht sein?
... dass es auf Unix-Systemen einfach unüblich ist. Bei BeOS oder MacOS mag es normal sein. Aber auf einem Unix-System (abgesehen von OSX) läuft das nicht von hause aus: Du muss entweder PATH erweitern oder Symlinks legen, Du musst entweder LD_LIBRARY_PATH erweitern oder /etc/ld.so.conf erweitern etc. pp.
Eine vernünftige Paketverwaltung weiß von jeder Datei, zu welchem Paket sie gehört, deshalb exisitiert das von Dir benannte Problem nicht.
Und wenn man Sachen von Hand kompiliert, dann gibt es immer noch GNU stow.
Im Übrigen ist das Norman-Paket wirklich dermaßen beschissen paketiert, dass man schreien möchte. Dass ein- und dasselbe Paket sich über /opt, /usr und /usr/local verteilt ist ein absolut hirntotes Layout.
Gleiches gilt für Sofware, für die es keinen Quellcode gibt, wie z.B. acrobat reader.
P.S.: Ob /usr "user" oder "unix system resources" als Ursprung hat, ist nicht geklärt. Es gab beides.
Andreas
So ein Käse! Dann gehört Dateien eines Users wohl auch nach /usr, was?
Stell Dir vor - einige Distributionen haben nichtmal ein /opt, und bloß weil SuSE das vor einiger Zeit mal eingeführt hat, muß es nicht Standard werden.
Davon abgesehen - was spricht dagegen /opt r/o zu mounten? Darf analog bei Euch auch jedes Programm auf /usr rummüllen, wenn es Lust hat? rw Daten gehören nach /tmp oder /var, aber nicht nach /opt oder /usr.
/opt ist ganz normal UNIX und für fremde
Programmpakete vorgesehen.
/usr heisst UNIX System Runtimes und dort gehören eben die ausführbaren Systemdateien hinein.
mfg, atomical - http://www.linuxbasis.de
Auszug aus LSB:
Applications may either install a message catalog in the MO format as specified by the info page in version 0.10.40 of the gettext source package, or the application may execute the msgfmt command during it's installation to compile the message catalog. In either case, the resulting output must be located in the package's private area under /opt, and the application may use bindtextdomain() to specify this location.
Nicht alles, was als Standard bezeichnet wird, ist es Wert, es zu übernehmen. Windows ist ja auch "Standard" ...
Gruß
Mowgli
Ich für meinen Teil denke, dass der /opt-Tree wenig Sinn und das System im Zweifel unübersichtlicher macht. Am Beispiel von Slackware sieht man das sehr gut; die lassen so ziemlich jedes Paket selbst entscheiden, wo es denn hin will. Das führt dazu, dass zwar KDE in /opt, aber Gnome in /usr liegt, obwohl es dafür keinen (mir bekannten) vernünftigen Grund gibt. Sowas verkompliziert das System unnötig.
Aha... So wie ich die man-pages verstanden habe (hab grade keine Lust, das raus zu wühlen) installiert man unter debian nach /opt eben die Sachen, für die man kein Paket bauen möchte / kein Paket hat. Bei mir ist das die neueste OpenOffice-Variante, die neuesten drei Mozilla-Varianten (die neueste von /opt/bin/mozilla aus verlinkt, die älteren von /opt/bin/mozilla-x.y aus verlinkt) sowie einige andere Sachen, für die ich keine Pakete habe. Damit habe selbst installierte libs und dergleichen komplett enwirrt von irgendwelchen Dingen, dpkg so gerne installieren/löschen möchte.
Gruß
Thorsten M.
Nee, dafür ist /usr/local (am besten verwaltet mit GNU Stow) da.
Das liegt daran, dass Debian generell keine unfreie Software enthält. Bei Gentoo kommt unter Opt zB das, was keine Sourcen mitbringt.
Trotzdem bin ich nicht prinzipiell dagegen. Allerdings ist es völlig krank und hirntot, wenn ein Paket wie das von Norman gleichzeitig /opt, /usr und /usr/local nutzt. Kein Deb hat irgendetwas in /usr/local zu installieren. Dorthin gehört ausschließlich händisch installierte/kompilierte SW.
/opt hat schon sonst ne Daseinsberechtigung. So ne gesamte DE wie KDE ist in /opt/kde mit sämtlichen apps einfach besser aufgehoben [Slackware]. Da find ich schneller etwas wenn ich was suche zum ändern
... sonst hätte ich 1000 andere Dateien im /usr/bin oder /usr/share
Und was das LSB betrifft, so bin ich der Meinung, daß es lediglich eine Empfehlung darstellt. SuSE oder Slack hat/haben vor einiger Zeit damit angefangen, als LSB noch gar nicht verabschiedet wurde. Damals lief das allerdings völlig entgegen zu den anderen Distributionen.
Ich find's halt blödsinnig. Aber mit dem command line switch ist das okay.
Jetzt werden Virenscanner für Linux bald kommerziell, folglich müssen irgendwann, die in den Virenherstellerlabor liegenden Linuxviren auf freien Fuß gesetzt werde.
\end{schwarzmal}
Aber ein Vergleich mit Versicherungen wäre passend.
bis denn,
Martin
Es geht um einen Virenscanner, der auf einem Mailserver läuft, um WindowsViren zu erkennen.
Grüße,
Hosi
Aber auf norman bin mal gespannt...
Grüße,
Hosi
Kann ich unter Debian nicht auch rpms einspielen??? Das sollte doch auch gehen. Oder widerspricht das dem apt-get-Gedanken?
Warum braucht man fertige Pakete?
Nett wenn es sie gibt, geht aber doch auch ohne.
sysinstall
Was Du ohne Quelltext mit deinem Compiler anstellst, möchtest Du bitte mal erläutern....
Grüße
Sebastian
Kannst dann das Beste für dich raussuchen!
Ich verwende momentan den fprot in Verbindung mit exiscan.
Da ist die kostenlose Lizenz allerdings etwas fragwürdig, man definiere "private Workstation".
Kann das Teil mit dem fprot mithalten?
Sven
Ich habe die Leute ungefähr zehnmal angemailt. Ich habe keine einzige Antwort, nicht einmal ein "keine Zeit, wir melden uns später" bekommen.
Ich habe mithin den Eindruck, dass sie selbst nicht so genau wissen bzw. wissen wollen, was erlaubt ist und was nicht.
Wer es mit Lizenzen nicht so genau nimmt, wie Debian, der verteilt f-prot munter drauf los (z.B. die diversen Recovery-CDs, die der c't beilagen). Das ist Frisk Software schätzungsweise ganz recht, weil es die Popularität erhöht. Aber trotzdem ist das strenggenommen illegal, weil die Lizenz sich über das Thema Weiterverteilung ausschweigt. Und was nicht erlaubt ist, ist verboten.
oder deb-Zeile nennen *grosses Interesse*
Thx.
WeihnachtsgeschenkGPl
:)
Die GPL soll die berühmten Freiheiten (Nutzung, Modifikation, Weitergabe) sicherstellen. Es geht ihre um Freiheit
Der kostenlose Virusscanner ist lediglich ein Werbegeschenk. Also Freibier.
Cu
Stef777
Ich empfehle bevor er in einer wichtigen Umgebung eingesetzt wird, ihn ausführlichst zu testen. Ein gravierender Nachteil, wie ich finde, ist die Konfiguration per Java. Da ich leider nicht weiß, wie man Apache dazu bringt, das Java Interface aufzurufen, muss zur Konfiguration eine X System installiert werden.
Da ich auf meinem Server kein X zur Verfügung steht, habe ich die Konfiguration auf einem Client vorgenommen und die *.cf Dateien auf den Server kopiert. Hier wäre ein Konsolen Interface wesentlich angebrachter.
Auch der Support der Linux Version lässt etwas zu wünschen übrig. Diese Version wird noch etwas Stiefmütterlich behandelt. Ein Grund weshalb sie die Version ein Jahr kostenlos vergeben, wird wohl ein großangelegter "Beta" Test sein.
Mal sehen, was daraus wird.
cu denny
Was auch nicht geht ist der NIU
# ./niu
You need a valid authentication key to update this demo version of
NVC.
Sehr seltsam das ganze !!
Wie der Goldenboy immer sagte.. STUDY! STUDY! STUDY!
;P *fg*
/usr/bin/niucf: Can't locate Java Virual Machine
Freudsch?
hier kanste alles herunterladen, und installieren, und unbedingt die readmes etc. durchlesen ;)
ftp://ftp.norman.ch/NVC/Linux/Installationsanleitung_NVC_LINUX.pdf
Ich geb aber ehrlich zu, dass ich nicht mehr auf dem Laufenden bin, was die aktuelle Entwicklung angeht, da ich komplett auf Linux umgestiegen bin. Vielleicht kann da ja auch jemand mal was dazu sagen.
Aktueller Vergleich: http://www.heise.de/security/artikel/39978