Archiv der Kategorie: LPIC-1[102]

EDV für Dummies

oder „Apps und andere moderne Wunder“.
Um elektronisch Daten verarbeiten zu können benötigt man Maschinen. Von Großrechnern, ja die soll es auch noch geben, Midrange-Rechnern, ja, auch AS/400 ähnliche Dinge laufen noch, will ich hier genau so wenig sprechen, wie von Clouds, Cluster, Crids und Amöben oder Smartphones. Hier wundere ich mich nur einmal mehr über die Abzocke von professionellen und privaten PC-Benutzern.
Wenn sich heute jemand einen PC kauft, ist meist Windows vorinstalliert, oder es wird dem Kunden separat dazu verkauft. Wer sich ein Windows kauft, muss sich zwangsläufig auch viele andere Programme kaufen, denn ohne Firewall, Antivirus, DVD-Brennsoftware usw. wird man mit Windows nicht viel anfangen können. Für jede neue Version darf dann wieder extra bezahlt werden und die benötigt man ja unbedingt, zum Email schreiben oder um auf FaceBook Kommentare abzugeben. Für die meisten Leute die ich kenne, würde einer der ersten PC’s, die auf dem Markt kamen, völlig ausreichen. Online-Spieler, Foto- und Videobearbeiter sind da natürlich ausgenommen, aber einige von meinen Bekannten spielen nur ein paar mal, damit sie einen Grund haben, sich einen Superrechner zu kaufen, danach würde für ihre Tätigkeiten am PC auch ein Commodore 64 genügen.
Na gut, das hatten wir hier ja schon oft gehört und auch über die kriminellen Raubkopierer, die illegale Software verwenden, statt sich ein kostenloses, quell-offenes Linux zu installieren habe ich schon öfter geschrieben.
Jetzt sind mir diverse Kurse und Ausbildungen ins Auge gesprungen. Da zahlen Leute Unsummen, von einigen hundert bis zu mehreren tausend Euros dafür, dass sie sich eine alte Doku zu einer Software vorlesen lassen. Für Kurse zu freien Open-Source-Produkten, Programmiersprachen und Datenbanken, obwohl es rfc’s, recommendations, specification und Dokumentationen gibt. Die sind kostenlos erhältlich und immer am neuesten Stand der Dinge. Für jede neue Version einer Programmiersprache oder Datenbank erhält man mit dem Erscheinen die zugehörige Dokumentation.
Auch über Tutorials und Bücher dazu wundere ich mich manchmal, obwohl ich selbst schon welche kaufte. Ja, es ist einfach ein gutes Gefühl ein Buch mit über 1000 Seiten in der Hand zu halten und auf diese Art, die sonst kostenlose Dokumentation zu lesen, denn meist ist sie mit Schwänken aus dem Leben des Autors aufgelockert. Für manche mag es eben unheimlich wichtig sein, zu wissen, dass Ruby der Zucker ist, unter den ProgSpr und dass man eine Tasse Kaffee (oder 10 Liter Tee) trinkt, während der Java-Kompilation vom ersten „Hello World“ mit Eclipse, denn ohne IDE wird’s meist sowieso nix. Leider wissen manche ausgebildete App-Entwickler nach ihrem Abschluss mit Auszeichnung noch immer nicht, dass sie ganz gewöhnliche Anwendungsprogrammierer (app kommt von application, was soviel wie Anwendung bedeutet, liebe Dummies) sind, wie es sie schon seit den ersten Anwendungsprogrammen auf den 286er gab. Ich will Anwendungsprogrammierer auf keinen Fall unter Systemprogrammierer stellen, ganz im Gegenteil, die operieren ja sogar eine Schicht höher, aber App-Designer, App-Entwickler, App-Analytiker und App-Ingenieure sind mir suspekt. Bin ja nur gespannt, wann sich das erste Dummy App-AnwendungsprogrammiererIn für x-Anwendungen nennt. Aber verdenken kann ich es keinem, so ist das nun mal in unserer Welt. Ein Brainstorming (heute ist übrigens der Shitstorm viel moderner) verschafft dem Internet Versionsnummern und beginnt bei Web 2.0, obwohl es eigentlich ein Beta 0.1 ist, aus einem Http-Request wird Ajax und aus dem Rindsbraten meiner Urgroßmutter das „Boeuf à la mode – Prince Eugène“ oder aus der Palatschinke ein „Crêpes réchauffer et séduisant, rempli de confiture d’abricot trop sucrée avec sucre glace“. Na warum eigentlich nicht? Und da kann man dann schon ein bisserl mehr verlangen, denn immerhin muss der Kellner den Namen der Speisen ja auch lernen.
Alles gut und schön, aber wie kann man einen teuren Kurs besuchen um eine Markup-, Script- oder Programmiersprache zu erlernen? Ich wollte zu solchen Leuten eigentlich keinen näheren Kontakt und sie auch nicht genauer befragen, aber ich habe Besucher solcher Kurse dann doch kurz befragt, welches Betriebssystem (OS) sie dazu benutzen. Ich war nicht besonders überrascht darüber, dass manche behaupteten, sie verwenden kein OS, andere wussten nicht genau was das ist. Wieder andere meinten es ginge wohl um die Version von Windows, womit sie ja schon verdammt nahe dran waren. Ich wollte es nicht so genau wissen und hätte mir eigentlich nur Bezeichnungen für ihr OS gewünscht, aber die zwei lustigsten Antworten muss ich mir doch notieren. Ein angehender C++-Programmiere gab seine Befehle in die CMD ein und hielt diese nicht nur für das OS, sondern auch für IDE bzw. für Compiler, Linker und Editor. Das war für mich so ziemlich der Lustigste, aber ein JAVA-Experte stand ihm nicht viel nach, als er belehrend behauptete, dass JAVA Betriebssystem unabhängig sei und er daher keines benötigt zum Programmieren. Wow, das ist ja echt schräg. Ich habe da ja so einiges dazugelernt, vielleicht sollte ich mich auch für so einen Kurs oder einen PC-Führerschein einschreiben lassen.

(1824)

1.106.2 Ändern des Runlevels

zurück zu Linux Zertifizierungen LPIC
Ändern des Runlevels und Niederfahren oder Neustart des Systems
Beschreibung: Prüfungskandidaten sollten in der Lage sein, den Runlevel des Systems zu verwalten. Dieses Lernziel beinhaltet den Wechsel in den Single-User Modus und das Niederfahren oder Rebooten des Systems. Kandidaten sollten auch in der Lage sein, Benutzer vor dem Wechsel des Runlevels zu benachrichtigen und Prozesse sauber zu beenden. Dieses Lernziel beinhaltet auch das Setzen des Standard-Runlevels.

Die wichtigsten Dateien, Bezeichnungen und Anwendungen:

* shutdown
* init
* /etc/inittab

Runlevel und ihr Wechsel
Linux bietet verschiedene Betriebszustände an, sogenannte Runlevel (manchmal auch init-level genannt). Im Wesentlichen geht es dabei um die Frage, welche Dienste zur Verfügung gestellt werden und welche nicht.
1.106.2 Ändern des Runlevels weiterlesen

(248)

1.106.1 Booten des Systems

zurück zu Linux Zertifizierungen LPIC
Beschreibung: Prüfungskandidaten sollten in der Lage sein, das System durch den Bootprozeß zu führen. Dieses Lernziel beinhaltet das Übergeben von Kommandos an den Bootlader und die Übergabe von Optionen an den Kernel zum Bootzeitpunkt sowie das Überprüfen von Ereignissen in den Logdateien.

Die wichtigsten Dateien, Bezeichnungen und Anwendungen:

* dmesg
* /var/log/messages
* /etc/conf.modules oder /etc/modules.conf
* LILO
* GRUB

Der Bootvorgang von Linux kann auf verschiedene Art und Weise gestartet, beeinflusst und nachvollzogen werden. Für die Anforderungen des LPIC 101 Examens genügt das Wissen um die Techniken, die mit dem Linux Loader (lilo) oder dem alternativen Bootmanager grub zu tun haben. Das soll auf dieser Seite näher erläutert werden.
1.106.1 Booten des Systems weiterlesen

(250)

1.114.3 – Sicherheit auf Benutzerebene

zurück zu Linux Zertifizierungen LPIC
1.114.3 – Einrichten von Sicherheit auf Benutzerebene
Prüfungskandidaten sollten in der Lage sein, Sicherheit auf Benutzerebene zu implementieren. Die Tätigkeiten beinhalten das Verwalten von Beschränkungen auf Benutzerlogins, Prozesse und Speichernutzung.

Die wichtigsten Dateien, Bezeichnungen und Anwendungen:

* quota
* usermod

Die Verwaltung von Einschränkungen einzelner Useraccounts ist ein vielfältiger Bereich, der in einzelnen Fällen schon in anderen Abschnitten beschrieben wurde. Die Haupt-Möglichkeiten der Einschränkungen liegen in einer durchdachten Organisation der Dateien und Programme hinsichtlich ihrer Gruppenzugehörigkeit. Sind bestimmte Programme nur von Mitgliedern einer bestimmten Gruppe ausführbar, so kann z.B. die Einstellung, welcher User ein solches Programm ausführen darf einfach über die Gruppenmitgliedschaft des Users verwaltet werden. Diese Techniken sind im Abschnit 1.111.1 bereits beschrieben worden.

Auch die Möglichkeit, die Gültigkeit eines Accounts und andere einen User betreffende Einstellungen mit usermod zu verändern wurde dort bereits ausführlich besprochen.

Die Einschränkungen des Festplattenplatzes, den einzelne User zur Verfügung haben mittels diskquotas wurde bereits bei der Vorbereitung auf die Prüfung LPI101 im Abschnitt 1.104.4 ausführlich besprochen und wird daher hier nicht weiter behandelt.

Einschränkungen mit ulimit
Eine Sache, die noch keine Beschreibung erfahren hat, für userbezogene Einstellungen aber sehr wichtig ist, ist der Umgang mit dem Shellbefehl ulimit. Es handelt sich hier um ein eingebautes (internes) Shellkommando, das der Shell selbst Einschränkungen hinsichtlich der von ihr benötigten Ressourcen macht. In der Regel werden diese Einstellungen in systemweiten Startdateien der Shell (wie etwa /etc/profile) gemacht. Einstellungen in usereigenen Startdateien sind in der Regel sinnlos, weil jeder User diese Einschränkungen selbst wieder aufheben könnte.

ulimit kennt verschiedene Möglichkeiten für Beschränkungen von Ressourcen, die für die Shell und alle Prozesse, die von ihr gestartet werden gelten. Die Syntax ist:

ulimit [-SHacdflmnpstuv [Limit]]

Die Optionen -H und -S spezifizieren jeweils den Hard- bzw. Softlimit einer Ressource. Ein Hardlimit kann nicht mehr erhöht werden, sobald er einmal gesetzt ist. Ein Softlimit kann bis zum Wert des Hardlimits erhöht werden. Werden beide Angaben weggelassen, so werden sowohl Hard-, als auch Softlimit gesetzt.

Die Angabe des Limit kann entweder eine Zahl sein, in der für die angegebene Ressource gültigen Einheit, oder einer der Spezialwerte hard, soft oder unlimited. Diese Spezialwerte bezeichnen die für diese Ressource eingestellten Hard- und Softlimits bzw. keinen Limit.

Ist kein Limit angegeben, so wird der gegenwärtige Wert des Softlimits der entsprechenden Ressource ausgegeben. Ist zusätzlich ein -H angegeben, so wird stattdessen der Hardlimit angezeigt.

Die einzelnen Ressourcen werden über Parameter eingestellt und haben die folgenden Bedeutungen:

-a
Alle aktuellen Limits werden dargestellt
-c
Stellt die maximale Größe von Core-Dateien ein. Das sind Dateien, die erstellt werden, wenn ein Programm abstürzt. Diese Dateien enthalten dann den Daten- und Programmbereich des abgestürzten Programms für die Fehlersuche mit einem Debugger. Ein Wert von 0 schaltet Core-Files grundsätzlich ab.
-d
Die maximale Größe des Datensegments eines Prozesses.
-f
Die maximale Größe von Dateien, die die Shell anlegt.
-l
Die maximale Speichergröße, die gesperrt werden darf
-m
Die maximale Größe von residentem Speicher
-n
Die maximale Anzahl gleichzeitig geöffneter Dateien
-p
Die Größe von Pipes in 512 Byte Blöcken
-s
Die maximale Stack-Größe
-t
Der maximale Wert von CPU-Zeit in Sekunden
-u
Die maximale Anzahl von Prozessen für einen einzelnen User
-v
Die maximale Größe von virtuellem Speicher, der für die Shell verfügbar ist.

Ist Limit angegeben, so bezeichnet er den neuen Wert für die angegebene Ressource (außer bei -a, das nur Ausgaben macht). Wird keine Ressource angegeben, so wird -f angenommen. Die Werte beziehen sich in der Regel auf 1024 Byte Blöcke, außer bei der Angabe von -t (Sekunden), -p (512-Byte Blöcke) und -n und -u, die keinen Multiplikator haben sondern genau so gewertet werden, wie angegeben.

Ein typischer Eintrag in /etc/profile wäre z.B.

ulimit -Sc 0 # Der Soft-Limit für Core-Dateien wird
# auf 0 gesetzt
# Es werden also keine Corefiles angelegt.
ulimit -d 15000 # Hard- und Softlimit für die Datengröße
# eines Programmes werden auf 15 MByte
# gesetzt (15000*1024)
ulimit -s 15000 # Hard- und Softlimit für die Stack-Größe
# eines Programmes werden auf 15 MByte
# gesetzt.

# Die folgende Konstruktion gilt nur für den User hans.
# Er darf nicht mehr als 10 Prozesse gleichzeitig laufen haben.
if [ $LOGNAME = „hans“ ]
then
ulimit -u 10
fi

Mit diesen Einstellungen ist es möglich, die einzelnen User in ihrem Ressourcenverbrauch einzuschränken. Diese Ressourcen beziehen sich aber nur auf eingeloggte User, nicht auf Netzwerkdienste. Genau besehen sind es ja Einstellungen der Shell. Also greifen diese Einstellungen nur da, wo die Shell aktiv ist.

(291)