Zum Inhalt springen

MaverrickTM

Mitglieder
  • Gesamte Inhalte

    35
  • Benutzer seit

  • Letzter Besuch

Alle Inhalte von MaverrickTM

  1. UUID der partitionen wird sich ändern, das stimmt schon. Muss beachtete werden, wenn mit UUID's gearbeitet wird, danke für den Hinweis. Ebenso hab ich auf das Netzwerksubsystem vergessen. ifconfig eth0 <ipadresse> netmask <Subnetzmaske> up # konfiguriert ethernet adapter 0. route add default gw <IP default gateway> # erstellt die default route, fürs internet bzw. andere subnetze. Sollten beide Rechner im selben Subnetz sein, so brauchst du das default gateway nicht. Ebenso hat flashpixx mit der Aussage recht, dass die Installation auf die VM natürlich angepasst werden muss. Ich denke das sollte jedem, bei solch einem "Umzug" klar sein. @flashpixx Danke für die ergänzungen MfG Mav
  2. Hallo, also nochmal: Vergiss dd. Das ist für dieses Szenario das falsche Werkzeug. Bereitet dir mehr ärger als es hier nützen würde. Du fährst deinen Produktiven Server herrunter. Du startest diesen Server mit einem Live Linux. Danach mountest du die vorhandenen partitionen nach /mnt/root; /mnt/boot/; /mnt/home; etc.... je nachdem wieviele partitionen du hast. Jede Partion würd ich alleine Sichern. Beugt eventuellen problemen vor. Nachdem du sämtliche Partitionen mit tar gesichert hast, kannst du die Maschine wieder starten. Erstelle auf dem Wirts System eine neue VM und starte diese mit einem live Linux. Als nächstest partitionierst du dir die platte so, wie du sie brauchst. Nun wirds ein wenig kniffliger. Scp kannst du zum beispiel zum kopieren der Images nehmen. Dauert jedoch ein wenig. Erstelle unter /mnt/ einen Ordner den du root nennst. Danach mountest du deine neue root partition in diesen Ordner. Kopiere das Backup der Root partition in die neue Partition und entpacke sie. Dabei drauf achten das genug speicherplatz frei ist. Ansonsten musst du auf eine externe platte ausweichen. Nachdem die root partition steht, mountest du jede weitere neue partition an ihren entsprechenden Ort und entpackst das backup. Nachdem alle Backups zurück gespielt wurden, machst du folgendes. Du mountest deine benötigten mountpoints für die chroot umgebung: Kann sein das einige Syntaxfehler in meinen Befehlen sind. Habs schon ein welchen nicht mehr gemacht und gerade auch nicht probiert. mount -o bind /dev/ /mnt/root/dev mount -t proc proc /mnt/root/proc Ich glaube die beiden reichen, nicht wie anfangs angegeben. Ansonsten, wenn sys fehlt, wie /dev, nur mit /sys. Vergewissere dich, dann alle notwendigen partitionen gemountet wurden. Wenn das der Fall ist, dann baue die Chrootumgebung auf. chroot /mnt/root/ /bin/bash Nun solltest du mit dem neuen System arbeiten können. Tippe "grub" ein, der startet dir die Grub console. Da gibst du folgende befehle ein, um Grub in den MBR der ersten festplatte zu installieren. root (hd0,0) setup (hd0) quit Das sollte es gewesen sein. Chroot umgebung mit exit verlassen und alles sauber umounten. Danach sollte deine neue VM lauffähig sein. MfG Mav
  3. MaverrickTM

    IP Cam -.-

    Mahlzeit, Vielleicht ist eben der IE8 das Problem. Das Plugin wird wahrscheinlich Probleme mit neueren Browsern machen. Versuch es mal mit dem IE6. MfG Mav
  4. Hi, genau aus diesem grund muss das Backup unter einem live Linux durchgeführt werden. Dann sind nämlich diese Verzeichnisse leer. Die müssen vor dem starten des OS unbedingt angelegt werden ansonsten klappt das mounten des entsprechenden mountpionts nicht mehr. Daher sollten Sie mitgesichert werden, ansonsten muss man sie händisch neu anlegen. Das mitsichern erspart einiges an arbeit. MfG Mav
  5. Irgend ein Client wird den PTR eintrag zu xxx.xxx.255.214 abfragen. Jedoch tut er das nicht direkt bei dem dafür zuständigen NS sondern landet erst beim NS des Providers. Dieser hat nun das 24er Subnetz in mehrere aufgeteilt. Das heisst er erstellt mehrere Subdomains in der zone 255.xxx.xxx.-in-addr.arpa. In meinem Fall wäre die Subdomain meiner reverselookup-zone: 208/28 in der Zone 255.xxx.xxx.in-addr.arpa. Dort existieren dann CNAME einträge die abgefragt werden. Also 214.225.xxx.xxx.in-addr.arpa wäre einer dieser Einträge. Dieser CNAME record zeigt dann auf 214.208/28.255.xxx.xxx.in-addr.arpa. 214.208/28.255.xxx.xxx.in-addr.arpa. ist dann der PTR-Record der auf ns00.sld.tld liegt und die antwort geben kann. Ich hoffe ich konnte das ordentlich erklären. Ist nämlich nicht ganz einfach zu verstehen. [EDIT] Der Provider delegiert also nicht direkt das "Subnetz" an ns00.sld.tld weiter sondern er delegiert eine neue Subdomain (208/28) in der Zone (225.xxx.xxx.in-addr.arpa) an ns00.sld.tld und die eigentlichen PTR einträge des Providers werden mit CNAME einträge ausgetauscht die auf PTR Einträge der neuen Subdomain zeigen. [/EDIT] MfG Mav
  6. Hallo, eigentlich ist es ganz einfach. Mach von deiner Maschine ein backup. Tar reicht vollkommen dafür aus. Das Backup muss unter einem live-linux gezogen werden, um das System nicht im gestartetem Zustand zu sichern. Wäre keine so gute Idee. Dann erstellst du eine VM und startest sie mit einem live-linux. Spiele das Image auf die VM zurück und erstelle dir ne ordentliche chroot umgebung. Nicht vergessen /dev /proc und /sys mit in die chroot umgebung zu nehmen. Nachdem die chroot umgebung steht, gehst du in die grub console und installierst den GRUB in den mbr. Danach kannst du die VM starten und es sollte out-of-the-box laufen. Wenn nicht musst du eventuell ein paar Treiber nachinstallieren. Sollte eigentlich nicht notwendig sein. MfG Mav
  7. Sry wegen doppelpost. Kann oben nix editieren. Du hast recht. Nu sehe ich es :upps Nicht mein NS wird nach xxx.xxx.225.214 gefragt sondern der des Providers. :upps Der besitzt nen CNAME-Record der auf unseren Nameserver verweisst und dort auf den PTR-Record 214 der Zone 208/28.xxx.xxx.in-addr.arpa. zeigt. Dieser enthält dann die entsprechende Information. :upps Danke für die Erleuchtung! MfG Mav
  8. Danke für dein Post definiere mal bitte "fragen" in deinem context. Ich verstehe leider nicht wie genau du das meinst. MfG Mav
  9. Hi, du hattest geschrieben das du die Maschine mit einem fedora betreibst. Dein howto da ist für Debian deviate. Würde mich wundern wenn es sauber unter redhat deviaten funktioniert. Unter Fedora machst du sone Sachen in /etc/sysconfig/network-scripts/ Dort erstellst du eine file namens ifcfg-eth0:1 (beispielsweise) und fügst folgenden Content ein: DEVICE=eth0:1 HWADDR=<Mac-Adresse des parent devices, hier eth0> BOOTPROTO=static TYPE=Ethernet ONPARENT=yes # Wenns beim start mitgestartet werden soll IPADDR=<IP Adresse> NETMASK=<Subnetzmaske> MfG Mav
  10. Hallo zusammen, ich hab hier ein etwas anspruchsvolleres Problem zu bieten, bei dem ich derzeit nicht wirklich mehr weiter komme. Unser Provider wird demnächst (hoffentlich) die Reverselookup Zone, unseres IP-Netzes, an uns weiter delegieren. Diese Delegierung müssen wir ja irgendwie entgegen nehmen. Hierzu sagt ja das RFC2317 mehr als genug aus. Nur leider scheint es bei mir nicht zu funktionieren. Bind Version: 9.5.1 Die rekusive Abfrage von extern ist verboten. bei dem Subnetz handelt es sich um folgendes: xxx.xxx.225.208/28 Die gleiche Config, eines 24er Subnetzes, funktioniert wunderbar. Es muss also an dem Teilsubnetz bzw. der Umsetzung des RFC2317 liegen. Die Frage ist warum Bind keine passende Antwort gibt bzw. was ich vergessen / übersehen habe. Wenn ich Bind erlaube nach extern cached informationen zu verteilen, dann antwortet er mir mit der Liste der root-server. Ansonsten startet der Bind ordentlich und meldet das er sich zuständig für die Reverselookup Zone fühlt. Eventuell kann mir jemand den entscheidenen Tipp geben, denn ich scheine den Wald vor lauter Bäumen nicht mehr zu sehen :upps Entgegennahme der delegierung: zone "208/28.225.xxx.xxx.in-addr.arpa" IN { type master; file "/etc/bind/external/master.xxx.xxx.225"; allow-transfer { "dns_slaves_ext"; }; }; Zonefile: $TTL 1h ; Zone TTL @ IN SOA ns00.sld.tld. hostmaster.sld.tld. ( 2010060700 ; Serial 10m ; Refresh 5m ; Retry 30m ; Expire 30m ; Negative Caching TTL ) ; ; Nameserver der Domain (NS Records) ; @ IN NS ns00.sld.tld. @ IN NS ns01.sld.tld. ; ; Pointer Eintraege (PTR Records) ; ;208 IN PTR Netzname ;209 IN PTR <XXXXXX gateway> 210 IN PTR host.sld.tld. ;211 IN PTR ;212 IN PTR 213 IN PTR ns00.sld.tld. 214 IN PTR ns01.sld.tld. ;215 IN PTR ;216 IN PTR ;217 IN PTR ;218 IN PTR ;219 IN PTR ;220 IN PTR ;221 IN PTR ;222 IN PTR ;223 IN PTR Broadcast nslookup: Z:\>nslookup -querytype=ptr xxx.xxx.225.214 ns00.sld.tld. Server: UnKnown Address: xxx.xxx.225.213 *** 214.225.xxx.xxx.in-addr.arpa. wurde von UnKnown nicht gefunden: Query refused dig: [root@srv01 ~]# dig @ns00.sld.tld. ptr xxx.xxx.225.214 ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> @ns00.sld.tld. ptr xxx.xxx.225.214 ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 5446 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;xxx.xxx.225.214. IN PTR ;; Query time: 21 msec ;; SERVER: xxx.xxx.225.213#53(xxx.xxx.225.213) ;; WHEN: Mon Jun 7 15:57:07 2010 ;; MSG SIZE rcvd: 32 logfile ns00: Jun 7 15:44:22 ns00 named[10102]: client xxx.xxx.62.238#20409: view external: query (cache) '213.225.xxx.xxx.in-addr.arpa/PTR/IN' denied Jun 7 15:44:22 ns00 named[10102]: client xxx.xxx.62.238#36190: view external: query (cache) '214.225.xxx.xxx.in-addr.arpa/PTR/IN' denied Schonmal vielen Dank für die Hinweise / Tipps MfG Mav

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...