-
Gesamte Inhalte
1584 -
Benutzer seit
-
Letzter Besuch
Inhaltstyp
Profile
Forum
Downloads
Kalender
Blogs
Shop
Alle Inhalte von dr.disk
-
Ok, jetzt weißt Du was die Abkürzung AVM eigentlich bedeutet. Und wo ist das Problem?
-
Wie wär's mit: cat testfile | perl -ne "s/^(.*)kdnr/kdnr/o; s/>.*$//o; print"
-
Da Du Dich selbst pingen kannst: wie sieht's denn mit der Verkabelung aus? Alles schön terminiert und hübsch mit T-Stücken versehen? Auch keinen Kurzschluß im BNC-Kabel? Womit ich auch regelmäßig Probleme hatte waren die Kabellängen. Nicht zu lang, sondern zu kurz. Kabel unter einem halben Meter sollte man nicht verwenden...
-
Das Runterfahren einer SuSE 7.2 Maschine auch Usern erlauben
dr.disk antwortete auf sebskulptura's Thema in Linux
Mit KDM hab ich die Anmeldung von KDE gemeint. Ok, bei reiner Konsole bringt die Dich nicht weiter. Anhalten darf ein normaler User das System aber nicht. Eine Möglichkeit das System anzuhalten/neuzustarten ist Strg-Alt-Entf - ob nun angehalten oder neugestartet wird legt man in der /etc/inittab fest. Eine andere Möglichkeit ist das Programm sudo. Schau Dir dazu mal die Manpage an, das würde auch funktionieren. -
Das Runterfahren einer SuSE 7.2 Maschine auch Usern erlauben
dr.disk antwortete auf sebskulptura's Thema in Linux
und kdm darf die Maschine anhalten. Das sollte es doch gewesen sein... (oder irre ich mich bei der Einstellung - dann müßte ich genauer nachsehen) -
Danach solltest Du Apache neustarten. Dann legt er die Dateien wieder an. Zu groß sollten die aber eigentlich nicht werden, läuft bei Dir kein Rotationsdienst?
-
Domain Logons steht auf yes? Gibt's den Unix und Samba-Benutzer mit dem Du Dich anmelden willst? Hast Du SuSE? Wenn ja findest Du unter /usr/share/doc/packages/samba die Samba-Dokumentation. Wenn Du kein SuSE hast mußt Du nachsehen wo Deine Distribution die Dokus ablegt. Schau Dir dort mal das Samba PDC-HowTo an, da steht alles drin was man zu diesem Thema wissen muß.
-
Suse 8.1 neue Abhängigkeiten Portmap/inet.d/ipsec
dr.disk antwortete auf sparstrumpf's Thema in Linux
Welches Dokument meinst Du? Den Runlevel-Editor von SuSE nehm ich nicht, ich bearbeite /etc/rc.d/rc?.d direkt oder mit insserv... Wahrscheinlich lag's daran, daß ich das Problem nicht hatte. -
Suse 8.1 neue Abhängigkeiten Portmap/inet.d/ipsec
dr.disk antwortete auf sparstrumpf's Thema in Linux
Das Startskript ist eigentlich nicht von SuSE, sondern von FreeS/WAN... Bei mir geht IpSec auch ohne Portmapper und inetd - kann Dein Problem also unter SuSE 8.1 leider nicht nachvollziehen. -
Von intern nach DMZ, da ist garantiert eine Firewall im weg... Wie läßt Eure Firewall FTP durch? Per Routing, per Proxy? Falls Routing probier mal den passiv-Mode abzuschalten. Bei den meisten FTP-Clients geht das mit 'pass', kannst aber auch mit 'help' nachsehen wie der Befehl heißt.
-
Bei welchem Linux? Bei SuSE kann Yast Dir die Arbeit abnehmen. Dort mußt Du einfach einen Samba-Drucker einrichten und das war's. Sollte 2000 verlangen, daß nur Domain-Mitglieder auf die Drucker zugreifen können, muß Samba vorher noch in die Domain aufgenommen werden.
-
Lies Dir mal das Samba BDC-HowTo, zu finden in jedem aktuellen Samba-Paket (2.2.x) durch. Bei SuSE findet man diese Dokus z.B. unter /usr/share/doc/packages/samba. Dort steht z.B. drin, daß Samba die Benutzerdaten nicht von einem PDC holen kann, der nicht auf Samba läuft. Sollte der PDC ebenfalls Samba sein würde folgende Möglichkeit funktionieren (wir in der Firma planen ebenfalls den Umstieg auf WinNT4 PDC und 2 mal BDC auf drei Samba-Maschinen. Die erste hat letzte Woche den Dienst aufgenommen, bisher nur als reines Domainmitglied). Als erstes darf der BDC nicht Domain-Master werden, also hier muß 'no' drin stehen. Bei Domain-Logons jedoch wiederrum 'yes'. Die smbpasswd Datei kann man mittels rsync synchronisieren, daß ist das kleinere Problem. Auch eine Verschlüsselung von rsync ist möglich: ssh mit Agent und ein paar intelligente Skripte oder rsync mit ssh tunnel (z.B. ssh selbst, stunnel, zeedebee usw.) Schwieriger wird's mit den Unix-Accounts. Samba wandelt die Rechte eines Benutzers auf Dateisystemsrechte um. Deswegen braucht Samba exisierende Unix-Accounts um den Zugriff auf Verzeichnisse zu gewähren. Jetzt gibt's zwei Möglichkeiten: 1. Die Dateien/Verzeichnisse gehören nobody:nogroup mit einer umask, daß jeder schreiben und lesen darf. Die Zugriffsrechte werden über die Samba-Benutzer geregelt. Also readlist und writelist in der smb.conf. Sicher ist allerdings was anderes, aber es funktioniert. 2. Die Unix-Paßwort/User-Dateien (passwd, group, shadow) müssen auf allen Maschinen gleich gehalten werden. Das schreit ja förmlich nach nis und genau das ist die Lösung des Problems. (oder das nächste Problem wenn man von nis keine Ahnung hat ) Keine schöne Nachricht für Dein Problem, aber vielleicht interessant für jemand anderen der Dieses Forum liest...
-
Das sieht eigentlich soweit ganz gut aus. Mit den PSK hat's funktioniert, oder? Dann bleiben noch die Zertifikate übrig. Ich such mal in meinem Leitz-Ordner die Anleitung mit der ich meine Zertifikate erstellt habe... Ah, ja. Da hab ich Sie: http://www.natecarlson.com/include/showpage.php?cat=linux&page=ipsec-x509#casetup Huh, da gibt's ne neuere Version wie die die ich damals hatte. Meine hatte ein paar kleine Fehler, die sollten jetzt aber wohl behoben sein. Da Du Sentinel hast brauchst Du ebootis nicht. Für Dich ist also nur der Teil mit der Zertifikaterstellung interessant. Probier's mal damit.,
-
Mahlzeit, ich gehe jetzt einfach mal der Annahme, daß die MSU-Zertfikate von von Sentinel erstellt wurden und die ipsec-Zertifikate mit openssl. Bei Remote-Hosts sollte nur ein Zertifikat drin stehen, eben der öffentliche Schlüssel der Linux-Kiste (der aus x509...) Bei den Certification Authorites sollten zwei Zertifikate drinstehen: das von Sentinel und das von openssl erstellte. Bei den 'my Keys' mußt Du die p12 importieren. Ich gehe mal der Annahme, daß das ipsectestpab importiert wurde. Dann würde auf Deinem zweiten Screenshot das Zertifikat nicht stimmen. Hier mußt Du das mit OpenSSL erstellte Zertifikat eintragen. Steht das alles so bei Dir (sinngemäß) drin? Wenn ja könnte es noch an den Schlüssel liegen.
-
Was mich stört ist folgende Fehlermeldung von Sentinel: SPD: Can not determine per-rule trusted CA root set for remote identity der_asn1_dn(any:0,[0..132]=C=DE, ST=Bayern L\=Aschaffenburg, O=MSU, OU=TS, CN=gwca, MAILTO=root@localhost.de). Using only globally trusted roots. Prüfe nochmals, daß bei der richtigen Policy (sofern Du mehrere hast) im Key-Managment die RootCA, der x509...-Schlüssel von FreeS/WAN und die p12-Datei importiert bzw. hinzugefügt sind. Desweiteren prüfe bei Deinen VPN-Einstellungen, daß Du auch das richtige Zertifikat und nicht das von Sentinel erstellte nimmst.
-
Dann fehlt noch die Certification Authority (CA). Das ist dir cacert.pem - die einfach unter selbigen Punkt ebenfalls importieren und das war's. Im Fehlerlog siehst Du, das Sentinel die CA des Zertifikates nicht kennt (und das mag er gar nicht).
-
Systembefehle unter Perl
dr.disk antwortete auf tschultze's Thema in Skript- und Webserverprogrammierung
Ooops. Hab's gerade erst gesehen: keine Kommandozeile sondern ein Fenster... Sei doch bitte so lieb und ignorier meine beiden Postings -
Systembefehle unter Perl
dr.disk antwortete auf tschultze's Thema in Skript- und Webserverprogrammierung
Meinst Du sowas hier? open PH, "myProg |"; print while <PH>; close PH; -
Da bin ich wieder! War lange nicht mehr im Forum... Also wenn ich das richtig sehe kennt Sentinel nicht alle Zertifikate. Hast Du im Sentintel neben der p12-Datei auch die RootCA und den Remote-Key, also den Schlüssel von FreeS/WAN installiert? Scheint nicht der Fall zu sein... Der öffentliche Schlüssel von FreeS/WAN liegt bei Dir in der x509cert.der (Remote Host) und die RootCA liegt in der cacert.pem (Certification Authorities). Anmerkung: die Diagnose prüft nur, ob auf der anderen Seite ein IKE-Server rangeht. Der eigentliche Verbindungsaufbau kommt einen Schritt später.
-
Das geht, ist aber ein riesengroßer Aufwand einzurichten - würde es an Deiner Stelle nicht tun, sondern getrennte Samba-Server aufstellen bzw. in einer Domain die Rechte entsprechend anpassen. Falls Du immer noch willst: bei swat unter Dokumentation findest Du die englische Ausgabe von Robert Ecksteins Samba Buch. Lese Dir dort mal Kapitel 4 durch. Dort wird eine Möglichkeit gezeigt IP-Abhängige Konfigurationen einzurichten. Du mußt also für jeden Client eine eigene Konfig erstellen und so die Clients in die jeweilige Domain 'schieben'. Mit symbolischen Links kann man sich die Tipp-Arbeit etwas erleichtern... Wie schon gesagt: ich würd's nicht tun. Nimm lieber Benutzergruppen und verteile denen entsprechende Rechte - läßt sich viel leichter administrieren.
-
Das müßte das cacert.pem als RootCA (Certification Author...) und x509... als Remote-Host. Als Format halt eins das Sentinel kennt, z.B. DER. Muß aber für heute weg - bis Morgen wieder.
-
Welche Zertifikate hast Du im Sentinel installiert? Woher weiß FreeS/WAN welches Zertifikat Sentinel hat? Ich selbst lasse mir auch die Sentinel Zertifikate von OpenSSL erstellen. Hast Du ja getan - wenn ich mich richtig dran erinnere - indem Du die p12-Datei importiert hast. Zusätzlich zu der p12 Datei muß man im Sentinel die rootCA und evtl. den Hostkey von FreeS/WAN einbinden. Sind diese beiden Zertifikate zusätzlich zur p12 drin?
-
Na dann trag doch ein nummer@fax irgendwas@ander.es Oder steh ich jetzt gerade völlig auf dem Schlauch?
-
Ooops! Sorry, hab ganz vergessen: auf obigem Link gibt's keine Software für NT4. Die Seite hab ich auch gefunden, jedoch konnte mir die nicht wirklich weiterhelfen.
-
Was hast Du denn in der canonical eingetragen? Die Einträge dort kann man ja auf einzelne Accounts/Domains beschränken - das müßte Dir doch reichen...