NIC-Verwaltung / AD-Einbindung

  • Moin,


    nachdem ich den HDD-standby halbwegs erfolgreich "operieren" konnte, tauchen aus dem off die nächsten Kuriositäten auf:


    1. Nachdem mein iphone mich heute früh mit Fehlermeldungen von Acronis B&R erfreut hat, wollte ich mir die Sache mal aus der Ferne angucken (Praxis ist heute zu). Also zuerst auf meinen PDC, um die Büchse von Hand über WOL zu starten ... ziemlich unproblematisch ;) , immerhin. Also WOL auf xxx.xxx.xxx.91 ("erster ethernet-adapter" der Büchse, der auch als benutzter NIC im NAS eingetragen ist, da ich auf den 2. NIC xxx.xxx.xxx.92 vor Lachen kein Standardgateway eingetragen bekomme ... das ignoriert die Büchse einfach :cursing: ). Kaffee getrunken und die Anwesenheit mal mit net sessions geprüft. Ergebnis: in der Sitzung wird lediglich der 2. Adapter angezeigt??? Ich denke, der ist nicht aktiv? Ping geht auf beide NIC's ...


    Hat jemand eine Idee, wie in Taiwan IP's verwaltet werden? Benötige ich, um die Eigenschaften des TCP-Stacks festzuschreiben, eine Tastatur mit chinesischem Layout? Und wenn ja, wo bekomme ich die her??


    2. Ich habe gestern Abend die ersten Sicherungs-Task's in Acronis Backup&Recovery 11 (Windowsserver) definiert. Alles inkrementelle Sicherungen, das jeweils erste Voll-Backup habe ich mit der Hand angeschoben - lief völlig easy. Dann habe ich das NAS heruntergefahren. Das automatische wakeup war auf 04:45 eingestellt, der shut down auf 07:00. Das hat die Büchse ausweislich des log's auch gemacht. Der erste Job sollte 05:00 Uhr beginnen. ABER: Acronis konnte nicht auf das NAS schreiben und gibt im log aus:


    Einstellen der Anmeldedaten für den Backup-Speicherort fehlgeschlagen.
    Zusätzliche Info:
    --------------------
    Fehlercode: 36
    Module: 64
    LineInfo: 97675718d2b52ce2
    Felder: path : hapraxis.local\yyyyy
    Nachricht: Einstellen der Anmeldedaten für den Backup-Speicherort fehlgeschlagen.
    --------------------
    Fehlercode: 20
    Module: 4
    LineInfo: f35f747b3b21faee
    Felder: function : WNetAddConnection3W, filename : \\qnap-praxis\public
    Nachricht: Zugriff auf die Datei verweigert.
    --------------------
    Fehlercode: 65520
    Module: 0
    LineInfo: bd28fdbd64edb8bc
    Felder: code : 2147942464
    Nachricht: Der angegebene Netzwerkname ist nicht mehr verfügbar
    --------------------


    In den Acronis-Jobs sind die Anmeldedaten für mein Domänen-Konto korrekt hinterlegt ... Und die Büchse lässt Acronis jetzt auch nicht mehr rein, wenn ich die Jobs jetzt mit Hand anstarten will. In den Benutzereinstellung des NAS ist alles unverändert.


    Aus Gewohnheit habe ich in den Einstellungen der Büchse den Haken für die Anmeldung bei Domäne\Nutzerkonto gesetzt. So lässt sie mich aber nicht rein, ich benötige die Syntax Domäne.topleveldomain\Nutzerkonto, also bei mir hapraxis.local\yyyyyy. WinNS läuft nicht. Dies habe ich in Acronis gestern für die Jobs auch so eingetragen, und damit liefen auch die Sicherungen. Die Sicherungspfade sind nicht als Netzlaufwerke verbunden (um die Platten nicht am spindown zu hindern), die Sicherheitsstufe im NAS ist momentan noch auf niedrig gestellt.


    Warum lässt die Büchse nach kurzer Nachtruhe Acronis nicht mehr rein???


    Ich halte das alles für ein wenig bizarr - schick für Cineasten und rapidshare-Dauernutzer, in einer Windowsserver-Umgebung macht das Teil auf mich jetzt nicht gerade einen zuverlässigen Eindruck???? Solche Faxen mit der AD-Anbindung habe ich weder bei Synology noch, und das will was heissen, bei Plastik-Buffalo erlebt ...


    Eventuell kann mich jemand auf den Pfad der Linux-Tugend führen?


    Danke und LG, Thomas


    EDIT:


    update:


    Nachdem ich auch manuell die Jobs aus Acronis nicht mehr starten konnte ( :cursing: ) habe ich mir den Nachmittag damit vertrieben, das NAS noch einmal mit einer Windows-Domäne vertraut zu machen. Das Resultat ist ernüchternd: selbst nach einem Rausschmiss des Taiwanblechs aus dem AD und Neueintritt in die Domäne habe ich nun nicht einmal mehr über den Explorer Zugriff auf das Teil, niedriger kann man die Zugriffsrechte auch nicht mehr setzen, es sei denn, man stellt das Ding mit offenen Plattentrays in eine Bushaltestelle.


    Ich bin mir nicht sicher, ob die Chinesen den Samba-Server nicht geschrieben haben, als der Reiswein gerade billig war??? Diesen Schrott kann man doch nicht zum professionellen Einsatz verticken ... Da gibt es ja offensichtlich erhebliche Probleme mit Windows 2008?


    Fazit: QNAP ist vermutlich nur für MP3 / MP4-Sammler eine Lösung ... ich geh wohl reumütig zurück zu Synology-Plastikgehäusen.


    Mal gucken, was der support sagt, aber das kann man echt nicht anbieten.


    LG, Thomas

    Einmal editiert, zuletzt von X5_492_Neo () aus folgendem Grund: Doppelte Beiträge vermeiden, siehe Forenregeln!

  • Hi,


    zu Deinem WOL / STDGATEWAY Problem, wie ist Deine Netzwerkeinstellung ? Nutzt Du ein BONDING ? Also Port Trunking ?
    Dann hast Du im System ein "Bonding" Device "bond0" und das hat dann auch ein STD Gateway..


    Tomas

  • Hallöle!


    Standard-Gateway ist einmalig! Entweder es ist der Standard oder eben nicht.
    Da Beide NICs offenbar im gleichen Netzwerk sind, ist auch das Standard-Gateway für beide NICs gleich!


    Unabhängig davon: Wenn Du unterschiedliche Netze benutzen würdest, würde der SG-Eintrag für die zweite NIC augenscheinlich auch nicht übernommen werden,
    d.h. er taucht nicht mehr auf, wenn Du die Konfiguration wieder aufrufst, ist aber im System gespeichert!
    Das System entscheidet sich grundsätzlich das SG der 1. NIC zu nutzen. Erst wenn dieses nicht mehr vorhanden sein sollte, zaubert das NAS das zweite Gateway aus dem Hut und nutzt es. Mit den Standard-Gateways ist es halt wie bei Highlander, "es kann nur einen geben" ;)


    Zur AD-Anbindung kann ich nur sagen, dass sie wahrlich etwas tricky ist (zumindest die Aufnahme ins AD).
    Leichter ist es ein ISCSI-Target zu definieren und dies direkt vom Server aus zu verwalten....


    Grüße
    Jody

  • Hallo zurück!


    Lassen wir mal den China-Standard im TCP beiseite, das Ding hängt ja zumindest im LAN. Einen Trunk habe ich der Büchse übrigens nicht zugemutet ... Was passiert, wenn der Standard-NIC wegstirbt mit dem Gate? Kriegt die Büchse dann Internet-Verbot?


    Aber der AD-Dienst ist die hohe Schule ..., sowas schrottiges habe ich wirklich noch nie gesehen, das ist nicht tricky, das ist extrem dirty!


    Das macht auch keinen Sinn, da weiter zu spielen, wenn man dann nur ein geht, geht nicht hin, geht .... hinbekommt.


    Einfach nur: 5, setzen! iSCSI ist nur eine Krücke, wenn mit einer Einbindung in das AD Werbung gemacht wird.


    LG, Thomas

  • Das ist kein China Standard, das ist Standard.
    Warum heisst ein Standard Gateway denn so.... könnte es sein dass er Standard ist, wieviele Standards sollen es denn sein?


    Wenn Du nachschaust, dann lässt sich einstellen, ob der std gw vom ersten oder 2ten Nic verwendet wird.


    Und iSCSI ist keine Krücke

  • Hi,


    das Thema ist zwar nicht der Hauptkritikpunkt, aber beschäftige Dich mal mit dem Thema Sicherungsgateway. Natürlich kannst Du das Gate pro NIC konfigurieren, und solange ich nicht weiss, nach welchem Lotto-Prinzip die NIC im NAS angesprochen werden und wie die Stack-Konfiguration umgesetzt wird (wie gesagt, es ist im gui nur eine Schnittstelle "aktiviert", ein Trunk ist nicht gebildet, der Datenverkehr wird über beide connectoren abgewickelt) ... hier gibt es offensichtlich Beschreibungsdefizite. Sei es drum, aber ich sehe gern, was meine Maschinen glauben, machen zu dürfen.


    Aber der burner: ich habe gestern vor Wut vergessen, die Sicherungstasks in Acronis anzuhalten und habe auch die automatische An-/Abschaltroutine des NAS so gelassen, wie ich sie vorgestern eingestellt habe. Heute früh eine sehr überschaubare Liste technischer Mails auf dem eierphone, erstaunlicherweise keine von Acronis?


    Remote auf den Server, den Acronisclient befragt: Jobs sind durchgelaufen. Das NAS geweckt, Kontrolle im Explorer: die freigegebenen Ordner - alle da und lieb anzusprechen. :cursing:


    Bevor jemand fragt: ja, ich habe das NAS gestern mehrfach neu gestartet, insbesondere nach der Neuanbindung an das AD. Da ging nichts. Das ist der absolute Brüller ... gibt es da einen Haken im GUI "Regeln des Arbeitszeitgesetzes" missachten?


    Und ja, iSCSI kann eine Krücke sein, insbesondere bezüglich Prozessorlast und Ansprachelatenz. Für meine Zwecke vermutlich vernachlässigbar, da das Gerät ausserhalb des regulären Betriebs angesprochen wird, aber wenn Du siehst, was ein Quadcore-Xeon neuerer Bauart von Acronis zu rechnen bekommt, kann das durchaus auch ein Argument dagegen sein. Für die Anbindung an einen reinen Storage-Server ist das dann eher belanglos, bei mir läuft das eben auch auf dem PDC.


    Es bleibt dabei nach 5 Tagen QNAP: das einzig Zuverlässige scheint die Unzuverlässigkeit des Gerätes zu sein, sorry. Mal gucken, was für den Sonntag geplant ist.


    LG, Thomas


    EDIT:


    Und update ...:


    NAS gestern angelassen. Und ja: NAS ist angeblieben. Und nein: Trotz Anweisung hat sich die Büchse heute früh nicht automatisch abgeschalten ...


    Alles nicht das Problem: Und nein! Sonntags läßt die Blechkiste Acronis auch nicht schreiben. Unterschied zum Freitag: die shares sind innerhalb des AD über den Explorer mit genau jenem Konto ansprechbar, mit dem auch Acronis versucht, auf das QNAP zu kommen.


    Fazit:


    Donnerstag: AD Zugriff
    Freitag: Kein AD Zugriff - Neuanbindung an die Domäne / auch da kein Zugriff
    Samstag: AD Zugriff ohne weitere Korrekturen zum Freitag
    Sonntag: 1/4 AD-Zugriff


    Alter Schwede! Ich habe jetzt seit 5 Jahren eine Windows-Domäne in der Praxis (3 Jahre 2003, 2 Jahre 2008). In dieser Zeit ist das Qnap das dritte NAS, was ich in's Netz gehangen habe (Buffalo 1 Bay, Synology 2 Bay, jetzt das TS439). Solche Faxen habe ich nicht einmal mit dem Buffalo erlebt - und die Teile sind berühmt für ihre miserable AD-Kompatibilität ...


    Hat nicht jemand eine how to, wie man der Truhe eine vernünftiges Betriebssystem überbügelt ;) [ich nehme dann auch eine Windows Vista home edition ... :tongue: ]


    LG, Thomas

    Einmal editiert, zuletzt von X5_492_Neo () aus folgendem Grund: Doppelte Beiträge vermeiden, siehe Forenregeln!

  • Hi,


    nichts ist unmöglich, und meist sitzt das Problem vor dem Monitor ... ;-).


    Aber ich verbürge mich dafür, das ich kein umtägig funktionierendes AD einsetze (das ist IMHO auch Option und muss bei Microsoft zugezahlt werden :P ).


    Worin ist Euer NAS eingebunden?? Windows 2003? Windows 2008? Windows 2008R2? Linux-AD? 20 Lagen Mullbinden :tongue: (kleiner Spass). Als Domänen-Client oder als iSCSI-Storage?


    Ich fürchte nach wie vor, das die Umsetzung von SMB im laufenden SAMBA nicht wirklich gut funktioniert, lasse mich aber gerne eines Besseren belehren.


    LG, Thomas

  • Hi nochmal, Christian,


    kannst Du eventuell mal bei Gelegenheit checken, ob Du gleichzeitig mit ein und demselben AD-Konto von zwei verschiedenen PC auf das NAS rauf kommst?


    Folgendes Phänomen (ich bin gerade noch mal in die Praxis gefahren): NAS mit Hand gestartet, erster Zugriff von einem Arbeitsplatz-PC mit meinem Konto via Explorer auf das Gerät: kein Problem. Remote auf meinen DC (ebenfalls mit meinem Konto), Zugriff schon via Explorer gesperrt. Eingesetzt wird allerdings 2008"R1" im SBS.


    Gibt es da eine bekannte quantitative Beschränkung der gleichzeitigen Zugriffe via SMB, sagen wir mal so grob geschätzt mehr als einer, im eingesetzten SAMBA??


    LG, Thomas



    edit: ich kann mich dunkel daran erinnern, das ich letzte Woche das Problem auch hatte, aber in der anderen Richtung (Zugriff vom DC oB, Zugriff vom Client nicht möglich). Eventuell merkt sich die Büchse die Anmeldung und gibt sie nicht wieder frei?


    EDIT:


    update: die Macht ist mit mir und mit meinen Ahnen! Jetzt kann ich auf einmal sowohl vom Server als auch vom client zeitgleich mit dem selben Konto auf die public folder zugreifen ... ich habe nichts gemacht. Wirklich!! Bittebitte glaubt mir, liebe Linux-Onkels :D


    Das Teil lebt ... ist träge und denkfaul, muss ich es jetzt trotzdem füttern? Oder übergebe ich es gleich dem Förster?? Mittlerweile finde ich das Ding richtig spassig, eventuell sehen wir hier den Beginn wirklicher künstlicher Intelligenz (kennt die Uhrzeit, kann Wochentage auseinander halten und reagiert je nach emotionaler Grundeinstellung ....


    LG, Thomas

    Einmal editiert, zuletzt von X5_492_Neo () aus folgendem Grund: Doppelte Beiträge vermeiden, siehe Forenregeln!

  • Nö, wir lieben uns!


    Erst recht, nachdem ich einen iSCSI-connect hergestellt habe und das Teil jegliche Größenvorgaben für das Laufwerk ignoriert (nur gut, das mein Serverchen nur 2 TB auf einem Laufwerk verwalten mag). Dafür biete die iSCSI-Partition jetzt einen Gesamtspeicherplatz von knapp 16 TB an ... Nicht schlecht, für die 4x1TB, die da drinnen stecken, gelle?


    Jetzt versuche ich, bei den augenblicklichen HDD-Preisen den so gewonnenen Speicherplatz als QNAP-Cloud online zu verticken ...


    Die spinnen, die Chinesen. Ich denke mal, ich bin der Ursache der wackeligen AD-Authentifizierung auf der Spur ... irgendwas stimmt IMHO mit der LAN-Authentifizierungsebene nicht. Kann es sein, das Linux nur ein verkleidetes Win95 ist? :roll:


    Doktor IT wird es in der nächsten Folge lösen. Bis dahin: QNAP-Werbung! :shock:


    Kläre ich noch, leider muss ich heute noch richtig arbeiten.


    LG, Thomas


    edit:


    jetzt schon weniger überraschend - Acronis durfte heute wieder sichern (nicht via iSCSI, sondern auf das public share!). YES!!! Jetzt bin ich gespannt, was das Dingens macht, wenn es merkt, das die Woche sieben Tage hat und die umtägige Do-Sa-Mo-Mi-frequenz nicht fortgeführt werden kann ...) :tongue:


    Aber es ist definitiv ein wackeliges Authentifizierungsproblem - ich habe das gestern mal auf dem Server beobachtet, während die RDP-session dauerhaft lief: Mal durfte ich, mal durfte ich nicht ... Erinnert fast ein wenig an zu Hause! Ist es möglich das es nicht das, sondern die NAS heisst? ;)


    und edit:


    Wen stört es noch? Natürlich heute kein Zugriff von Acronis auf die shared folders des taiwanesischen Blechkistchens ... Ist ja Dienstag. Offenbar haben die autonomen Chinesen ein neues firmware-build in den Multi-Media-Markt geworfen ... das fix-log liesst sich jetzt irgendwie nicht nach dem neuem SAMBA, der ja wohl schon ein Weilchen final released ist.


    It's your last chance, my yellow friend! Wenn es dann nicht geht, bekommen Dich die Kindergartenkids um mehrere Animationsfilme parallel abstreamen zu können, ich fürchte, hier liegt der Einsatzschwerpunkt der QNAP's ... Schicke Multimediakistchen sind die Teile ja alle mal, da kann man auch mal das schöne alte Liedchen: "Tanze Samba mit mir, Samba, Samba die ganze Nacht ..." laufen lassen.


    Sämtliche von mir vertretbare Änderungen am NTLM eines x64-W7 haben bezüglich der AD-Authentifizierung keine Auswirkungen, den Server will ich da nicht wirklich anfassen, ist ja letztlich aber auch nichts weiter als ein grosses W7, gelle ...?


    In einer Windows-Domänen-Umgebung haben die Teile offenbar nichts verloren - da heisst es dann wohl doch storage server 2008. Teure Lösung - aber auf entsprechender Hardeware funktionell und zuverlässig. Wer billig kauft, kauft ... teuer! Naja, mal schauen, was das bugfix bringt, aber wie gesagt ...

    Einmal editiert, zuletzt von Docba ()

  • Zitat von "Docba"

    Ist es möglich das es nicht das, sondern die NAS heisst? ;)


    LOL
    unbedingt! hin & wieder zickt mein kleines NAS auch, dann dreh ich den Strom ab und es merkt wer das sagen hat :thumb:


    Grüße
    Jody

  • So,
    jetzt das schlussendliche update. Das NAS hängt jetzt relativ stabil via smb in der AD. Heilung (auch nach Vorschlag des supportes): austreten ... eintreten ... austreten etc. pp. Habe ich insegesamt wohl 5 oder 6mal gemacht ... Naja.
    Dafür müllt mir das QNAP jetzt 5minütlich das System-Ereignislog des DC mit Fehlermeldungen aus DCOM zu ... ist nicht abzustellen, vermutlich ist im verwendeten SAMBA DCOM nicht angebunden?


    Egal: ich nutze das Teil jetzt nicht mehr in der AD (schade), sondern ausschließlich als Storage für meine Zwischensicherungen via iSCSI - nachdem ich dafür ein separates VLAN aufgemacht habe. Damit habe ich jetzt im wesentlichen die Funktionalität einer USB - Festplatte am Server, die dafür noch mit der Unsicherheit eines Software-RAID glänzt ... Aber für die Sicherheit gibt es Utrium.


    Zum momentanen Zeitpunkt kann ich ergo nicht wirklich empfehlen, die QNAP's per smb in eine Windowsdomäne einzubinden - zu unzuverlässig und nicht wirklich tief integriert (DCOM).


    Aber schickes Gehäuse hat das Teil allemal, also werde ich mich wohl nicht davon trennen ;)


    LG, Thomas


    p.s.: hat eigentlich schon mal jemand versucht, INTREXX auf den Büchsen zu installieren??

  • So, the last update:


    Das Qnap darf jetzt auf den Kinderspielplatz - da ist es gut aufgehoben. Ich werde mal schauen, ob ich zu Hause einen Platz für das Kistchen finde.


    Um in einer Windows-Domäne tatsächlich gute Arbeit zu tun, ist die SMB-Anbindung doch zu wackelig.


    Abhilfe: ich habe mir einen AccuVault RDX von Tandberg zugelegt. Zwar nicht billig, aber mit richtigem Betriebssystem (WSS2008). Und die Idee mit der RDX-Kassette im Gerät macht fast die LTO's verzichtbar.


    LG und Bye, Thomas