DanielB
-
Gesamte Inhalte
493 -
Benutzer seit
-
Letzter Besuch
Inhaltstyp
Profile
Forum
Downloads
Kalender
Blogs
Shop
Alle Inhalte von DanielB
-
Du vergisst anscheinend, dass die Umstellung nicht von irgendeiner Frickelbude mit 10 Leuten die sich Linux Admins nennen ausgeführt werden wird, sondern von Profis Auch wenn es noch eine separate Auschreibung über die Umstellung geben wird, bin ich mir ziemlich sicher, dass IBM & SuSE den Zuschlag für die Umstellung erhalten werden. Es würde mich nicht wundern, wenn IBM & SuSE dabei ein Verlustgeschäft in Kauf nehmen, wobei IBM das aus der Portokasse zahlt. Probleme wie "die Netzwerkkarte erkennt den Fiber Anschluss nicht" oder "das GUI ist nicht der Hit" wird es nicht geben. Die rein technische Seite einer solchen Umstellung ist für o.g. Firmen durchaus überschaubar und wurde sicherlich im Vorfeld durch diverse Studien etc. ermittelt. Beide Firmen werden sich hier sicherlicht nicht auf ein Softwareabenteuer ala "Ma gucken ob dat lübt " einlassen. Dafür steht, für beide, zu viel auf dem Spiel.
-
Ich bin mir nicht sicher wie apt die http_proxy Umgebungsvariable abfragt, bei Verwendung eines Proxy Servers mit Programmen wie z.B.Lynx. muss auch noch ein "http://" mit rein : http_proxy="http://<proxy_ip_oder_hostname>:<proxy_port>" Falls apt es nicht benötigt, nm
-
Ja, wenn die Linuxkiste direkt am Netz hängt ist es besser, das ganze über ip-up zu regeln. Wenn die Kiste jedoch hinter nem Router hängt funktioniert es logischerweise nicht über ip-up. pppd übergibt auch diverse Verbindungsparameter an das ip-up Skript, so dass Du die IP auch über diese Parameter herrausfinden kannst (macht das lynx --source...) unötig.
-
Ja, starten solltest Du es über Cron. Für Dial On Demand solltest Du _vor_ dem Aufruf von lynx z.B. ein Ping ausführen, um sicherzustellen, dass eine Netzwerkverbindung steht bevor lynx sich mit www.whatismyip.org verbindet.
-
Hi, meiner Ansicht nach ist DynDNS der bessere Weg, wenn Du jedoch wirklich mit einer Weiterleitung auf einer HTML Seite arbeiten willst, lässt sich das in etwa so erledigen : /home/foo/html-update/page-template.html <html> <head><title>IP Update</title></head> <body> IP : %IP% </body> </html> /home/foo/html-update/update.sh #!/bin/bash HTMLTEMPLATE="/home/foo/html-update/page-template.html" HTMLFILE="/home/foo/html-update/page.html" NCFTPPUT=/usr/bin/ncftpput LOGFILE="/tmp/ip-log" TMPFILE="/tmp/ip-tmp" DATE=`date +%D` LAST_IP=`tail -1 $TMPFILE` CURRENT_IP=`/usr/bin/lynx --source [url]http://www.whatismyip.org[/url]` echo $CURRENT_IP >> $TMPFILE if [ "$CURRENT_IP" == "$LAST_IP" ]; then echo -e "$DATE : IP [$CURRENT_IP] has not changed.\n" >> $LOGFILE else sed -e 's#%IP%#$CURRENT_IP#' < $HTMLTEMPLATE > $HTMLFILE $NCFTPPUT YOUR_OPTIONS_TO_UPLOAD_$HTMLFILE RETVAL=$? if [ "$RETVAL" -ne 0 ]; then echo -e "$DATE : Error -> $RETVAL\n" >> $LOGFILE else echo -e "$DATE : IP [$CURRENT_IP] updated.\n" >> $LOGFILE fi fi Du benötigst hierfür NcFTP, wenn Du den Part für das Hochladen der HTML Seite per FTP nicht selbst mit in das Skript einbauen willst. Das HTML Template musst Du selbst anpassen, im Skript die Optionen für ncftpput auch. Das ganze ist nicht getestet, sollte aber funktionieren
-
In /etc/securetty lässt sich einstellen über welche Konsolen ein direkter root Login erlaubt ist. Falls Du PAM verwendest, finden sich in /etc/security/access.conf weitere Möglichkeiten Logins zu beschränken.
-
Etwas in dieser Art müsste funktionieren : #!/bin/bash LOGFILE="/tmp/ip-log" TMPFILE="/tmp/ip-tmp" DATE=`date +%D` LAST_IP=`tail -1 $TMPFILE` CURRENT_IP=`/usr/bin/lynx --source [url]http://www.whatismyip.org[/url]` echo $CURRENT_IP >> $TMPFILE if [ "$CURRENT_IP" == "$LAST_IP" ]; then echo -e "$DATE : IP [$CURRENT_IP] has not changed.\n" >> $LOGFILE else # Aufruf deines DynDNS clients mit den entsprechenden Optionen hier # $CURRENT_IP an DynDNS client übergeben. # /usr/bin/ddlclient bla bla bla echo -e "$DATE : IP [$CURRENT_IP] updated.\n" >> $LOGFILE fi Die Datei /tmp/ip-tmp nicht löschen Das Skript dann über Cron in beliebigem Abstand aufrufen. Es ist wichtig, dass eine Abfrage stattfindet, ob sich die IP geändert hat. DynDNS blockt den Account, wenn Updates mit der selben IP zu oft wiederholt werden.
-
Ohne weiteres gar nicht. Dafür müsstest Du ein kleines Script starten, welches sich die aktuelle IP (z.B. von www.whatismyip.com oder von einem CGI Skript welches deine IP zurückliefert und auf einem Webserver liegt) besorgen. Diese dann mit deiner letzen IP vergleichen und dann, falls nötig den Client mit der neuen IP startet. Benutzt mal die Suchfunktion des Boards, ich meine vor längerer Zeit mal so ein Script gepostet zu haben.
-
Schau mal unter http://www.honeynet.org unter Challenges. Die Leute vom Honeynet Project fangen mit Hilfe von Honeynets die neuesten Explots, Angriffsmethoden etc. Vieleicht findest Du dort was interessantes.
-
Ok, dann sind wir uns da ja einig Jupp, das ist sicherlich ein Vorteil, keine Frage. Jedoch muss man dies auch in Zusammenhang mit "Werbeaussagen", wie "1 remote hole in the default install ..." sehen.
-
Ein _Remote_ Hole in der _Default_ Installation. (Default Installation = es läuft quasi nix nach der Installation, lokal ausnutzbare Lücken sind hierbei nicht berücksichtigt) Fehler gibt es auch bei OpenBSD. OpenBSD ist sicherlich eine gute Grundlage, wenn es um Sicherheit geht, jedoch ist es nicht _das_ fehlerfreie System zu dem es oft gemacht wird.
-
Aha, das wird vermutlich der Grund dafür sein, das es unzählige Firewall Appliances gibt, welche auf dieser "S_C_H_E_I_S_S_E" basieren. Aus dem selben Grund ergibt eine Suche auf Google nach "Linux Firewall" auch unzählige Ergebnisse. Natürlich sind all diese Firewall Tools und Extraprogramme nur aus eben diesem Grund für Linux entwickelt worden. Du solltest nicht alles blind glauben, was Theo, OpenBSD.org bzw. die diversen Ad. Mailinglisten sagen und dieses dann hier posten. Der iptables Syntax ist keinesfalls menschenunfreundlich und eine Steuerung über Skripte ist sehr flexibel. Auf www.netfilter.org finden sich 6 Security Announcements von 04.2001-05.2003. Einige betreffen mich nichtmal.Damit kann ich gut leben. OpenBSD's pf ist auch nicht fehlerfrei, keine Software ist das. Das Linux selbst ein einziges Chaos ist kannst Du Leuten wie Alan Coax erzählen, die vermutlich schon programmiert haben bevor Du diese Welt erblickt hast. Wie wäre es also mit _richtigen_ Argumenten. ?
-
NetSaint gibt es nicht mehr, das ganze wurde umbenannt und heisst jetzt Nagios. Es ist nett und übersichtlich, allerdings ist die Konfiguration relativ zeitaufwendig.
-
Slackware (www.slackware.com) oder Debian (www.debian.org), wenn es Linux sein soll, ansonsten eventuell OpenBSD (www.openbsd.org).
-
Ich benutze Syslog-NG, Perl, MySQL um Logfiles zu filtern und in eine Datenbank zu schreiben, welche ich dann über ein Webfrontend auswerten kann. Sowas ist relativ schnell gebastelt. Wenn Du einfach nur über den Status der Systeme informiert werden willst, schau mal unter http://www.nagios.org/
-
Ist relativ einfach möglich. Schau mal hier : http://www.linuxgazette.com/issue72/bright.html
-
Gimp fragt die Umgebungsvariable LANG ab. Diese kannst Du für dein System global in /etc/profile bzw. /etc/profile.d/ einstellen. Füge einfach ein Zeilt mit dem folgenden Inhalt hinzu : export LANG="de_DE"
-
Die Option -i lässt sich, logischerweise, nicht in der OUTPUT Chain verwenden, da es das eingehende Interface bestimmt. Für die OUTPUT Chain ist die Option -o zu verwenden, welche das ausgehende Interface definiert.
-
Hi, das Problem ist, wie die Fehlermeldung ja auch eindeutig sagt, dass die Konfigurationsdatei nicht gefunden werden kann. Kann Dir leider nicht sagen welchen Pfad der Packager des Programmes für die Konfiguration gewählt hat, aber diese wird, IIRC in der Datei config.h definiert. Lade Dir die Quellen für das Programm runter, entpacke diese und lies das README file. Dort ist erwähnt, wie Du das Problem beseitigen kannst.
-
Richtig, soweit zur Theorie. In der Praxis sind die segfaults, welche ich erlebt habe jedoch zu 95% auf Hardware und nicht auf Software zurückzuführen gewesen. Grade bei Standardprogrammen wie "ls" ist ein Fehler in der Software, welche die segfaults verursacht eher unwahrscheinlich. Eine defekte Library ist sicherlich möglich, würde aber sehr wahrscheinlich auch eine Menge andere Programme betreffen. Eine andere Möglichkeit, die in diesem Fall auch sehr wahrscheinlich ist, sind Probleme mit dem entsprechenden Verzeichnis bzw. Dateisystem. Das habe ich auch nicht geschrieben Segfaults sind auch nichts alltägliches, wenn man nicht grade als Programmierer tätig ist. Glücklicherweise ist es relativ leicht und schnell zu testen, ob es ein Hardwareproblem ist, deshalb habe ich ich dieses vorgeschlagen. Es ist grade bei Problemen dieser Art hilfreicht bestimmte Dinge ausschliessen zu können. Wenn bei den Tests, wie oben beschrieben, weitere Fehler auftreten ist es mit 99%tiger Sicherheit ein Hardware Problem. Ansonsten kann, im Falle eines Problemes mit shared-libs, mit Hilfe von "ldd" gecheckt werden, welche libraries von dem entsprechenden Programm verwendet werden. Danach kann ein Austausch der entsprechenden shared-libs vorgenommen werden bis das Problem nicht mehr auftritt. Was aber weitaus wahrscheinlicher als shared-libs als Fehlerquelle in Frage kommt sind Probleme mit dem Verzeichnis selbst. Die entsprechenden Frage für weitere Fehleranalysen hat Nic ja schon gestellt.
-
Ansonsten ist NcFTP ein guter FTP client. Zu finden hier : http://www.ncftp.com/
-
Segmentation faults weisen oft auf fehlerhafte Hardware hin. (i.d. R. Speicher, CPU, Board. Seg faults treten aber auch auf, wenn z.B. die CPU zu heiss wird. Besorg dir einfach mal den Quelltext von einigen, möglichst grossen Programmen und fang an alles auf einmal zu kompilieren. Wenn Du Fehlermeldungen wie z.B. cc exited with signal 11 oder Kernel Panics bekommst ist es ein Hardwareproblem und Du kannst anfangen Komponenten zu tauschen bis der Fehler nicht mehr auftritt.
-
Bei RPM Paketen kannst Du es so erledigen : /bin/rpm -ql paketname um eine Auflistung aller Dateien zum entsprechenden Paket zu erhalten. Bist Du Dir beim Paketnamen nicht sicher, hilft ein : /bin/rpm -qa | less bzw. /bin/rpm -qa | grep "paket_heisst_so_ähnlich"
-
Die AVM Treiber und isdn4linux sind 2 unterschiedliche Dinge. Die Treiber werden benötigt um auf die Hardware zuzugreifen, die isdn4kutils greifen später auf das ISDN device unter /dev zu. Ich erinnere mich an die Fritz Card PCI 2.0, welche zunächst nur mit dem CAPI Treiber von AVM funktionierte. Die Unterstützung für die isdn4linux Tools (isdncrtl, etc.) funktioniert aber trotzdem. Es kann sein, dass du bestimmte Module laden musst, um die Funktionalität für isdnctrl etc. zu bekommen. Eventuell musst Du auch noch die entsprechenden Device Dateien unter /dev/erstellen.
-
Ist das Projekt für die Schule, zu Lernzwecken oder für einen Kunden ? Bei letzerem würde ich Dir auf jeden Fall dazu raten die Firewall nicht mit YaST zu konfigurieren, Dich krätig mir der Materie auseinanderzusetzen (das ist nämlich nicht etwas was man in ein paar Stunden nebenbei macht) und eventuell auf eine andere Distribution auszuweichen. Ja, das sind die 3 Basis Ketten. Innerhalb dieser Ketten können benutzerdefinierte Ketten erstellt werden. Das ist sinnvoll um hinterher noch den Überblick zu behalten und auch besser für die Performance, da nicht immer alle Regeln abgearbeitet werden müssen. Das ist recht einfach zu lösen. Als erstes konfiguriert Ihr Squid mit transparent Proxy Support und er muss auf Port 8080 lauscht. Danach könnt Ihr mit folgender Regel alles auf den Proxy umleiten was auf den Ziel Port 80 (also http) geht : iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080 Jupp, du kannst und solltest die Default Policy auf DROP bzw. REJECT stellen. Die Forward Chain benötigst Du, wenn Du kontrollieren willst ob bzw. welche Pakete von einem Netzwerkinterface auf das andere gelangen dürfen. Auf der Netfilter Homepage ist gute Dokumentation dazu vorhanden.
