eine kleine Putting Übung

August 26th, 2018 No comments

Wir golfen seit ein paar Wochen und ich dachte, ich bereichere das Interwebz nun mal mit einem ersten Golf-Posting =) 

 

Ein toller Tipp unseres Pro, um zuverlässiger mit dem Putter gewisse Längen zu erzielen ist folgender:

 

 

  • Wir benötigen zwei Linien.
  • Die vordere, gedachte, Linie gilt als Minimum, die hintere Linie als Maximum.
  • Das kann man an Fixpunkten wie der Fahne oder einem abgelegten Schläger festmachen.
  • Nun spielt man aus einer gewohnten Distanz den ersten Ball über die Minimum-Linie.
  • Der folgende Ball muss den ersten Ball überholen, darf aber nicht das Maximum überschreiten.
  • Der dritte Ball muss somit den zweiten Ball überholen und darf ebenfalls nicht das Maximum überschreiten.

Wenn der ganze Spaß geklappt hat, erhöht man die Distanz um ca 1 Meter.

Sollte ein Ball danebengehen, fängt man die gleiche Distanz komplett von vorne an, bis es klappt.

 

Klingt einfach, kann einen aber in den Wahnsinn treiben ;)

Wir haben damit schnell gute Ergebnisse erzielt und 

Categories: Golf Tags:

Grinds my Gears!

July 31st, 2018 No comments

 

…manche tun aber auch echt nichts dafür, um das Klischee des tiefarroganten Consolenhelden abzubauen…

Wenn ich auf ner frisch deployten Testbox – fucking noch eins – irgendwas mit ROOT ausführen will, dann ist das meine Entscheidung und da will ich nicht von so nem Typen vollgelabert werden, der die aktuell vorherrschenden Situation nicht kennt, aber seine Welt für die einzig Richtige hält…

 

 

Frei nach Terry Lambert:

“It is not UNIX’s job to stop you from shooting your foot. If you so choose to do so, then it is UNIX’s job to deliver Mr. Bullet to Mr Foot in the most efficient way it knows.”

Linux CPU Load

May 29th, 2018 No comments

Die Load eines Linux Systems zeigt die Auslastung einer CPU an.

Die drei Werte der “load averange” sind Durchschnittswerte auf eine, fünf und zehn Minuten. Somit kann die echte Last des Systems auf einen Blick erkannt werden, da der aktuelle Wert allein nicht wirklich aussagekräftig ist und starken Schwankungen unterliegt.

Wenn wir ein Single-Core System betrachten, dann zeigt sich eine Load wie folgt:

Wie man sieht ist ein zur Hälfte ausgelasteter Core mit 0,5 angezeigt. Eine Load von 1 ist immer noch ein Zustand von “OK”, da dies bedeutet, dass das was reinkommt auch direkt bearbeitet werden kann und die CPU mit einer 100%igen Auslastung fährt, also nahezu im Idealzustand der nutzbaren Performance ist.

Eine Load von über 1 zeigt in einem Single-Core System, dass es zu einem Rückstau in der Verarbeitung kommt. Je nach Applikation kann das kritisch sein, oder auch nicht.

Wenn wir es mit einem Multicore System zu tun haben, und die Applikation alle Cores nutzt, verteilt sich die Load auf die entsprechenden Cores und “senkt” die Gesamtauslastung. Bedeutet: Ein Single-Core System mit 100% Auslastung, also einer Load von 1, wäre in einem Dual-Core System mit einer Load von 0,5 gelistet.

 

Zusammenfassend gilt:

  • Load1 -> OK 
  • Load über 1 -> kann OK sein, hier kommt es dann auf Erfahrungswerte des Admins an. 

 

Dein Dual-Core System mit einer dauerhaften Load von 5 kann also weiterhin sauber laufen, aber in Gesamtsicht langsamer oder träger sein. Hier kommt es dann auf die Applikation an, ob die Auswirkungen sichtbar werden oder nicht.  Eine DB, die auf einem Dual-Core System mit Load 5 läuft wird ehr als träge oder “langsam” wahrgenommen als ein http- oder Fileserver. Load ist also ein typischer Wert, der zur Interpretation viel auf den Erfahrungswerten der Admins beruht.

Generell sollte man beim Monitoring von Load-Werten auf Zeitspannen achten. Einzelne Peaks in der Load können immer auftreten und sind zu vernachlässigen – dauerhafte Loads über den Zeitraum von 5, 10 oder 15 Minuten geben deutlich mehr Hinweise ab wann vom Admin einzuschreiten ist.

Categories: FreeBSD, Linux / Unix / foo Tags:

AIX 7.2 Etherchannel Bug

September 21st, 2017 No comments

Ab dem Oslevel AIX 7.2 kann es dazu kommen, dass ein Etherchannel, dem ein Device wegbricht, sich nie mehr recovern kann!

 

Hierfür gibt es einen iFix von IBM, der leider einen Haken hat…

 

klick mich oder das Bild

Leider kommt das epkg.Z File als *.tgz an, was dem ungeübten Admin eine Entpackungsorgie und ziemlich viel Frust beschehrt…

 

 

Einfach logikbefreit von *.tgz auf *.Z umbenennen und schon läuft die Sache mit

emgr -e   IV97588s2a.170714.72TL01SP02.epkg.Z

 

Backgroundinfo:

 

**************************************************************
* ERROR DESCRIPTION:
* In recent Service Packs, for etherchannel devices in
* IEEE802.3ad mode (LACP mode), if a link port goes down or is
* disconnected, after it comes back etherchannel may never be
* able to renegotiate LACP on that port again.
*
* There is a discrepancy in the protocol used between the
* server and switch that prevents the port from being
* re-aggregated.
*
* If this issue occurs, it can be resolved temporarily by
* reconfiguring LACP mode on the etherchannel adapter. This
* will allow LACP to be renegotiated on the port for now,
* though the issue could reoccur later if the fix is still not
* applied.

Categories: IBM, Linux / Unix / foo Tags:

LUNz Devices löschen

June 29th, 2017 No comments

 

I see LUNZ devices when the AIX servers are zoned to the disk array for the first time.  Once the real LUNs are allocated from the disk array we delete those LUNZ devices and run cfgmgr/powermt config to discover the LUNs.  Some times the LUNZ’s disappear and some times they stick around.

 

Der bis jetzt beste Weg die Dinger loszuwerden ist sie über einen crontab-Eintrag immer wieder suchen und löshen zu lassen, da es Installationen gibt, die dir nach jedem Boot und auch nach jedem cfgmgr die Dinger wieder auf den Hals hetzen…

 

lsdev -Cc disk | grep -i LUNZ| awk ‘{print $1}’ | xargs -i rmdev -Rdl {}

 

Diesen Eintrag lasse ich alle 12h laufen und bekomme so ein recht sauberes System was die LUNZ Devices angeht.

 

Categories: IBM, Linux / Unix / foo Tags:

UNIX PARTY

June 15th, 2017 1 comment

Also denkt dran!

Parteyyyyy ;)

 

Categories: Uncategorized Tags:

AIX errpt Timestamp lesen

June 14th, 2017 No comments

Timestamp lesen:

0614024317 –> 06=Monat 14=Tag 02=Stunde 43=Minute 17=Jahr

 

 

Categories: IBM, Linux / Unix / foo Tags:

HMC Update 8.8.6.0 und das missing bzImage

February 10th, 2017 No comments

 

IBM hat wohl einen kleinen Bug, was die Images des Updates angeht. Nimmt man die regulären Files aus dem Netinstall Filepack, wird beim Upload auf die HMC ein fehlendens bzImage angemerkt. Das lässt sich leider nicht umgehen, weil ein Kernel nunmal notwendig ist ;) 

Die im Netinstall Update vorliegenden img2a & img3a Dateien funktionieren wohl nicht mit dem Updater der HMC.

Nimmt man allerdings die gleichen beiden img2a & img3a Files aus dem Recoveryimage unter HMC_Recovery_V8R860_1.iso/isolinux/ funktioniert der Install einwandfrei. Checksumwerte bleiben gleich, somit müssen wirklich nur die zwei Files ausgetauscht werden.

Die benötigten Pakete liegen dann auf einem per ssh erreichbaren System:

 

  • img2a (aus dem Recovery Iso)
  • img3a (aus dem Recovery Iso)
  • base.img
  • disk1.img
  • hmcnetworkfiles.sum

 

Auf der HMC sollten die „Upgradedata“ gesichert werden:

Auf Platte und USB Stick:

saveupgdata -r diskusb

Nur auf Platte:

saveupgdata -r disk

Import der Upgradefiles auf die HMC mit: 

FTP

getupgfiles -h <FTP server> -u <user id> –passwd <pwd> -d <directory> 

 

SFTP

getupgfiles -r sftp –h <system>  -u <username> -d /export/update/v8860/


Nachdem die Files kopiert wurden wird das Upgrade ausgeführt: 

chhmc -c altdiskboot -s enable –mode upgrade 

Da wir mit dem oberen Command das Upgrade in die Bootpartition geschrieben haben, wird der Reboot nun einige Zeit dauern, da dann auch gleich das Update mit anläuft.

 

Reboot

 

hmcshutdown -r -t now 

 

Dauer ca 20min

 

Categories: GrindsMyGears, IBM, Linux / Unix / foo Tags:

simple, but well working .kshrc

January 19th, 2017 No comments

 

Ist noch in Arbeit… wird gelegentlich geupdated =) 

# Variables
HISTFILE=${HOME}/.sh_hist/.sh_hist.${TTY##*/}
HISTSIZE=1024
EXTENDED_HISTORY=ON
PS1=’${PWD} $’
if id >/dev/null 2>&1 ; then
PS1=’${VIOS}:${PWD} #’
else
PS1=’${LOGNAME}@${PWD} $’
fi

export PS1

# Allow arrow key editing
set -o emacs
alias __A=’^P’
alias __B=’^N’
alias __C=’^F’
alias __D=’^B’
alias __H=’^A’
alias __P=’^D’

# Disallow Ctrl-D logout
set -o ignoreeof

Categories: IBM, Linux / Unix / foo Tags:

HMC Supportdaten ziehen

January 18th, 2017 No comments

Head-IBM-HMC

 

HMC supportdaten werden in einem pedbg zusammengefasst.

Da die shell der HMC etwas restricted ist muss das über den hscpe User erfolgen.

 

Prüfe zuerst ob der User vorhanden ist:

lshmcuser | grep hscpe

 

Sollte dies nicht der Fall sein, legen wir ihn an:

mkhmcusr -u hscpe -a hmcpe -d “HMC PE User”

 

Danach kommt eine Passwortabfrage und jetzt können wir als hscroot per ssh auf den User zugreifen:

ssh hscpe@localhost

 

Der normale Aufruf ist:

$ pedbg -c -q 4

Collecting the network information.
Collecting Kerberos information.
Collecting LDAP information.
Collecting user information.
Collecting NTP information.
Collecting certificate information.

Collecting base HMC logs

Dumping the object repository

 

Was bedeuten diese Schalter?

-c COLLECT

-q QUIET

4 “LEVEL”

1 = Netzwerkinfos
2 = Netzwerkinfos +  Standardlogs
3 = Netzwerkinfos + Standardlogs  + erweiterte Logs
4 = Netzwerkinfos + Standardlogs  + erweiterte Logs + Archive
5 = Sammelt nur Files aus /home/hscpe/ibmsupt directory
9 = Dialog um gesammelte Daten auf einen lokalen USB Stick zu schreiben

 

HINT:

Es hat sich rausgestellt, dass es geschickt ist, den Dump nach /tmp zu kopieren, weil man da als hscroot ganz gut per scp rankommt.

$ cp /dump/<pedbg_filename.zip> /tmp/<PMR#.pedbg_filename.zip>

Categories: IBM, Linux / Unix / foo Tags: