DevilDawn

Dann ist /lib/64 nicht im suchpfad Entweder LD_LIBRARY_PATH setzen (schlechte Idee im Grunde) oder die libpfade konfigurieren (Linux oft /etc/ld.so.conf, Solaris: man crle(sp?)) und -> man ldconfig

Trete auch du der Initiative "Ignorieren statt Flamen" bei Leite deine Antworten mit "Ansatz:" ein und nutze dann deine Zeit für Produktiveres als sich Ärgern

RPM sucht gar nicht nach den libs, sondern nach installierten packages (die die libs potentiell enthalten). Du kannst rausfinden zu welchen packages die libs auf deinem filesystem gehören: rpm -qf /pfad/zur/datei Wenn du sicher bist das du alles hast (und es eben nicht mit RPM installiert wurde) erzwinge die installation durch rpm --nodeps -i php-snmp-5.0.4-10.i386.rpm (auf eigenes Risiko ) /edit: Ebenfalls --nodeps für dein zweites Problem

Beim Supernetting sucht man die erste Netzmaske die alle betroffenen Hosts einschliesst. Das hat Binär zu geschehen. 1) 192.168.1.2 2) 192.168.0.3 3) 192.168.0.4 4) 192.168.0.12 Die ersten der 2 Bytes der Dottet-Decimal Notation können wir weglassen. Es reichen die hinteren 2 Bytes 0000 0001 0000 0010 -> 1.2 0000 0000 0000 0011 -> 0.3 0000 0000 0000 0100 -> 0.4 0000 0000 0000 1100 -> 0.12 ----------------------------- 1111 1110 0000 0000 -> Netmask, die Bits die sich nicht ändern 255.255.254.0 -> freq.9 wins /23 reicht also aus. Das wäre der Bereich von 192.168.0.0 (Net-Address) bis 192.168.1.255 (Broadcast-Address), 256*2 = 512, - 2 = 510 usable Addresses

Offenbar kümmern dich Subdirectories nicht. Dann reicht es die filemtime auszugeben. Aber:

Dann hättest du vielleicht an irgendeiner Stelle auch mal das gewünschte Betriebssystem nennen sollen.

Sicherheitstechnisch wäre es bedenklich wenn das ohne Probleme ginge. Im Unix-Umfeld in LANs ist oft noch der fingerd aktiviert, so das finger @host eventuell geht. Solaris bietet sogar extra ein Befehl rusers an um dies herauszufinden. Für Windows ist mir nichts bekannt, es sei denn man kann etwas derartiges über SMB rausfinden. Ein CMD.exe Kommando ist IMHO dafür aber nicht Vorhanden.

AFAIK Steckt doch ein Intel Yonah in dem Teil?

Richtig. Der Secondary ist keine sekundäre Mailbox für den User. Er sorgt nur dafür das keine Mails verloren gehen die Unterwegs zu dir waren.

MX-Records sind keine Postfächer, sondern zuständige Mailserver (die theoretisch mehrere Tausend Postfächer haben können). Mail an user@domain.tld ==> Kontaktiere Mailserver (MX) für "domain.tld" und liefere dort die Mail in das Postfach für "user" ein. Der MX-Record hat zusätzlich eine Nummer, eine sogenannte Priority. Wenn man mehrere MX-Records in sein DNS Einträgt kann man dadurch entweder Mailserver Loadbalancen (wenn alle die gleiche Priority haben) oder man kann Fallback-Mailserver definieren (wenn die Einträge verschiedene Priority haben). In meiner Domain z.B. ist mein Server selber Haupt-MX, mein Provider nimmt netterweise aber auch Mail für mich an (die er dann an meinen Server schickt sobald dieser wieder Verfügbar ist) - er ist also mein "secondary" MX. PS: Natürlich kannst du nicht einfach irgendeinen Mailserver als secondary bei dir Eintragen. Der Betreiber deines Secondaries muß es natürlich auch bei sich entsprechend Konfigurieren.

Das muß der Machen der deine Domains verwaltet - also für dich die Nameserver stellt. Lässt sich auch unter Windows leicht rausfinden: -> Welche Nameserver sind für eine Domain zuständig? Q:\>nslookup -q=NS google.com Server: ns.intern.firma.de Address: 10.10.10.53 Nicht autorisierte Antwort: google.com nameserver = ns4.google.com google.com nameserver = ns1.google.com google.com nameserver = ns2.google.com google.com nameserver = ns3.google.com ns4.google.com internet address = 216.239.38.10 ns1.google.com internet address = 216.239.32.10 ns2.google.com internet address = 216.239.34.10 ns3.google.com internet address = 216.239.36.10 Analog: Welche Mailserver sind zuständig? Q:\>nslookup -q=MX google.com Server: ns.intern.firma.de Address: 10.10.10.53 Nicht autorisierte Antwort: google.com MX preference = 10, mail exchanger = smtp2.google.com google.com MX preference = 10, mail exchanger = smtp3.google.com google.com MX preference = 10, mail exchanger = smtp4.google.com google.com MX preference = 10, mail exchanger = smtp1.google.com google.com nameserver = ns1.google.com google.com nameserver = ns2.google.com google.com nameserver = ns3.google.com google.com nameserver = ns4.google.com smtp2.google.com internet address = 64.233.167.25 smtp3.google.com internet address = 64.233.183.25 smtp4.google.com internet address = 66.102.9.25 smtp1.google.com internet address = 216.239.57.25 ns1.google.com internet address = 216.239.32.10 ns2.google.com internet address = 216.239.34.10 ns3.google.com internet address = 216.239.36.10 ns4.google.com internet address = 216.239.38.10 Vermutlich(!) macht schlundtech.de das für dich - ob du über ein Tool die Möglichkeit hast selber Einträge im DNS zu machen weiß ich nicht. Ansonsten Support dort befragen, wenn der MX nicht wie gewünscht gesetzt ist. Ohne MX-Eintrag kann deine Domain weder Mail versenden noch empfangen.

Um mit Perl/PHP Mails zu versenden benötigst du einen Mailserver. Das ist in dem Falle dann das Exchange. Exchange sollte auf port 25 lauschen. Dein Mailhost ist damit die IP/der DNS-Name des Exchange-Servers. telnet <IP des Exchange> 25 sollte ungefähr so aussehen: telnet exchange.firma.com 25 Trying 10.20.30.40... Connected to exchange.firma.com. Escape character is '^]'. 220 exchange.firma.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830 ready at Thu, 2 Mar 2006 10:08:00 +0100 Wenn das funktioniert sollte die IP des Exchange auch im Script verwendet werden können.

Wenn ich das richtig Verstanden habe ist die Lage so: schlundtech.de Verwaltet deine Domains und stellt somit auch den Nameserver. Alle deine Domains und Hosts in den Domains zeigen auf eine IP, nämlich deinen Rootserver. Ich kenne confixx nicht, aber es ist meines Wissens Multidomain-fähig. Confixx kontrolliert nur die Konfigurationen deiner Dienste. Dein Webserver muss für jede deiner Domains (bzw. www.DOMAIN oder was auch immer) einen virtuellen Server Konfiguriert haben. Jedem virtuellen Server ist ein htdoc-Verzeichnis zugeordnet. Bei einem HTTP/1.1 Request eines Browsers (der technisch gesehen nur an die IP geht) schickt der Browser den gewünschten Hostnamen mit. Daran erkennt dein Webserver welchen Inhalt er rausgeben soll. Siehe auch Name based virtual hosting(apache.org). Unterstützt Confixx also mehrere Domains, so ist das Problem Webserver einfach zu lösen. Wenn jemand eine Mail an dich (eigentlich: Eine beliebige Mailadress XXX@example.com, wobei deine Domain dann exampel.com wäre) schickt schaut der Mailserver des Absenders nach dem sogenannten MX-Record (Mail eXchanger) deiner Domain. Damit bekommt er eine IP, an die er sich dann direkt wendet um die Mail zuzustellen. Optionen: 1. Du betreibst einen echten Mailserver auf deinem Server (sendmail, postfix) und sorgst dafür das alle MX-Records deiner Domains auf deine Server-IP zeigen. oder 2. Du lässt deinen Provider deine Mail empfangen, in einem POP-Mailfach, und holst diese von deinem Server automatisch ab. Gängige Programme (Unix vorausgesetzt) wären hier z.B. fetchmail gesteuert von cron. DNS wird etwas brauchen um zu aktualisieren, aber 1. würde gehen, ja. Mit Option 2. oben ist auch das Postfach-Problem keins mehr. Da der primäre Server down ist holt er keine Mail mehr, du kannst die Mails aber beim Provider direkt abholen. Zum "wie realisieren": Ohne Grundlagen in der Materie wirst du eine Menge nicht einfach so realisieren können. Die Wahrscheinlichkeit das du dir dabei in den Fuß schießt ist relativ groß; je mehr Services mehr oder minder planlos ans Laufen gebracht werden deste größer die Chance das der Server ausfällt - durch Fehlbedienung, oder schlimmer, Fehlkonfigurationen die weniger netten Menschen erlauben Zugang zu der Kiste zu bekommen. Das sicherste Betriebssystem ist das, mit dem man sich auskennt Mehr mag ich nicht sagen, es fehlt Hintergrund. - Ist der Server/die Domains reine Spielerei oder ist da ein ernster Hintergrund? - Ist der Wille Mail, DNS, Webserver zu lernen vorhanden? - OS? Webserver? Mailsoftware? etc.

IMHO gibts da nicht viel zu Routen. Der Provider wird euer Netz zu euch Routen. Der Router bei euch sollte auf der externen Seite zumindest eine der validen IPs haben, mit der passenden Netzmaske (x.x.x.x/30). Auf der anderen Seite dann euer internes Netz. Die default Netzrouten sollten drauf sein und das Standardgateway sollte der Providerrouter sein. Was dann noch gemacht werden muß hängt davon ab was ihr genau machen wollt. Hiding-NAT auf der externen Seite bietet sich offensichtlich an, wenn es keine DMZ mit Proxy etc gibt.

Naja deine Suchfunde zeigen beliebige Kernel Oops bei verschiedenen Applikationen, das hilft nicht weiter. Verwirrend ist daß kein Prozess angegeben ist, bzw eine wirre Zeichenkette und eine unmögliche PID. Ich konnte nur im SLOX Help Forum finden das andere das Problem auch haben (Kernel fast identisch, wohl selbe SLOX Version). Eine Lösung gibts dazu jedoch nicht. Kernel Panics lassen sich nicht so leicht durch rumgooglen lösen, und Ferndiagnose macht da wenig Sinn. Entweder Novell Support anhauen oder einen entsprechenden Dienstleister. Es kann auch an der Hardware liegen. Auf jeden Fall checken ob alle Komponenten auf der Kompatibilitätsliste sind. Gegebenenfalls mal auf älterer, erprobter (und Kompatibeler) Hardware testen.

Es stand nie außer Frage das er den Server kennt. Aber Server erlaubt keine Verbindung von deiner Maschine (wo das Script läuft) auf seinen SMTP Serviceport (tcp/25). Solange telnet <ip> 25 nicht geht wird Mailversenden weder mit perl noch mit php gehen. PS: Lokale Virenscanner mit eMail Check Feature verhindern gelegentlich Verbindungen auf Mailserver. ggfs mal Deaktivieren und erneut mit telnet testen.

SendEnv gibts erst ab OpenSSH 3.9 Siehe http://www.openssh.com/txt/release-3.9

uname -r bzw. uname -v, je nach OS. Am besten uname -a (all) das sollte immer klappen. Aber: Das mit dem Path zu reboot hatte ich weiter oben schon Erwähnt... wozu postet man Fragen wenn man die Antworten nicht liest? Cron hat nur ein limitiertes Set an Pfaden und das ist auch gut so. Es sollte immer ein voller Pfad zum Befehl angegeben werden.

Ja. Nennt sich in Fachkreisen "Firewall" oder "Application Level Gateway", je nachdem.

Ja, VMWare. http://www.vmware.com/de/products/server/gsx_faqs.html Hätte man aber auch finden können.

Der genaue Logeintrag wäre hilfreich, und außerdem sollte cron eine Mail an root schicken mit der Ausgabe des commands. Das müsste zum debuggen reichen. Vermutlich liegts am fehlenden Pfad zum Binary. Der muß dazu, a) aus Sicherheit, hat man in der cron Umgebung normal nur /usr/bin:/bin als $PATH.

Hm die Frage ist verständlich. Er hat sein eigenes System geschrieben und schwierigkeiten mit dem Parsen. Allerdings kann man da nicht wirklich helfen. Wenn dein Parse auf [if *] trifft muss er die folgenden Zeilen bis [/if] eh lesen. Dann prüfst du die Bedingung und schmeisst den gelesenen Teil entweder weg oder nicht. Das würde ich vermutlich vor dem echten Parsen des Templates tun, weshalb man solche Anweisungen in einigen Sprachen Präprozessoranweisungen nennt Also: - Template preprocessen. Ergebnis ist ein (neues) Template - Template in den Parser schieben. - Ergebnis rauswerfen.

Ich meine man sollte den Aufwand gegen den Nutzen abschätzen - nicht mehr, nicht weniger. Wenn ich ein Manntag brauche ein Script so zu schreiben das es nur 100% korrekte Angaben annimmt, das Script später aber eh nur von 2 Admins genutzt wird die Plan haben (sollten) was sie tun ist das leicht Overkill. Schreibe ich ein Script für einen Kunden der wenig Erfahrung mit Unix Shell hat dann ist es sicherlich Sinnvoll die Zeit zu investieren - wenn ein falscher Umgang mit dem Script verheerende Auswirkung haben kann. Wenn man so ein getopts-Framework natürlich eh schon hat kann man es ohne viel Aufwand aber immer wieder Einsetzen. Das schadet dann nichts.

Perl bietet sich natürlich an, da du kaum eine Unix-Kiste ohne Perl finden wirst. Gehört praktisch überall zur Basisinstallation Ausserdem hat Perl eine sehr angenehme Getoptions-Funktion. Aber es ist immer die Frage ob sich Perl lohnt. Genauso wie die Frage ob sich die Überprüfung der extra Parameter lohnt - man kann sie auch einfach ignorieren. Wie immer: "Depends!"

Nun, die legalen Optionen werden gehandled. Die illegalen Optionen ("-*") werden erkannt und angemahnt. Fehlt also nur der Check ob zuviele nicht-Optionen angegeben wurden. Das könnte man tun indem man sicherstellt das alle gegebenen Parameter von getopts abgefrühstückt wurden. Da $OPTIND dann auf (Anzahl Parameter)+1 stehen müsste kann man das Abfragen. #!/bin/bash # # Usage: bar [vVxq] -u USER BARVERSION="0.0.1beta-3RC1" VERBOSE=0 XENOPHOBIA=0 QUIET=0 while getopts ':vVxqu:' OPTION do case $OPTION in v) # Verbose VERBOSE=1 ;; V) # show Version echo "this is bar v${BARVERSION}" exit 0 ;; x) # be xenophobe XENOPHOBIA=1 ;; q) # be quiet QUIET=1 ;; u) # Username USERNAME=$OPTARG ;; \?) echo "Unbekannte Option \"-$OPTARG\"." >&2 exit 1 ;; echo "Option \"-$OPTARG\" benötigt ein Argument." >&2 exit 1 ;; esac done # check REQUIRED options # [...] TODO # check: unhandled params? let NUMPARAM=$#+1 if [ $NUMPARAM -ne $OPTIND ] then echo "Unbekanter Parameter an Position $OPTIND" >&2 # exit 1 fi # [...] exit 0 [/code] Generell ist die bash für sowas aber eigentlich nicht geschaffen.