Archiv der Kategorie: Gewöhnlich

Das ist meine „miscellaneous“ Kategorie

200 Jahre Augusta Ada Lovelace

200 Jahre Augusta Ada Lovelace – wobei meine Beziehung zu Ada 20 Jahre alt ist, zumindest ungefähr 20 Jahre, wenn Ihr mir diese Geschichtsglättung erlaubt. Vor 20 Jahren habe ich mich mit den ersten Rechenmaschinen und deren Erfindern befasst. Neben Frau Lovelace waren dies Persönlichkeiten wie Wilhelm Schickard, Gottfried Wilhelm Leibniz, Charles Babbage und viele mehr. Weiterlesen

Kubuntu Benutzerverzeichnis nachträglich verschlüsseln

Nachdem ich mir mit diversen Anleitungen, die händisch Kopieren und „deluser“ verwenden, in den Fuß geschossen hatte, hier eine kurze Anleitung wie das bei mir unter Kubuntu, Ubuntu 14.04 wunderbar automatisiert funktioniert hat.

Hinweis

Auf dieser Seite findet Ihr einen persönlichen Erfahrungsbericht. Dies ist keine offizielle Support-Page! Ich Übernehme keinerlei Garantie für die Angaben und es gilt der rechtliche Hinweis.

An welche Leser wende ich mich? Es können Daten verloren gehen. Ihr auf jeden Fall experimentierfreudig sein. Alle Einstellungen, Konfiguration, Kommandos, etc. müsst Ihr bitte selber hin bekommen. Das heißt im wesentlichen:
  1. Alle Daten vorher sichern (Backup)
  2. apt bzw. den Adept Manager bedienen können
  3. Readme-Dateien lesen
  4. Die Fehlermeldungen lesen, im Internet suchen und die Problemchen lösen

Eine sehr gute Quelle für Hinweise und Fragen ist http://wiki.ubuntuusers.de/

Los geht’s

Ich gehe von einem Rechner mit nur einem Hauptbenutzer aus. Habt ihr mehrere Administrative Benutzer können die ihre Kollegen gegenseitig migrieren, das Ganze ist also etwas weniger aufwändig als hier dargestellt, wenn ihr mehrere Benutzer habt.

Kurzer Check: Die Migration legt eine unverschlüsselte Kopie des Hauptverzeichnis an (/home/<user>.XXXXXXXX). Auf dem Laufwerk muss entsprechend Platz vorhanden sein. Die aktuelle Größe findet ihr mit dem Dateimanager oder der Kommandozeile heraus

user@maschine:~$ du -sh /home/<user>
3,7 GB
user@maschine:~$ df -h
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf 
/dev/sda1 299G 146G 148G 49% /

Als Software wird encryptfs benötigt. Dies ist entweder mit dem grafischen Paketmanager oder der Kommandozeile zu installieren.

sudo apt-get install ecryptfs-utils

Nun müssen wir an eine Root-Shell herankommen, die nicht vom Hauptbenutzer aus aufgerufen wurde, denn ansonsten ist /home/<user> geöffnet und kann nicht migriert werden. Das geht in dem man den Rechner im Recovery-Modus bootet, dazu beim starten <Shift> halten (bei manchen Computern wohl auch <Esc>).

Im Menü „Wiederherstellungsmodus“ dann „root“ wählen. Es erscheint eine Kommandozeile. Das Dateisystem ist in dem  Moment „read-only“ eingebunden, um es schreibbar zu machen

mount -o remount,rw /

Jetzt kann die Aktion losgehen

ecryptfs-migrate-home -u <user>

Zum Ende der Migration kommt eine Meldung die bitte unbedingt zu beachten ist.

  1. Das die Migration erfolgreich war, jedoch der Nutzer sich sofort ohne zu booten(!) einzuloggen hat, um die Migration abzuschließen.
  2. Die Migration hat die Daten unverschlüsselt zuvor in ein Verzeichnis /home/<user>.XXXXXXXX gesichert. Dieses Verzeichnis sollte irgendwann gelöscht werden.
  3. Der <user> sollte sich beizeiten seine Passphrase notieren. Dies geht via dem Befehl ecryptfs-unwrap-passphrase bzw. über ein grafisches Tool nach dem ersten einloggen.
  4. Eine vollständige Verschlüsselung bezieht auch Swap ein (habe ich mir gespart)

Also unbedingt ohne Neustart!

login <user>
exit

Falls alles fehlerfrei abgelaufen ist, die Recovery-Root-Shell mit <Strg>-<D> verlassen und im Menü Resume wählen, um das System zu starten.

Der <user> kann sich nun grafisch einloggen und bekommt bei KDE via der kleinen Glühlampe in der Taskleiste vorgeschlagen sich seine Passphrase aufzuschreiben.

Viel Spaß!

Hits des Jahres 2014

Die Jahresend-Pause ist ein willkommener Anlass mal in die Web-Statistik zu schauen. Während es in den letzten Jahren der Text zu Diplomarbeiten mit OpenOffice.org immer wieder mit Abstand an die Spitze der Abruf-zahlen brachte, hat sich das in 2014 geändert. Es führt zwar wieder ein technischer Text, aber die normalen Blog-Beiträge holen auf. Hier meine Top 10 aus den letzten 3 Monaten (bereinigt um Feeds, Bilder, Kommentare und kurze Beiträge).

  1. Netzwerk mit zwei WLAN-Access-Points
    Ein Beitrag aus 2012 der es mittlerweile auf durchschnittlich 3500 Abrufe pro Monat schafft.
  2. Diplomarbeiten mit LibreOffice
    Liegt nur noch bei 1350 Klicks.
  3. Transformation: There are no easy answers
    Die Einführung von IT Service Management durch schlechte Berater in einer schmutzigen WG (970).
  4. Was verbirgt sich hinter verschiedenen Support Level oder Lines?
    Lines of Support ohne Mythen simpel erläutert (930).
  5. What is the defined scope of different support levels or lines?
    Die englische Version des Platz #4 bringt es auf 790 Besuche.
  6. Processes without people – Hope springs eternal
    Ein Beitrag über die Unart IT Service Management per Beratung und PowerPoint einzuführen. Erstaunlicherweise zieht der englische Text wesentlich mehr Besucher (670) als die deutsche Version mit ca. 40 pro Monat.
  7. Transformation: There are no easy answers
    Die englische Version der #3 (510).
  8. Issue: Incident and Problem
    Die Unterscheidung zwischen Incident und Problem in Theorie und Praxis (460)
  9. Espresso Experience – Anfängerfehler
    Wunderbar auch nicht IT Artikel schaffen es in die Top 10 (250)
  10. Service Desk Nearshoring
    Ein Projektbericht über die Zentralisierung eines Service Desks (210).

Bildet den Abschluss dieser Liste. Viel Spaß beim Stöbern bis zum nächsten Blog-Eintrag.

Wichtig, Wichtiger am Wichtigsten

Manchmal – ganz kurz – sehne ich mich zurück und möchte meinen Monitor gegen ein 90-iger Jahre 21″-Paperwhite Exemplar tauschen. Aus dem einzigen Grund: Von Mitmenschen verbrochene Rich-Text-E-Mails oder Dokumente in ihrer Wirkung etwas abmildern zu können.

Da wird munter mit Farben und Auszeichnungen rumgeklotzt, dass es einem in den Augen vor lauter Hervorhebung wehtut. Der erste Fehler ist natürlich, dass Textverarbeitungen und E-Mail-Clients so einen Müll auf einen Mausklick bereitstellen.

Wichtig wichtiger

Der zweite Fehler ist jedoch schlimmer: Man tut Unbildung und Verwirrung kundtun.

Zerlegt man ein Dokument mit duzendfacher Auszeichnung in dessen unterschiedliche Bestandteile, stellt man fast immer fest, das trotz mannigfaltiger Unterstrechung und Hervorhebung es dem Autor entglitten ist: Wichtiges wird nicht von Unwichtigem unterschieden. Ganz so wie Studierende Bücher und Skript mit dem Textmarker durcharbeiten. Dinge sind so lange wichtig, wie der Arm noch nicht weh tut.

Also noch mal zurück auf Los. Die Dinge sind erst gut, wenn sie nicht mehr vereinfacht werden können.

  1. Text sortieren und gliedern. Auch wenn es nur eine E-Mail ist. Was soll der Leser verstanden haben? Mit einem Element beginnen: Wenn der Leser fast nichts versteht, welcher Inhalt muss verstanden sein? Jetzt auf zwei Elemente erhöhen.
  2. Überschriftsebenen gliedern den Text, so wenig wie möglich, so viel wie nötig.
  3. Kursiv für Dinge die während des Lesens auffallen sollen. Kursiv verlangsamt das Lesen. Bitte keine ganzen Passagen kursiv.
  4. Fett zieht wie ein Schlagwort im Lexikon die Aufmerksamkeit an sich. Was soll der Leser beim ersten Anblick des Dokuments erfassen?

Fertig, mehr braucht es nicht. Wer mehr über Typografie wissen mag: Typografie mit dem OpenOffice.org Writer

P.S.: Wenn sich 12-jährge zum ersten Mal schminken, kommt doch auch die Mama mit dem feuchten Tuch und macht der Sache ein Ende. Warum gibt es solche Zuwendung nicht auch in der Geschäftswelt? Ich gäbe etwas darum.

Processes without people – Hope springs eternal

Ages ago I started my career in the Unix company with the nice logo. In transition projects when Windows infrastructure was changed to Unix, there was a golden rule: Find new jobs for the old administrators – a good inter company choice was the client environment. The reason is simple, it takes a lot of training and time to become familiar with a different architecture and learn about new approaches. In other words: If you try to re-educate existing staff, there is a high chance that the “everything used to be better” minded will win the game by time.

[Link to German version]

Dear reader, feel free to flip the place-holders “Windows” and “Unix” or substitute them by any other things that are different in concept and you’ve a general rule.

Let us use the place-holders “historical IT operational sequences” and “operations guided by ITIL® practices” in this article. The astonishing fact about this flavour of the general rule is: There are people out in IT industry who believe that something like this can work satisfyingly.

We use the example of a certain IT department, which is according to industry benchmark too rich staffed. The results of this department are not good, but tolerable in quality, using a lot of overtime work. This example is not completely unfounded, such set-ups can be easily found. Take a look at established internal IT organizations who did the usual mistake negotiating special terms with a lot of internal customers. All these special agreements weaved to a thick complex network, that is operated manually and eats a lot of resources. From a corporate perspective, usually without any deeper reason or benefit.

In fact such a situation is perfect to structure everything towards ITIL. A project could implement and standardize internal agreements (OLAs) which ensure that extra-services are only carried out against extra-money. A change management could take care to focus and prioritize changes. The formerly too rich department would be enabled to separate important from unimportant things using a business perspective. After standardization, change requests will be professionally evaluated, communicated and implemented. Something like this can work and will save a lot of money in the end.

In such situations I often notice that the old team is almost not supported. A consultant explained them ITIL upfront in a three sessions course, even sometimes including the necessary changes in correctly amended detail. Taken the short time into account – means no time to think – the team understands: “They want to bother us, the consultant understands not a single bit of our business needs; and oh, god, we will get an extra burden of bureaucracy!” Depending on the behaviour of the management team, usual after initial defensive battles of the team in which management just gets the “everything used to be better” attitude, management switches to high pressure mode and cuts headcount.

The reaction of the old team, that still does not gets the meaning and benefits of industrialization and good practices, will start to play a role, e.g. masquerades a process flow that makes no sense. In reality, they do their old job. But now much worse, with fewer resources and supporting this extra “process” bureaucracy. Such “ITIL implementation” becomes ludicrous when there is a high 6-digit budget for the design, but almost no money left for implementation and management decides to assign this task to the old teams and who apparently get nothing more than some material to read.

I always wonder, what is the mindset of people who want develop service management using this approach. Essentially this is as worse as sending initially mentioned Windows administrators to a short Unix training. With the next problem popping up this short trained guys are clueless. To build a bridge from problem to solution was a no brainer for those guys in their familiar environment, because the solved similar cases in the past. Now with the new technology everything seems to be difficult and unmanageable. No one understands why managements goes for this stupid Unix. (Again feel free to interchange “Windows” by “Unix” administrators).

The missing knowledge to bridge a gap applies as is also for operating processes: the well known evolved processes are familiar, in an ITIL world a way walking along the accepted practices is unknown and hard to find.

The reason is familiarisation and can be observed by the example of a new employee in the old department structures: In the first working days the new employees will realize the existing procedures as complex, confusing and he finds the need of improvement obvious. After half a year he gets along quite well in the chaos and the impression of complicated will start to dissolve. After a year he will already be absorbed in the processes and all his initial suggestions to improve the mess are refused as too simple, because by his current knowledge all suggestions do not reflect all the different special rules of each internal customer.

My finding is: In existing structures only a few people are able switch to an abstraction level that enables them to map the existing to a new system. One key to success is to find and utilize those employees to communicate with ITIL experienced staff or consultants. You will need them to leverage solutions until the major part (e.g. 80%) of the problems were solved by alternatives. Beware those alternatives, are developed by experts of the new system. A Windows administrator is not able to develop a Unix-style solution. When the architects of the old system develop the new solution, you will get the worst of both worlds. Basically a concept of the ancient world, with a lot of whopping and tinker to be amended to the new world.

My letter to the protectors of the budget, if there is no budget for implementation available, please wait for the next fiscal year. Delay is a far better idea, than the abuse of the old team plus some prayers for a miracle.

Last note: Initial general rule is in general not commutative. People who are used to higher maturity, can easily manage lower maturity structures. This is a usual smack in corporate acquisitions. Nevertheless there is a direct link to higher attrition if such simple structured operations become the main task of senior employees.