Hilfe! Ich hab immer noch keinen freien Speicherplatz! (Open File Handle)

Dein Letzter Beitrag über Inodes hat mir nicht geholfen. Ich habe einige Dateien gelöscht und angeblich ist mein Filesystem immer noch voll.

Auch das kann leider passieren. Und zwar dann, wenn ein Prozess eine gelöschte Datei noch im Zugriff hat.

Ich versuche das ganze mal hier zu verdeutlichen.

Wie wir sehen, habe ich derzeit 1.5GB in Benutzung. Jetzt löschen wir einmal die Datei und sehen was passiert.

Mist, ich habe ja immernoch 1.5GB Speicher belegt… Mal gucken wo das herkommen kann…

Mit “du” (disk usage) können wir uns anzeigen lassen, welche Dateien wie viel Platz auf der Festplatte benötigen.

-s fasst dabei alle Verzeichnisse zusammen

-h wie bereits von df bekannt, macht es die Ausgabe für uns einfacher zu lesen.

Offensichtlich haben wir auf dem Filesystem nur 16K belegt… Trotzdem behauptet “df” wir hätten 1,5GB belegt. Ist “df” etwa verbuggt und zeigt einfach nur Müll an?

Nein, beide Tools zeigen genau das an, was die Entwickler sich vorgestellt haben. Beide Tools haben “recht”.

“df” Zeigt die Speicherbelegung im Filesystem an. Dort sind noch immer tatsächlich 1.5GB belegt.

“du” Zeigt die Speicherbelegung auf der Festplatte an. Hier sind die 1.5GB schon freigegeben worden.

Wie kann ich die “freien” 1,5GB denn nun auch wieder nutzen?

Hier kommt die unterschiedliche Handhabung von geöffneten Dateien zwischen Linux (und vermutlich auch Unix, das kann ich aber nicht beurteilen) und Windows zum vorschein.

Hätten wir unter Windows versucht die Datei zu löschen, während ein anderes Programm auf diese Datei zugreift, hätten wir folgende Fehlermeldung erhalten:

geht-nicht

Unter Linux können wir die Datei trotzdem Löschen. Hierbei wird vorerst nicht die Komplette Datei gelöscht sondern erst der Inode. Neue Prozesse können also NICHT mehr auf diese Datei zugreifen. Um ein unvorhersehbares verhalten der Programme welche die Datei allerdings geöffnet haben zu vermeiden, wird es diesen Programmen weiterhin erlaubt die Datei zu nutzen.

Woher weiß ich denn, ob ich solche noch geöffneten Dateien habe?

Mit “lsof” (list open files) können wir uns alle derzeit geöffneten Dateien anzeigen lassen. Das kann aber unter Umständen recht viel werden (Auf meinem System derzeit gut 33.000 Dateien)

Also filtern wir mit “grep” nach dem Text “deleted” denn so stellt lsof Dateien dar, welche bereits gelöscht, aber noch immer geöffnet sind.

Haben wir ein eigenes FIlesystem auf dem wir nach offenen Dateien suchen wollen, können wir “lsof” dies auch als Parameter mitgeben.

Wenn wir nun den Prozess (in diesem Fall ein “less”) Beenden, wird der von uns vermisste Speicherplatz auch direkt wieder freigegeben.

So einfach kann es sein seinen geliebten und teuren Speicherplatz wieder frei zu bekommen.

Was deine iPhone Facebook App über dich verrät

Heute ist mir beim durchschauen meiner Server Logs etwas interessantes aufgefallen. Wusstet ihr eigentlich, was euer iPhone so alles über euch verrät wenn ihr darüber Webseiten aufruft?

Mit den meisten dieser Angaben kann ich jetzt persönlich nicht viel anfangen, es sieht für mich aber danach aus als wenn hier zeimlich genau mitgeteilt wird um welche iPhone generation es sich handelt und welchen Softwarestand man verwendet (Ui, was sich da so anbieten würde um automatisiert Exploits auf das passende Modell los zu lassen…)

Was mich allerdings am meisten verwundert hat ist der Punkt “FBCR”.

Hier scheint das iPhone doch tatsächlich ungefragt den Mobile Carrier an jede besuchte Webseite weiter zu geben.

Wozu ist denn bitte sowas notwendig? Wieso muss ein Webseiten Betreiber diese Information “frei Haus” geliefert bekommen?

Hat hier irgendjemand ein paar weiterführende Informationen? Ich konnte leider nicht viel finden über die einzelnen Parameter. Kann man das irgendwie abstellen? Ich hab selbst kein iPhone mit dem ich das testen könnte…

Achja, nur der Vollständigkeit halber, Android ist ebenfalls recht gesprächig was genaue Versionen angeht, verrät aber wenigstens nicht den Carrier.

Update: Ich wurde darauf hingewiesen, dass die Spannenden Felder nicht durch iOS an sich hinzugefügt werden, sondern ihren Ursprung in der Facebook App haben.

Unter Android kann ich das verhalten weiterhin nicht nachvollziehen…

Update 2:

Aus den Kommentaren von Etan Kissling:

– fban wahrscheinlich app name (fb ios)
– fbav wahrscheinlich fb app version
– fbbv – baseband version? ka

– fbdv – device
– fbmd – model
– fbsn – software name
– fbsv – software version
– fbss – ka wahrscheinlichh auch was mit software
– fbcr – carrier
– fbid – ev device idiom
– fblc – locale
– fbop – ka ev was es für ein link war / ob ein post oder ein foto oder ein quote oder so

Die Facebook App scheint sich unter iOS anders zu verhalten als es mir Bisher bewusst war. Öffnet man via Facebook einen Link, wird hier eine UIWebView Referenz verwendet um Inhalte direkt anzuzeigen und ein zurückkehren zur Facebook App zu ermöglichen. Diese WebView übermittelt dann scheinbar die oben sichtbaren Informationen. Für alle, die sich das genauso wenig vorstellen können wie ich, hier mal zwei Bilder davon wie das dann aussieht.

11351352_10204191007843602_6744414928828506499_n

11351411_10204191008843627_5995725200841356205_n

 

Vielen dank an Etan Kissling für diese Bilder :)

Update 3:

Titel angepasst

 

Hilfe! Meine Festplatte ist voll. Aber ich hab doch noch soo viel Platz frei (Inodes)

Einige von euch kennen es bestimmt. Ihr wollt auf eurem Linux System eine neue Datei anlegen und es antwortet euch trocken “no space left on device” oder zu deutsch “Auf dem Gerät ist kein Speicherplatz mehr verfügbar”.

Mist. Wird wohl zeit mal wieder aufzuräumen. Gucken wir doch mal wie voll das Dateisystem eigentlich ist.

Siehst du, da sind doch noch ganze viel frei, wieso kann ich dann keine Dateien mehr erstellen?

Speicherplatz ist nicht das einzige was frei sein muss, damit man Dateien erstellen kann. Auch müssen sogenannte Inodes frei sein, um die Referenzen auf diese Dateien speichern zu können.

Ein Inode sagt dem System, wo die Datei oder der Ordner den man sucht zu finden ist. Diese sind in ihrer Anzahl allerdings begrenzt. Weitere Informationen was ein Inode ist findet ihr z.B. hier.

Um zu sehen, wie viele Inodes wir noch frei haben, können wir wieder den “df” Befehl verwenden

Oooh, da haben wir tatsächlich gut 65.000 Dateien auf unserem Filesystem und wirklich keinen Platz mehr für neue…

Und wie kann ich das nun Lösen?

Am einfachsten:

Durch löschen von Dateien.

Wenn das nicht geht haben wir aber noch andere Möglichkeiten an neue Inodes zu kommen.

Wir können das Filesystem einfach erweitern (Vorausgesetzt wir verwenden LVM und haben ein Filesystem welches Online Erweiterungen unterstützt).

Nun haben wir wieder 65336 freie Inodes. Und fast 2GB freien und unbenutzten Speicher.  Das ist natürlich auch doof… Wir wollen ja gar nicht so viel Speicher verschwenden nur um noch einmal ein paar winzige Dateien anlegen zu können.

Auch hier haben wir einen Ausweg:

Wir legen das Filesystem neu an (Backup!)

Mit “-N” können wir hier nun festlegen, wie viele Inodes wir haben wollen. Wissen wir vorher, wie viele Dateien wir haben werden, ist das in meinen Augen mit der beste Weg um nicht zu viel Speicher zu verschwenden.

 

 

CentOS 7 um Extra Packages for Enterprise Linux (EPEL) erweitern

Möchte man bestimmte Software unter CentOS installieren, kommt man irgendwann zu dem Punkt, dass diese Pakete nicht in den Standard Repositories mitgeliefert werden.

Oftmals hilft es dann das EPEL Repository zu installieren und zu nutzen.

Eine Übersicht darüber, welche Pakete im EPEL Repo enthalten sind findet ihr hier.

Aber wie nutze ich das Repository jetzt?

Nichts leichter als das. Um uns die Nutzung des Repositories möglichst einfach zu machen, werden von Fedorahosted spezielle RPM Pakete bereitgestellt welche sich bereits im “Standard Lieferumfang” befinden.

Das ganze noch bestätigen und schon könnt Ihr die Vielfalt der EPEL Pakete nutzen.

 

SSH per sudo und Keys “absichern”

Heute will ich euch kurz erklären, wie ihr euren SSH Daemon zumindest ein klein wenig sicherer machen könnt indem Ihr einige kleine Änderungen an dessen Konfiguration durchführt und sudo verwendet.

WICHTIG: Zu keinem Zeitpunkt die SSH Sitzung des Root Users beenden. Unter Umständen sperrt ihr euch sonst selbst von eurem System aus.

Zuerst sollten wir uns auf jeden Fall einen nicht root User anlegen. Dies geschieht unter CentOS mit folgendem Befehl:

Haben wir den User angelegt, müssen wir ihm ein Passwort zuweisen. Dies benötigen wir später als weiteren Schritt zur Authentifizierung beim Aufruf von sudo.

Damit wir den User nun auch zur Administration unseres Servers verwenden können, brauchen wir das Packet “sudo”

Unter CentOS kann dies einfach mit

installiert werden.

Nun haben wir mehrere Möglichkeiten um dem neuen User seine Administrator Berechtigungen zu gewähren. Entweder, wir geben dem Nutzer direkt die Rechte Befehle als root auszuführen, oder wir weisen dem User eine Gruppe zu welche die Rechte erhalten soll. Hier muss jeder für sich selbst entscheiden was ihm am liebsten ist. Hat man mehrere User die root Rechte erhalten sollen? Dann würde ich die Gruppe bevorzugen.

Wie auch immer man sich entscheiden sollte, wir bearbeiten zunächst einmal die Datei /etc/sudoers

Nun wechseln wir in den grade angelegten User mit

und überprüfen ob die Einträge in der /etc/sudoers korrekt gesetzt wurden

Das sieht schon einmal gut aus. Um ganz sicher zu sein, können wir jetzt auch noch ein “sudo id” machen und werden sehen, das System erkennt uns als Root User.

Damit wären die Grundlagen für eine Funktionierende sudo Konfiguration erledigt.

Nun bearbeiten wir die SSHd Konfigurationsdatei:

Anders als die meisten werde ich euch an dieser Stelle nicht empfehlen den SSH Port zu verändern… Das könnt ihr tun, könnt ihr aber auch genauso sein lassen. Meiner Meinung nach sorgt das verlegen des SSH Ports nur für etwas weniger Grundrauschen in den Logfiles.

Folgende Einträge sollten geändert werden:

Haben wir dies erledigt, müssen wir den SSH Daemon einmal neustarten. In CentOS 7 und RedHat 7 (Und jeder anderen Distribution die bereits systemd verwendet) machen wir dies wie folgt

Spätestens ab hier ist es absolut wichtig, das Ihr eure Root SSH Sitzung vorerst NICHT beendet. Ab jetzt habt ihr keine Möglichkeit mehr auf euer System zu gelangen.

Das ist aber nur halb so schlimm, das werden wir jetzt auch gleich wieder beheben.

Wir brauchen nun Erstmal einen SSH Key den wir fortan für die Authentifizierung verwenden wollen.

Unter Linux erstellen wir den Key wie folgt: [1]

-b Die Key Länge in Bytes

-a Gibt an wie viele Runden “key derivation” verwendet werden sollen. Höhere Zahlen führen zu einer Verlangsamung der Passwort Verifizierung und steigert den Aufwand von Brute-Force Attacken sollte der SSH Key mal gestohlen oder verloren werden.

-o Speichere den SSH Key im neuen OpenSSH Format anstatt im “kompatiblen” PEM Format.

Kopiert euch den Inhalt von /home/<username>/.ssh/id_rsa.pub. Diesen werden wir gleich wieder brauchen.

Unter Windows verwenden wir hierzu PuTTYgen

Wie unter Linux auch, wählen wir hier einen RSA Key mit 4096 Bits und Klicken auf “Generate”

PuttyGen1

 

Das erstellen der Zufallszahlen dauert nun einen Moment, bewegt einfach euren Mauszeiger in der freien Fläche unter dem Statusbalken.

 

PuttyGen2

 

Habt ihr genug Zufallszahlen erzeugt, beginnt PuTTYgen den Key zu erstellen:

PuttyGen3

 

 

Nach Abschluss der Erstellung wird euch folgendes angezeigt

PuttyGen4

Kopiert euch den Teil aus dem Feld “Public Key” in ein Textdokument eurer Wahl. Diesen Benötigen wir gleich wieder.

Speichert euren neuen Private Key mit klicken auf “save private key” und wählt einen Ort zum speichern aus.

Wieder zurück in der SSH Sitzung auf unserem Server wechseln mit “su – <username>” in unseren neuen User.

In unserem Home Verzeichnis erstellen wir einen Ordner namens .ssh und dort erstellen wir eine Datei mit dem Namen “authorized_keys”.

Noch schnell die Zugriffsrechte auf die authorized_keys anpassen, sonst meckert der SSH Daeomon rum.

Nun fügen wir den gerade kopierten Public Key in die authorized_keys ein (Mit vi oder jedem anderen Editor eurer Wahl).

Achtet darauf das Ihr wirklich nur den Key einfügt. Keine Leerzeichen oder Zeilenumbrüche dazwischen.

 

Jetzt ist es endlich an der Zeit, das Login mit unserem neuen User auszuprobieren.

Unter Linux, einfach

eingeben und dann das Passwort zu eurem Private Key eingeben und ihr solltet verbunden sein.

Unter Windowss benötigen wir wieder ein kleines Tool, den Pageant

Wir starten das Programm und unten in der Benachrichtigungszeile von Windows erscheint ein neues Zeichen. Dort einfach Rechtsklick drauf, “Add Key” und den gespeicherten Private Key auswählen.

Hat alles geklappt, könnt ihr nun mit sudo euren Server wie gewohnt Administrieren.

 

[1]: http://blog.patshead.com/2013/09/generating-new-more-secure-ssh-keys.html