Grundsätzlich bietet 7zip (nachfolgend 7z) für sein Archivierungstool auf Windows- sowie UNIX-Systemen eine passable GUI an. Ganz im Gegensatz zum Synology NAS Betriebssystem DSM (DiskStation Manager). Dort lassen sich zwar über Rechtsklick im File Station Dateimanager Archive erstellen und extrahieren. Allerdings sind beide GUIs äußerst minimalistisch. Davon abgesehen scheitert bei mir das Öffnen von Archiven (über Rechtsklick -> Extrahieren -> Extrahieren…) mit Größen über 200GB – „Operation fehlgeschlagen“ ist die einzige Reaktion.
In einem aktuellen Webprojekt verwende ich MongoDB als Datenbank und die Node Erweiterung mongoose als Aufsatz. mongoose ist für alle Entwickler, die bisher pur auf der MongoDB arbeiten, definitiv einen Blick wert. Anfangs wurde lokal auf dem PC programmiert, mittlerweile beginnen wir den Umstieg auf einen Webhoster. Dabei ergab sich ein Problem, dass ich kurz erläutern möchte.
Die Mongoose Verbindung zur Datenbank erfolgt anhand eines Connection Strings, der bei einer Standardinstallation aller Komponenten sehr einfach aussehen kann:
var mongoose = require("mongoose");
mongoose.connect("mongodb://localhost/proorg-test");
Dieser String verwendet localhost als Server, den Standardport von MongoDB 27017, die Datenbank „proorg-test“ und keine Authentifizierung. Das reicht für den Anfang und funktioniert gut.
Nach dem Umstieg auf einen (shared) Webserver trifft man jedoch meistens eine andere MongoDB Installation an. Oftmals wird diese mit dem Parameter –auth eine Authentifizierung erfordern, einen anderen Port nutzen und vielleicht auch einen anderen Server verwenden. Neben den zusätzlichen Angaben für Server, Port und User muss man Mongoose jetzt auch befehlen, sich explizit an der „Admin Tabelle“ zu authentifizieren. Dies ist meisten die admin Tabelle, in der auch ein Admin Nutzer, dessen Daten im Connection String stehen, enthalten sein sollte.
var mongoose = require("mongoose");
mongoose.connect("mongodb://mongodb_admin:r0OtP4s$w0rd@localhost:20718/proganizer", {auth:{authdb:"admin"}});
Dieser String enthält jetzt den wichtigen Teil {auth:{authdb:“admin“}}, damit Mongoose sich mit dem mongodb_admin an der admin Tabelle authentifiziert.
An dieser Stelle auch big shoutouts an uberspace.de, der sympathische deutsche Webhoster mit „Preis-selber-wählen“ Prinzip und einem riesigen Arsenal an vorinstallierten, vorkonfigurierten und bestens dokumentierten Server- und Entwickler-Tools. Ein kleiner Einblick: „SSH. Perl. PHP. Python. Ruby. node.js. Erlang. Lua. Compiler. FastCGI. MySQL. CouchDB. MongoDB. Cronjobs. HTTPS. IMAP. SMTP. Webmail. qmail. vmailmgr. maildrop. SpamAssassin. ezmlm-idx. DSPAM. ~/service. runwhen. Eigene Logs. Backups. 10 GB Plattenplatz. Und das ist nur der Anfang.“
Mögliche Fehlermeldungen: Dieser Fehler würde auftreten, wenn trotz –auth Parameter bei MongoDB der Standard Connection String benutzt würde: assertion 16550 not authorized for query on proganizer.users ns:proganizer.users query:{ username: „SchurigH“ } Wenn man nur Benutzername und Passwort eingibt, ohne den auth Parameter von Mongoose einzustellen, also
, dann kommt: auth: couldn’t find user schurigh_mongoadmin@proganizer, proganizer.system.users Und selbst wenn man jetzt in proganizer.system.users einen neuen Admin User erstellt – das ginge mit db.addUser({user:“proganizer_admin“, pwd: „*****“, roles: [ „readWrite“, „dbAdmin“ ]}); – würde das nicht funktionieren. Ohne {auth:{authdb:“admin“}} geht es nicht.
Ich brauche die UNIX Shell auf meinem Windows System. Und es war erstaunlich einfach.
Cygwin heißt die sich praktisch von selbst installierende Software, die das komplette Linux Look & Feel mitbringt. Zusätzlich ermöglicht es der Installer auf einfachsten Wege hunderte Linux Pakete gleich mitzuinstallieren.
Nach der Installation liegt auf dem Desktop (wenn nicht während der Installation deaktiviert) eine Verknüpfung zum Cygwin Terminal, welcher einer Linux Umgebung nachempfunden ist. Von dort kann man wie auch im Linux Terminal Befehle absetzen, Programme starten, ausführen usw.
Es wird auch direkt eine Linux-ähnliche Ordnerstruktur erstellt und eingegebene Pfade entsprachend übersetzt, sodass auch das Dateisystem Linux-like anmutet:
MS-DOS style path detected: p:/Cygwin/home/Hannes/prog.sh
Preferred POSIX equivalent is: /home/Hannes/prog.sh
Die Ausgaben des Cygwin Terminals entsprechend nicht 1:1 den Ausgaben von Linux Distributionen, man sollte den dort entwickelten Code also nicht ohne Weiteres in Linuxumgebungen übernehmen. Aber für erste Tests (und die 2 Linux Bash Vorlesungen meines Studiums) reicht es.
Ich möchte heute 2 junge Blogs vorstellen, die meiner Ansicht nach über interessante Themen schreiben.
IT-Runde.de Christian betreibt seit über 2 Monaten den IT-Runde Webblog, in dem er zusammen mit einem aktiven Mitautor hauptsächlich über IT Themen schreibt. Von Anfang an bietet die IT-Runde mindestens 1 Post pro Tag, auch am Wochenende. In dem ansprechenden Design findet man sich schnell zurecht. Jeder Artikel hat ein Posticon, das schätze ich sehr. Bei den ersten Artikeln habe ich das auch noch versucht umzusetzen aber schon nach nicht mal einem Monat habe ich damit aufgehört. Dabei macht das einen unverwechselbaren Eindruck. Mir ist der Google Artikel ins Auge gefallen. Christian schreibt hier über die bekanntesten Applikationen von Google und spricht das Thema Datensammlung an. Erinnert mich an den ausführlichen „Wenn Google böse wird“ Artikel auf community-manager.info. Also schaut vorbei, es gibt immer etwas Neues zu lesen.
Disfunctions.de Dieser frische Webblog wird von den 2 leidenschaftlichen Webentwicklern Matthias und Lukas betrieben. Thematisch ist Disfunctions eher auf Linux Themen fixiert, vorrangig Ubuntu. Ebensoviele Tutorials kann man dort schon begutachten. Mir hat der Artikel Der Ubuntu Software Store – Zukunftsmusik? gefallen. Gut recherchiert und mit vielen Screenshots hinterlegt. Vor allem für Linux-Freunde hier also ein netter Blog zum mitlesen und mitreden, so dont be shy.
Schnell kann es passieren, wenn man sich mal eine kurze Zeit mit Ubuntu beschäftigt hat und es dann einen Monat brach lag: das Passwort ist weg und es war natürlich irgendwas schnell gewähltes, nirgends notiert und so. Shit happends; aber das lässt sich ändern.
Ubuntu wird ganz normal gestartet, und nach dem POST Screen drücken wir schnell [Esc] im richtigen Moment:
Danach kommt der GRUB, ein Bootloader bei unixbasierten Systemen; hier wählen wir das gewünschte System mit dem „(recovery mode)“ Anhang:
Nach dem typischen Linux wir-geben-eine-Menge-Scheiße-aus-und-beeindrucken-oder-verwirren-euch-damit-indirekt-Gedöns sehen wir ein Auswahlmenü im hübschen Blau-grau-Augenkrebs, wie man es von Windows auch schon kennt. Hier wählen wir den „root“ Eintrag und betreten damit die Shell. Mit folgenden Befehlen könnt ihr sowohl den Nutzernamen herausfinden als auch dessen Passwort neu setzen:
ls /home
ls /home gibt den (oder die) Benutzernamen zurück. An sich wird einfach nur der Inhalt des Home-Ordners angezeigt, was aber das selbe Resultat hat 😉
passwd [username]
Den gewünschten Usernamen eintragen. Als nächstes müsst ihr 2x das neue Passwort eingeben. Ihr werdet dabei keine Veränderung des Eingabefelds sehen, weder die Eingabe noch Sternchen oder Ähnliches. Einfach eintippen und 2x mit [Enter] bestätigen.
exit
Damit kehrt ihr zu dem Recovery Menü zurück und könnt dort z.B. mit „resume“ das Booten von Ubuntu einleiten. Ihr könnt natürlich auch
reboot
nutzen um das System komplett neu zu starten.
Da werden sich jetzt viele denken, „Ist das nicht eine extreme Sicherheitslücke??„. Ja natürlich, wenn mehrere an dem Computer sitzen, sollte man sich diese Recovery Konsole sichern. Es lässt sich sich der GRUB mit einem Passwort absichern. Am Anfang habt ihr die [Esc] taste gedrückt, um den GRUB zu betreten und dann ein System ausgewählt; hiernach lässt sich ein Passwort schalten. Zuerst starten wir die GRUB shell mit dem
grub
Befehl. Dort gebt ihr dann den
md5crypt
Nun gebt ihr ein Passwort ein und bekommt von diesem Passwort den MD5 Hash. Kopiert den String und kehrt zurück in die Shell („quit“ als Befehl). Öffnet dann die Datei /boot/grub/menu.lst mit eurem Lieblingseditor („sudo“ davor nicht vergessen). Dort fügt ihr nach jeder „initrd“ Zeile, die ihr sichern wollt, folgende Zeile ein:
password –md5 $1$w7Epf0$vX6rxpozznLAVxZGkcFcs
Also wenn wir z.B. den normalen und den Recovery Modus sperren wollen müsste das folgendermaßen aussehen:
Eigentlich war ich ja auf .rar Archive aus, da ich .zip nicht benutze, aber ich wollte leicht anfangen. Das erste Tool, was ich fand, war „fcrackzip„. Also los, zuerst das Programm mit apt-get install fcrackzip oder aptitude install fcrackzip (falls Aptitude vorhanden) installieren. Falls ihr kein root seid, müsst ihr natürlich sudo apt-get install fcrackzip oder sudo aptitude install fcrackzip verwenden. Nun kurz warten… Nachdem das erledigt ist, wechseln wir in den Ordner mit der geschützten .zip Datei. Nun können wir mit dem fcrackzip Befehl rumspielen.
Tipps: Parameter findet ihr hier. Bei einigen Internetseiten ist das Passwort die URL dieser Seite. Hier reicht es z.B. nur die Kleinbuchstaben und den „.“ bei Brute-Force zu nutzen, dann sollte es schneller gehen. Beispiel: fcrackzip -b -c a:. -l 5-13 -v [Datei]
Das ganze ist bei Passwörter ab 9 Zeichen natürlich recht sinnlos, vor allem wenn ausser Buchstaben auch noch Sonderzeichen ins Spiel kommen. Aber so war Brute Force schon immer. Ausser man baut sich einen PC mit Quad-SLI Grafikkartencrackingcluster, dann könnte das anders aussehen.
Hat jemand Ahnung in der Thematik dann bitte Comment oder Mail an kontakt@hannes-schurig.de.
Update: Ich habe das oben gezeigte Szenario (fcrackzip -b -c a:. -l 5-13 -v) über Nacht durchlaufen lassen. Mit einem AMD Athlon 64 X2 3800+ und 1280MB RAM (was beides ja praktisch Steinzeit ist) sind wir bei folgendem Ergebniss angelangt: Wir sind also beim Anfang von 9 Buchstaben… Als Erfolg seh ich das bei „a-z“ und „.“ als Charset irgendwie nicht.
Ich bin gerade dabei zu Testzwecken Ubuntu 8.10 in VMWare Workstation einzurichten. Es soll später bestimmte Aufgaben und Tests für meine Arbeit in Angriff nehmen, wenn alles gut läuft.
Eine der wichtigsten Entscheidungen während der VM Einrichtung in VMWare ist ja die Auswahl des „Network Types“, also wie die Virtuelle Maschine mit Netzwerken interagieren wird. Hier gibt es mehrere Auswahlmöglichkeiten, von denen uns jetzt aber nur die ersten Beiden interessieren sollen:
bridged networking und network address translation (NAT) sind unsere Kandidaten für ein funktionierendes Internet. Der Unterschied ist folgender: Bei bridged networking kann die VM eine eigene IP bekommen und als ein eigenständiger Client agieren. Bei NAT klinkt sich das Gastsystem beim Hostcomputer mit ein und nutzt seine Verbindung mit. Für den Fall ihr nutzt DHCP oder habt noch freie IPs für die manuelle Vergabe würde ich euch bridged networking empfehlen.
Nachdem die VM fertig eingestellt ist können wir die IP an das System vergeben.
Nun kann es, wie bei mir auch, passieren, dass das Netzwerk trotz richtiger Einstellungen streikt. Pings funktionieren nur auf das Hostsystem und alles Andere ist unerreichbar. Netzwerkdiagnosen wie z.B. Pings, Traceroutes und Weiteres könnt ihr bei Ubuntu unter System->Systemverwaltung->Netzwerkdiagnose durchführen.
2 Vorschläge: 1. Fahrt die VM herunter, klickt in der VMWare Übersicht eurer VM auf Network Adapter und aktiviert die Option „replicate physical network connection state“. Vor allem wenn ihr VMWare WS auf Laptops installiert, sollte dieses Häkchen gesetzt sein. 2. Geht zu den Netzwerkeinstellungen (System->Einstellungen->Network Configuration), löscht das bestehende Network Interface und erstellt ein neues. Klickt auf Einstellungen und achtet bei der manuellen Vergabe darauf, dass ihr nach jeder Eingabe (IP, Maske, Gateway und DNS) die [ENTER] Taste drückt. Ich hatte manchmal das Problem, dass nach dem Schließen und erneutem Öffnen nicht alle eingetragenen Einstellungen übernommen wurden. Überprüft durch erneutes Ansehen der Einstellungen, ob alles korrekt übernommen wurde.
