SAPoscol und shared memory

SAP schlägt mir grade vor wegen eines (vermeintlichen) shared memory problems im saposcol das system zu rebooten. WTF?? Kann man das nicht anders frei kriegen? Für mich klingt das eher danach, dass SAP (=stark alkoholisierte programmierer) die Handles auf ihr shared memory nicht richtig zumachen wenn saposcoll restarted wird. Vermutlich ist deshalb auch nach restart des saposcol das memory nicht freigeben.

Update:

Ach ja, nachdem ich mich geweigert habe das System x mal zu rebooten und den verblödeten recommendations zu folgen hat sich dann rausgestellt, dass dem Parameter exe/saposcol das ".exe" am Ende fehlte. Also tatsächlich nix mit shared memory wie SAP die ganze zeit angenommen hatte...

Ubuntu Karmic und HP workstation

Nachdem wir endlich der Telekom den Rücken gekehrt haben und nun bei einem schnellen Kabel Anbieter sind, habe ich mal die Gelegenheit genutzt und Ubuntu auf 9.10 upgegraded.

Danach ging aus irgendwelchen Gründen das automatische power off beim shutdown nicht mehr. Der Rechner ist eine xw4100 HP workstation, vermutlich liegt es am neuen Kernel.

Man kann aber mit dem Kernelparameter

# defoptions=vga=794 apm=power_off in der /boot/grub/menu.lst (grub 1.5) den Kernel zum ausschalten auf die alte Methode zwingen.

Danach noch kurz "update-grub" ausführen und in der /etc/modules folgende Zeile einfügen:

apm=power_off=1

Einmal rebooten, fertig.

Deusch-Schwäbisch-Deutch

Super Dictionary :)  http://www.happes.net/schwaebisch/default.asp?v=g

 

Verteilung der Dateien im Filesystem - wie groß sind meine Dateien?

Wenn man mal eine Analyse über Dateigrößen eines bestimmten Verzeichnisses bekommen will kann man den Unixbefehl find verwenden:

find c:\foo -type f -printf "Size:\t%s\tName:\t%p\r\n" > output.txt

Find ist Bestandteil der Windows Gnutools, die IMO jeder der Windows Server betreibt installiert haben sollte, genauso wie die sysinternals suite :).

output.txt sieht dann folgendermaßen aus:

Size: 746 Name: c:\foo\1.txt
Size: 603 Name: c:\foo\bar\2.txt
Size: 2077 Name: c:\foo\bar\3.txt

Den output kann man leicht in Excel analysieren (Pivotchart!), mit Pipes an andere programme weiterleiten (grep z.B.) oder mit eigenen Scripten (Perl bietet sich an) weiterverarbeiten. Beispielsweise kann man so eine Größenverteilung der Dateien zu ermitteln (Wieviel Prozent der Dateien sind eigentlich kleiner als x Byte, Wieviel Prozent davon sind Textfiles etc).

Windirstat, DF, DU, LS oder DIR /s können das alles nicht leisten, weil der output entweder die Verzeichnisse mit listet, Summen für Unterverzeichnisse bildet oder einfach für die weitere Verarbeitung ungeeignet ist.

XSS Cheat Sheet

Für alle die ihren XSS Payload nicht selbst schreiben wollen oder
können, hier gibt es schon einige Standardtemplates:

http://ha.ckers.org/xss.html

DataProtector und Backward Compatibility beim SQL Server 2008

Ich lese hier grade interessantes zu SQL Server 2008 und Data Protector:

 

Anscheinend benötigt man das SQL 2005 Backward Compatibility Pack damit man mit Data Protector Backups auf SQL Server 2008 machen kann. Offensichtlich geht noch nichtmal der connection check wenn das nicht der Fall ist.

 

http://headadmin.net/?p=225

http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1270026292340+28353475&threadId=1189523

 

 

 

 

NIC Speed VMWare ESX

Interessante Info zu Speed und Autonegotiation bei Intel Pro 1000 MT:

Wir haben hier mehrere VMWare Guests (die auf ESX laufen). Alle haben die virtuelle Netzwerkkarte „Intel Pro 1000 MT“, die eigentlich ja 1000 Mbit unterstützt. Auf der NIC kann allerdings sowohl mit dem Microsoft Treiber als auch mit dem Intel Treiber nur maximal 100 Mbit Full Duplex einstellen.(Der Virtuelle Switch, ESX Host NIC‘s und der Cisco Routingswitch sind natürlich allesamt auf 1 Gbit FDX eingestellt, Autonegotiate ist aus).

Trotzdem kann man auf den virtuellen Karten maximal 100MBs/Full Duplex einstellen. Die 1000MBs/Fdx einstellung die wir von NICs normalerweise gewohnt sind, gibt es nicht. Die 1000 MBs erreicht man nur, wenn man die Speed auf „Auto“ stellt was wir auf echter Hardware ungern machen, weil es immer wieder zu Problemen mit Verbindungsabbrüchen kam.

Jetzt sind diese Karten ja bekannterweise keine echte Hardware, sondern von ESX vollständig virtualisiert. In wirklichkeit ist es total egal ist, welche Speed in den VMWare Guests eingestellt ist, der ESX Host bestimmt die Geschwindigkeit. Wenn dort 1000 Gbit eingestellt sind werden die auch benutzt.

Wir haben es gestestet und kamen auf 317 MB/min bei 100 Mbit und 312 MB/Min bei Auto (1000 Mbit). Die Differenz von 5 MB ist zu vernachlässigen, die müsste grob um den Faktor 10 unterschiedlich sein.

Grund (laut diesen Threads) ist dass die Speed auf Layer 2 abläuft (Ethernet), die allerdings in der VM keine Rolle spielt weil die Kommunikation dort nur über den TCP/IP Stack abläuft (layer 3+4). Die Argumentation steht aber auf wackeligen Füßen wie ich finde, weil der Treiber die Einstellung zumindest an’s Layer 2 kommunizert, da es ein „echter“ Treiber ist und nicht von VMWare kommt. Dass die virtuelle Hardware die diese Einstellung dann ignoriert weiß der Treiber nicht – allerdings läuft die Kommunikation nicht nur auf Layer 3 + 4, dazu wären spezielle von VMWare implementierte TCP/IP stacks (und VMWare Treiber) notwendig. IMO gibt es durchaus einen Layer2, der die Kommunkiation übernimmt, auch wenn dieser durch ESX virtualisiert ist.

Wichtig ist nur: Dem Guest kann’s egal sein, der ESX Host bestimmt die Geschwindigkeit, egal ob 10, 100 oder 1000 MBit auf dem Guest eingestellt sind :)