Administrator's Blog

Einträge für October 2009

Twitter Timeline

Monday, 12. October 2009

[Tipps und Tricks] Server sicher über ssh herunterfahren

Linux
Der heutige Tipp resultiert wieder einmal aus dem täglichen Arbeitsleben eines Administrators und soll euch dabei helfen, die Fehler die ich begangen habe, wenn möglich zu vermeiden. ;-)

Wer kennt das nicht, nach einem 10h Tag, vor 20 Remote Konsolen hängend, tippt man in nächtlicher Umneblung reboot auf einem vermeintlichen Testserver ein. Soweit so gut. 5 Minuten später klingelt dann das Telefon, am andere Ende der Geschäftsführer mit der Frage: "Wieso kann ich unseren Web-, Datenbank- [wichtigen Server hier eintragen] Server nicht erreichen? Hast du was dran gemacht?". In folge der fotgeschrittenen Stunde, denn richtige Admins fangen ja auch erst um 12 Uhr Mittags an zu arbeiten, sagt man natürlich ohne darüber nachzudenken: "Nein, aber ich schau gleich mal drauf, bin eh noch via ssh *geistesblitz* ähh, ich ruf gleich zurück". Hmm ssh, 20 Remote Konsolen offen, da war doch was. Hab ich jetzt den Testserver rebootet oder vielleicht doch den [wichtigen] Server?

Aber auch darüber hat sich bereits ein findiger Entwickler gedanken gemacht und zumindest für Debian artige Systeme ein Paket dafür bereit gestellt. :-)

Molly-Guard heißt das ganze und ist relativ einfach über
apt-get install molly-guard
zu installieren. Dieses kleine Paket macht im Endeffekt nichts anderes als unter /usr/sbin/ einen Symlink für die Programme halt,shutdown,reboot und poweroff anzulegen, welche auf das molly-guard Skript unter /usr/share/molly-guard/shutdown verweisen. Dieses wiederum erkennt anhand des aufgerufenen Programmnamens, bestimmer Umgebungsvariablen und abgefragter Parameter, ob man sich in einer SSH Session befindet, und fragt wenn das der Fall ist, nach dem Hostnamen des Servers den man herunter fahren möchte. Dies sieht dann in etwa so aus:

root@important_server:~# shutdown -n 60
W: molly-guard: SSH session detected!
Please type in hostname of the machine to shutdown: testserver
Good thing I asked; I won't shutdown important_server ...

Und wieder einmal eine kleine aber feine Erfindung, die das Admin-Leben erleichtert und vor allem Nerven spart.
Geschrieben von Maddin in Linux um 18:33 | Kommentare (4) | Trackbacks (0)

Saturday, 10. October 2009

[Tipps und Tricks] erweiterte geteilte Screen Sessions

Linux
Beim meinem letzten Post war ich ja auch auf das Thema geteilte Screen Session gekommen, in dem ich erklärt habe wie man via screen und einigen Optionen, wunderbar mit mehreren root-Nutzern zusammen in einer Screen Session arbeiten kann. Da Screen aber auch in der Lage ist, mit mehreren unterschiedlichen Nutzern eine geteilte Session zu machen, möchte ich euch dies anhand eines kleinen Beispiels erklären.

Mein Beispiel ist aus meinem Alltag gegriffen, in dem es immer mal wieder vorkommt, dass ein Kunde zum Beispiel eine Applikation installiert haben möchte, diese aber unter dem root Nutzer installiert werden muss. Dann empfiehlt sich einfach eine geteilte Screen Session zu machen, in der der normale Nutzer auf meinen root Screen einen lesenden Zugriff erhält und mich durch die Installation des Programmes leiten kann, ohne aber selbst mit meinen Rechten irgend etwas ausführen zu können. Ich kann mir auch vorstellen das dies zu Schulungszwecken sehr hilfreich sein kann, zum Beispiel um eine Konfiguration oder Installation erklären zu können.

Die erste Aktion, die ausgeführt werden muss, ist dem screen Programm, welches meist unter /usr/bin/screen liegt, setuid Rechte zu geben. Diese werden benötigt um im Multinutzer Betrieb von Screen Dateien zu öffnen, die sonst nur von root gelesen werden können.

Achtung Bitte beachtet aber, dass Programme die mit setuid Bit laufen und dem Nutzer root gehören, alles auf dem System machen können. D.h. sollte das Programm eine Schwachstelle haben (BufferOverflows etc. pp.), kann dadurch das System komprimitiert werden.

Deswegen solltet Ihr nach der Session dem Programm Screen das setuid Bit wieder entfernen.

Um das setuid Bit zu setzen, führt Ihr als root Nutzer folgenden Befehl aus:
chmod u+s /usr/bin/screen
Danach läuft Screen als setuid Programm. Um das setuid Bit nach der Screen Session wieder zu entfernen, führt Ihr wieder als root Nutzer folgenden Befehl aus:
chmod u-s /usr/bin/screen
Nach dem setzen der Rechte könnt Ihr, wie schon im letzten Artikle beschrieben, eine Screen Session mit eigenem Namen als root Nutzer aufrufen:
screen -S root_lese_session
Nachdem Ihr diese erstellt habt, müssen ein paar Optionen gesetzt werden, sodass ein normaler Nutzer lesenden Zugriff auf den Screen erhält. Dazu führt Ihr die folgenden Kommandos im Screen aus:
(strg+a) + :multiuser on
(strg+a) + :acladd nutzername
(strg+a) + :aclchg nutzername -rwx "#?"
(strg+a) + :aclchg nutzername +rx "0,detach"
Die Kommandos haben dabei folgende Bedeutung:

  • (strg+a) + :multiuser on schaltet den Multinutzer Betrieb ein

  • (strg+a) + :acladd nutzername fügt den Nutzer nutzername (also z.B. hans) der Zugriffsdatenbank von Screen hinzu, nachdem dieses Kommando ausgeführt wurde, hat der Nutzer alle Rechte in dieser Screen Session

  • (strg+a) + :aclchg nutzername -rwx "#?" entfernt die Leserechte (-r), die Schreibrechte (-w) und die Screenkommando Rechte (-x) für alle offenen Screens und Kommandos in dieser Session ("#?")

  • (strg+a) + :aclchg nutzername +rx "0,detach" fügt für den Nutzer auf Screen 0 die Lese- und Ausführrechte wieder hinzu, somit kann der Nutzer Screen 0 lesen und sich von diesem wieder abmelden ((strg+a)+(strg+d))

Nach dem die Optionen erfolgreich gesetzt wurden, kann sich der Nutzer mit dem folgendem Befehl anmelden:
screen -x root/root_lese_session
Und jetzt kann die freudige Session beginnen. Bei jedem Tastendruck leuchtet der Screen kurz weiß auf, sodass man als root Nutzer merkt wenn der normale Nutzer hätte etwas eingeben wollen. Das einzige was der normale Nutzer jetzt noch darf, ist sich vom Screen via (strg+a)+(strg+d) abzumelden.

Und schon kann man mit der Schulung, Installationen oder sonstigem beginnen. Wenn Ihr fertig mit eurem vorhaben seid, könnt Ihr die Berechtigungen des normalen Nutzers, ganz eichfach, via
(strg+a) + :acldel nutzername
wieder löschen.

Das Beispiel wurde auf einem Ubuntu 8.04 LTS erstellt. Bitte bedenkt das sich das unter Redhat/CentOS/MacOSX ein wenig anders darstellen kann (je nach Screen Version). Als Hilfe empfehlen sich immer die dazugehörigen man pages von screen. Und jetzt viel Spaß beim ausprobieren!

Geschrieben von Maddin in Linux um 09:49 | Kommentare (0) | Trackback (1)

Friday, 9. October 2009

Google Wave: Noch nicht auf meiner Wellenlänge

WWW
Ich habe heute endlich meinen Wave-Invite erhalten, nachdem mich ein netter Twitter-Follower bereits letzte Woche eingeladen hatte. Leider ist mir mit dieser Art von Account offenbarn nicht möglich, weiter Leute einzuladen. Dennoch habe ich nach einem Twitter-Aufruf einige Kontakte bekommen und konnte an ein paar "Waves" teilnehmen. Wer mich adden will, kann dies übrigens via robmin1337 [ät] googlewave.com tun, ich würde mich freuen. Google hat automatisch meinen Google-Usernamen at googlewave.com als Wave-Namen genommen. Hoffe, das lässt sich später noch ändern, z.B. auf eigene E-Mails oder so. ;-)

Also habe ich nun ja mal ein paar Unterhaltungen via Wave geführt und auch das Twitter-Plugin geladen (wie das geht steht hier). Und was soll ich sagen, so richtig begeistert bin ich nicht wirklich. Klar, man kann in Realtime chatten, sieht den Anderen live tippen, kann twittern und mit mehreren Leuten darin reden, aber so richtig einen Mehrwert konnte ich bisher nicht feststellen. Mit Plugins wie dem Twitterbot wird das Ganze zudem extrem unübersichtlich, der spammt die ganze Wave regelrecht zu. Generell leidet die Übersichtlichkeit sehr stark, wenn viele Leute in einer Wave zu Gange sind.

Natürlich ist das eine Beta und wird wohl erst richtig bewertbar, wenn alle Bekannten und Kollegen drin sind bzw. man einen eigenen Wave-Server aufsetzen kann. Das werde ich dann auf jeden Fall testen, bin vor Allem sehr darauf gespannt, was das an Rechenleistung brauchen wird. Da fallen ja massiv AJAX-Requests an, wenn ein paar Leute aktiv sind. Ich hoffe auch, dass externe Clients kommen, die das Ganze dann besser benutzbar machen (wie man es z.B. von Twitter dank der API kennt). Denn der normale Browser hat doch schon einige Einschränkungen. Es wäre beispielsweise schon schön, wenn man Dokumente oder Bilder einfach via Copy und Paste in eine Wave fallen lassen könnte..

Also warten wir mal ab, bis eine größere Masse Wave testen kann bzw. die finale Version herauskommt. Derzeit kann ich mir zumindest nur schwer ausmalen, wie das die Revolution für E-Mail, IM oder Chats sein soll..
Geschrieben von Rob in WWW um 11:07 | Kommentare (4) | Trackbacks (0)

Thursday, 8. October 2009

Twitter erneut mit Problemen

WWW
Seit ca. 2 Stunden ist Twitter mehr oder weniger down. Man kann zwar noch Tweets verfassen, sieht allerdings in der Timeline nur noch seine eigenen Tweets und nicht die der anderen User. Die @ Mentions scheinen noch zu funktionieren, zumindest habe ich eben eine erhalten ;-)

Es fing vor ein paar Stunden damit an, dass auf der Twitter-Website plötzlich die echten Zahlen für "Follower" und "Following" nur noch als Nullen dargestellt wurden, siehe Screenshot rechts. Datenbankproblem?

Kurze Zeit später ging dann gar nichts mehr bzw. jede Aktion auf twitter.com wurde mit einer tollen Fehlermeldung wie dieser hier quittiert:



Immerhin mal eine Abwechslung zum Fail-Whale. Aber schon ein wenig arm, dass Twitter seine Kapazitätsprobleme nicht in den Griff bekommt. Vor Allem angesichts der Tatsache, dass in den Betrieb ja Millionen Dollars an Risiko-Kapital fließen. Man darf gespannt sein, wie derartige Probleme zukünftige Investoren auffassen. Bis dahin warten wir halt einfach, bis Es wieder funktioniert. Noch ist Facebook zumindest nicht down, so wie es beim letzten großen Twitter-Ausfall wegen Lastproblemen der Fall war..

[UPDATE]

Twitter funktioniert nach einigen Stunden mit Problemen nun wieder, im Statusblog gibts folgenden Hinweis:

The problems this morning were caused by a bug triggered by an edge case in one of the core services that powers Twitter. We have already fixed this bug and are making additional optimizations based on what we learned.
Geschrieben von Rob in WWW um 18:53 | Kommentare (7) | Trackbacks (0)

Linux Professional Institute - LPIC

Linux
Da ich seit gestern LPIC-1 zertifiziert bin (Co-Autor Maddin war es bereits seit einer Weile..), möchte ich mal ein paar Worte dazu hier verlieren. Während die Microsoft-Jünger aus dutzenden Schulungen (aka Gehirnwäschen bzw. Werbeveranstaltungen) wählen können, sieht es für Linux eher mau aus. Zwar bieten Suse und RedHat eigene Zertifizierungen an, die Beschränken sich dann aber tatsächlich nur die jeweilige Distrubution und sind nicht allgemein anerkannt.

Dafür wurde LPI gegründet und wird u.A. von IBM subventioniert. Derzeit gibt es 3 Stufen, die man als Administrator (für Entwickler etc. werden keine Zertifizierungen angeboten) erreichen kann: LPIC-1, LPIC-2 und LPIC-3. Die ausgestellten Zertifkate sind weltweit anerkannt, so dass man als Bewerber um einen Posten als Linux-Admin mit einer oder mehreren LPIC-Stufen unter Umständen (!) bessere Karten hat. Garantie gibt es dafür freilich keine. Bei LPIC-1 geht es um Grundlagen der Administration eines Linux-Rechners wie z.B. die Shell, Bootloader und Installation. LPIC-2 geht dann schon etwas mehr ans Eingemachte wie Serverdienste, Kernel oder Hardware. In der 3 (die es wohl in Deutschland noch gar nicht so richtig gibt, soweit ich informiert bin..) dann um Sicherheit oder Virtualisierung.

Auch wenn das auf den ersten Blick für einen Admin, der seit Jahren mit Linux arbeitet, einfach aussieht: Man sollte die Prüfungen nicht unterschätzen. Ich kann jetzt nur für LPIC-1 sprechen, aber mir sind auch einige Sachen begegnet, wo ich Lücken hatte. Zum Beispiel beim Thema X11 oder Drucker musste ich mir Vieles noch aneignen, da sie in meiner täglichen Arbeit als Server-Admin nie begegnet sind. Auch sed oder awk hatte ich noch nie groß benutzt, schließlich gibt es ja PERL. Fragen zu diesen Themen sind aber nunmal Bestandteile bei der LPIC-1 Prüfung, so dass man diese lernen muss.

Zur Übung hat sicher der Simulator auf lpi-academy.de als nützliches Tool erwiesen. Aber Vorsicht, die Fragen sind derzeit nicht auf dem neuesten Stand der Prüfung. Als Buch kann ich auf jeden Fall die LPIC-Reihe von Heinlein empfehlen, ebenso die Materialien von der Linup Front GmbH. Natürlich sollte man idealerweise noch einen entsprechenden Kurs in einem Trainings-Center belegen, um das Wissen aufzufrischen. Bei mir fand der Kurs im Com-Center Dresden statt und war mit Dozenten wie Heiko Schlittermann (bekannt u.A. aus der Linux-User-Group Dresden) recht informativ und hilfreich für die Prüfung.

Ohne entsprechenden Kurs und Erfahrungen mit Linux wird man die Prüfung allerdings wohl kaum bestehen. Es wird, im Gegensatz zu den MS-Zertifizierungen, nicht das auswendig lernen von Fakten abgefragt, sondern die Erfahrungen aus der Praxis im Umgang mit Linux. Dabei spielt die Distribution übrigens keine Rolle, es wird z.B. beim Paket-Management auf alle "Welten" wie Debian, Fedora oder RedHat eingegangen, was auf jeden Fall gut ist. Ich habe bereits in der Schulung gemerkt, dass die Teilnehmer ohne Vorkenntnisse zum Thema Linux echte Probleme hatten, dem Stoff zu folgen. Einige meinten auch, sie werden die Prüfung gar nicht erst ablegen, sondern es bei dem Kurs belassen, da keine Aussicht auf Bestehen der Prüfung besteht. Das ist natürlich schade, aber zeigt deutlich, dass die Anforderungen nicht zu gering sind und man sich als Inhaber des Zertifikates ein wenig freuen darf! ;-)

Selbst ich als "alter Hase", der seit vielen Jahren mit Linux beruflich als auch privat arbeitet habe bei den LPIC-Schulungen noch einige neue Dinge und Kniffe kennengelernt, kann die Zertifizierung daher eigentlich durchaus empfehlen. Allerdings ist der "Spaß" natürlich nicht ganz billig. Derzeit fördert aber das Arbeitsamt für berufstätige Admins, die länger als 4 Jahre im Job sind, die LPIC-1 und LPIC-2 Schulungen. Weitere Informationen dazu gibts hier. Wenn man also, wie ich, die Vorgaben des Amts erfüllt und einen Arbeitgeber hat, der die Zeiten dafür freiräumt, sollte man sich die Chance auf mehrere Tausende Euro Förderung für die Schulung(en) nicht entgehen lassen..
Geschrieben von Rob in Linux um 13:05 | Kommentare (3) | Trackbacks (0)

Wednesday, 7. October 2009

[TESTBERICHT] Tethering beim iPhone (T-Mobile) via Bluetooth bzw. USB

Mac
Nachdem ich ja nun ein MacBook und ein iPhone besitze, macht diese Zusammenstellung natürlich auch auf Reisen bzw. außerhalb von zu Hause mit Internet viel mehr Sinn. Da Apple und T-Mobile ja mit dem iPhone OS 3.0 bzw. 3.1 das sogenannte "Tethering" (2 von 3 Leuten an der Hotline oder im T-Punkt haben dies übrigens noch nie gehört ..) als kaufbare Option in den neuen Tarifen eingeführt haben (und für Nutzer der alten Complete-Tarife zu deren Unmut deaktiviert!), habe ich dieses Feauture also zugebucht.

Viele meckern zwar über den Preis von 19 EUR im Monat, fairerweise muss ich allerdings sagen, dass ich den Preis eigentlich angemessen finde. Man bekommt dafür 3GB im wohl besten HSDPA-Netz Deutschlands und kann nahezu überall mit beinahe DSL-Speed surfen. Klar, die iPhone-Tarife sind so schon nicht besonders günstig, aber rein für diese 3GB sind 19 EUR schon erträglich..

Nach Bestellung an der Hotline, wo ich der planlosen Dame "Tethering" erstmal buchstabieren musste und einem Rückruf von selbiger wurde nach rund 10min. das Tethering direkt auf meinem iPhone freigeschalten. Es gab dann zu meiner Freude direkt die neuen Optionen, die ihr auf dem Screenshot rechts oben sehen könnt. Leider war es das aber auch gleich wieder mit der Freude vorbei. Die Bluetooth-Kopplung von MacBook und iPhone klappte - warum auch immer - erst nach zig Versuchen, läuft nun aber stabil. Die wohl bessere Variante ist allerdings der Connect via USB zum iPhone, da sonst der Akku beim Tethering minütlich schwindet. Die gleichzeitige und intensive Nutzung von UMTS/HSDPA und Bluetooth ist der Akku-Killer schlechthin, was man auch an der starken Erwärmung des iPhone (3GS) bemerkt.

In den Systemeinstellungen unter Netzwerk erscheinen dann 2 neue Dienste bzw. Anschlüsse, nämlich iPhone-USB und Bluetooth-PAN (siehe Screenshot), die dann die Verbindung via Tethering ermöglichen. Das funktioniert tatsächlich nach der ersten Einrichtung völlig problemlos und auch angenehm schnell. Die Bluetooth-Verbindung kann man auch direkt über die Statusleiste herstellen, damit sind es wirklich nur 2 Mausklicks und das mobile Surfen kann beginnen.

Hier ein noch paar Statistiken, ermittelt mit einem DSL-Speedtest.

Tethering via Bluetooth-Verbindung

Download-Geschwindigkeit: 356 kbit/s (45 kByte/s)
Upload-Geschwindigkeit: 124 kbit/s (16 kByte/s) - via Bluetooth-Tethering

Tethering via USB-Verbindung

Download-Geschwindigkeit: 1.188 kbit/s (149 kByte/s)
Upload-Geschwindigkeit: 202 kbit/s (25 kByte/s)

USB ist also in der Empfangsrichtung 3x schneller als Bluetooth und auch beim Versand der Daten noch deutlich vorn. Wenn möglich, sollte man daher (nicht nur wegen der Akku-Geschichte) das USB-Kabel benutzen..
Geschrieben von Rob in Mac um 18:36 | Kommentare (0) | Trackbacks (0)

Tuesday, 6. October 2009

[Tipps und Tricks] Remote Shell ein mal eins

Linux
Heute möchten wir euch 3 kleine, aber wirkungsvolle Tipps für das tägliche Arbeiten an entfernten Computern geben.
In Zeiten wo Administratoren für immer mehr, und vor Allem, immer weiter entferntere Systeme zuständig sind, haben sich im Unix bereich 2 Tools heraus kristallisiert, die für die tägliche Arbeit unabdingbar sind: screen und ssh.
  1. Shared SSH Sessions
    Des öfteren arbeitet man mit mehreren Remote Shells auf einem Server. Gerade wenn man am testen, konfigurieren oder debuggen auf einem Server ist, ist dies meist unabdingbar. Um dann auf dem Server durch die angehäuften Shells nicht zuviel Speicher zu nutzen (es kann ja auch mal sein, man arbeitet auf einer Appliance oder einem Router mit etwas weniger Speicher), bietet SSH die Möglichkeit sogenannte Master Verbindungen aufzubauen. Diese sind in der Lage, ihre Verbindung mit mehreren Slave Verbindungen zu teilen. Dazu wird auf dem lokalen System ein Master Socket angelegt, über den die Slave Verbindungen zugreifen können. Daraus resultieren 2 Vorteile:

    • auf dem entfernten System wird durch die "wiederverwendung" der schon bestehenden Verbindung, Speicher gespart
    • die Slave Verbindungen müssen sich am entfernten System nicht mehr authentifizieren (sehr hilfreich bei gescripteten Sachen)

    Wie legt man nun eine Master Verbindung an? Ganz einfach, nämlich so:
    ssh -M -o ControlPath=/Pfad/zum/Master/Socket user@host
    Dabei steht ide Option -M für Master und unter der Option -o ControlPath=/Pfad/zum/Master/Socket wird der Pfad zum Kontroll Socket für die Slave Verbindungen angegeben. Der Socket wird dabei unter den jeweiligen Benutzer mit Lese- und Schreibrechten angelegt (0600), ist also für andere Nutzer (ausser natürlich root) nicht les- und schreibbar. Die Slave Verbindungen startet man dann ganz einfach via
    ssh -S /Pfad/zum/Master/Socket user@host
  2. Screen lock
    Ist man einmal via SSH auf einem entferntem System angemeldet, ist nichts schlimmer als wenn diese Session durch Verbindungsfehler, sei es die schlechte Verbindung (z.B. nach China) oder das versehentlich geschlossene Fenster, wieder beendet werden. Für solche (und noch viele andere) Zwecke gibt es screen. Screen erstellt einen virtuellen Terminal, der losgelöst vom SSH Prozess auch dann weiter existiert, wenn dieser durch irgendwelche Gründe beendet wird. Hat man jetzt via screen einen Screen gestartet, kann die Verbindung wegbrechen wie sie möchte. Nach einer Wiederverbindung auf das System kann man sich ganz einfach via screen -r den Screen zurück holen und da weiter machen wo man aufgehört hat. Was aber wenn man sensible Daten auf seinem Screen verfolgt (z.B. Log Ausgaben) oder dieser beim Verlassen des Arbeitsplatzes vor fremden Zugriff geschützt werden soll? Auch dafür gibt es eine Lösung: In der laufenden Sceen Session aktiviert man mit der Tastenkombination (strg+A) + (strg+x) (unter Debian, bei anderen Systemen hilft ein Blick in die Hilfe, zu erreichen via (strg+a) + :help + enter) den Screen Lock. Danach ist der Screen nur noch über das Login zu erreichen. Je nach dem was für ein Lock Programm oder eine Version von Screen verwendet, kann man den Screen mit dem Nutzer Passwort oder einem selbst gewählten Passwort entsperren.

  3. Geteilte Screen Session
    Nun soll es ja auch vorkommen, dass mehr als ein Adminstrator für die Systempflege zuständig ist und man gemeinsam auf einem System an einer Konfiguration arbeitet oder einen Fehler debuged. Aber auch dafür gibt es mit Screen eine Lösung, die vor allem dann sehr toll ist, wenn man gemeinsam Dateien editieren möchte oder jemanden etwas erklären möchte. In diesem Post werde ich euch die geteilte Screen Session mit gleichen Nutzern erklären. Es gibt auch Möglichkeiten mit unterschiedlichen Nutzern eine geteilte Screen Session zu machen, z.B. root als ausführende Kraft und ein normaler Nutzer der nur einen Read-Only Zugriff auf den Screen hat. Nun aber zu ersterer Variante mit dem gleichen Nutzer. Als erstes startet man einen Screen mit einem angepassten Socketnamen via
    screen -S Socketname
    Um den Screen jetzt Multinutzer fähig zu machen, aktiviert man mit der Tastenkombination (strg+a) + :multiuser on diese Funktionalität. Mit dem zweiten Benutzer kann man jetzt via
    screen -x Socketname
    auf die Session zugreifen. Und simsalabim, schreibt der eine Nutzer sieht es der andere Nutzer sofort.
Ich hoffe diese Tipps erleichtern euch die tägliche Arbeit auf der Shell..
Geschrieben von Maddin in Linux um 12:33 | Kommentare (3) | Trackback (1)

Monday, 5. October 2009

Mit Time Machine unter Snow Leopard auf Netzlaufwerk sichern

Mac
Time Machine ist eine wirklich tolle Sache, um seinen Mac zu sichern und jederzeit Zugriff auf die Backups zu haben. Leider lässt sich damit von Haus aus nur auf eine zweite Platte, eine Time Capsule oder externes Gerät via USB oder Firewire sichern. Um aber auf einem entfernten Host, z.B. einer NAS via SMB-Freigabe, zu sichern, bedarf es einiger Kniffe. Diese will ich hier kurz anhand von Snow Leopard erklären.

Zuerst einmal muss man in der Konsole die Funktion aktivieren, auf "nicht unterstützten Volumes" zu sichern. Das geht mit diesem Befehl:
defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1
Anschließend kann man in Time-Machine auch Netzlaufwerke für die Sicherung auswählen. Nomalerweise wäre man jetzt direkt fertig, doch so leicht macht es Apple uns leider nicht. Versucht man jetzt nämlich, ein Backup zu starten, bricht es nach einer Weile mit Fehlern ab. Wir müssen also die Vorbereitungen von Hand treffen, bzw. uns von einem Script dabei helfen lassen. Mit dem Bash-Script MakeImage.sh (Download oder Sourcecode - habe ich in einem Forum gefunden) ist es kinderleicht. Man führt dazu einfach folgenden Befehl aus (vorher chmod +x MakeImage.sh):
./MakeImage.sh 200 /Volumes/shared_folder
Die maximale Größe des Backups wird in GByte angegeben, in dem Beispiel wird das Backup also maximal 200 GBytes groß werden, bevor alte Files gelöscht werden. Anschließend gibt man den Pfad zum Netzlaufwerk an, das sollte i.d.R. unter /Volumes eingehangen sein. Im Beispiel heisst die Feigabe "shared_folder".

Es wird nun zuerst lokal das 200 GB große Sparsebundle des Backups erzeugt (also der Platz reserviert). Anschließend wird es dann auf das Netzlaufwerk kopiert. Dabei wird der Name des Mac im Dateinamen verwendet (kann unter Systemeinstellungen->Freigaben->Gerätenamen anpassen). Man sollte also, falls man mehrere Macs sichern will, unbedingt auf verschiedene Gerätenamen achten. Der Output des Scriptes sollte dann in etwa so aussehen
Generating disk image NAME_EURES_MACs.sparsebundle with size 200GB ... done!
Generating property list file with uuid 3BE3748D-46DC-54F9-9F01-B82AA5A3B7DF ... done!
Copying NAME_EURES_MACs.sparsebundle to /Volumes/shared_folder ... done
Finished! Happy backups!
Damit haben wir den Großteil der Vorbereitungen getroffen, um dann mit Time Machine auf eine Netzlaufwerk zu sichern. In Time Machine selbst sollte nun auch via "Volumes auswählen" die Netzwerkfreigabe zu sehen sein. Nach Auswahl kann dann direkt das erste Backup auf den entfernten Host starten..
Geschrieben von Rob in Mac um 15:24 | Kommentare (19) | Trackbacks (4)

Saturday, 3. October 2009

Mac für die tägliche Arbeit, Linux auf dem Server

Mac
Nun habe ich es nach vielen Jahren Linux-Nutzung auf diversen Laptops und PC's tatsächlich getan: Ich bin zu Apple und damit zu OSX in Form von Snow Leopard gewechselt. Mein neues Arbeitsgerät für den täglichen Einsatz ist jetzt ein MacBook Pro 15,4" mit mattem Display, 320GB Festplatte (@7200UPM), Core 2 Duo @ 2,8GHz und 4 GB RAM. Im Büro kommt für mehr Übersicht noch das 24" Cinema Display samt einer externen Tastatur zum Einsatz.

Und, man glaubt es kaum, ich bin sowas von begeistert bisher: Alles funktionierte auf Anhieb, Snow Leopard macht einen extrem schnellen und stabilen Eindruck und samt Dev-Tools, GCC und einer Bash "unter der Haube" kann ich mit dem MacBook genauso angenehm arbeiten wie vorher unter Linux. Nahezu alle benötigten Tools sind frei verfügbar, da gibt es kaum Unterschiede zu Linux. Die Verarbeitung ist erstklassig, da kann keines meiner anderen Geräte mithalten.

Der Hauptgrund für den Wechsel war, dass auf einem als Arbeitsgerät eingesetzten Laptop oder auch PC hin und wieder Linux einfach nur genervt hat. Da ging plötzlich der Sound nicht mehr, da seitens der Distri (bei mir meist Debian/Ubuntu) auf einen anderen Soundserver umgestellt wurde, dann wurde plözlich das Touchpad nicht mehr erkannt oder der Mauszeiger stand plötzlich still, was einen X-Neustart nötig machte usw. - ich hätte dutzende solcher Geschichten auf Lager. ;-) Wenn man das Gerät aber in genau diesem Moment dringend braucht, um ein Problem zu beheben oder Etwas zu programmieren, will man sich nicht mit solchen banalen Sachen rumschlagen. Ich hoffe, mit dem Mac gehören diese Sachen der Vergangenheit an.

Natürlich arbeite ich auf Serverebene weiterhin ausschließlich mit Linux, da gibt es gar keine Frage. Auch mein Mini-Vaio läuft ja weiterhin mit Ubuntu, wenn auch mit einigen Einschränkungen (ich berichtete). Und auch auf dem Mac habe ich bereits ein Debian in einer VM via VirtualBox laufen, nur für den Fall der Fälle ..

So wird es in Zukunft im Admin-Blog wohl auch mal ein paar Postings zum Thema in der neuen Mac-Kategorie geben, schließlich ist dies auch ein sehr interessantes und weitreichendes Feld.
Geschrieben von Rob in Mac um 19:06 | Kommentare (0) | Trackbacks (0)

Administrator's Blog auf Twitter

WWW
Um noch schneller kurze News, Links und Facts rund um IT-Stuff verbreiten zu können, hat das admin-blog.com ab sofort auch einen eigenen Twitter-Account. Da Twitter konsequenterweise das Wort "admin" im Nutzernamen verbietet, ist das Blog nun als "admn_blog_com" vertreten. Aber das ist ja eigentlich kein Problem ;-)

Die neuesten Tweets werden auch im Blog in der neuen Spalte links dargestellt ..

Wir würden uns über zahlreiche Follower freuen: admn_blog_com auf Twitter

Geschrieben von Rob in WWW um 14:08 | Kommentare (0) | Trackbacks (0)
« vorherige Seite   (Seite 2 von 2, insgesamt 25 Einträge)

powered by

Suche

Kommentare

wolfgang zu Strato schaltet Server ab: Abwarten und Tee trinken bis morgen früh angesagt
06.03.12 22:49
strato hat vor mehrern tagen meinen server a [...]
Jeykon zu US-Proxy für YouTube und Co. bei Server4You - das war wohl nix
03.03.12 22:31
Weiss nicht obs noch aktuell ist. Aber es gi [...]
oberschlaui zu Alice nervt mit alternativer 404-Seite trotz Abschaltung
18.02.12 13:38
Ich habe einfach meinen Router auf Google DN [...]
Peter zu Schlecht zu Fuß: Das MacBook Pro und die Gummifüße
04.01.12 20:34
Hallo Freunde, Da ich genau das gleiche Pr [...]
PLu zu Acer EasyStore H341 als NAS für SMB und AFP mit Ubuntu Server
12.12.11 02:46
Hi, ich habe seit einem halben Jahr das Acer [...]
MeyJu zu US-Proxy für YouTube und Co. bei Server4You - das war wohl nix
07.12.11 10:03
Ich bin gestern auf Ultrasurf (http://ultras [...]
Patrick zu US-Proxy für YouTube und Co. bei Server4You - das war wohl nix
29.11.11 17:24
Versuchs mal mit Proxys von hidemyass.com - [...]
Rob zu US-Proxy für YouTube und Co. bei Server4You - das war wohl nix
24.11.11 09:13
Habe den Server nun wieder gekündigt. War wo [...]
Flo zu US-Proxy für YouTube und Co. bei Server4You - das war wohl nix
16.11.11 19:13
In der USA sind leider manchmal auch ein paa [...]
Rob zu US-Proxy für YouTube und Co. bei Server4You - das war wohl nix
16.11.11 17:27
Nette Sache, war der Speed in Ordnung? Der P [...]

Impressum

RobHost GmbH
Glashütter Str. 53
D-01309 Dresden
Mail schreiben

Subscribe


 



Archive

Kategorien



Alle Kategorien
tweetbackcheck