Glorf.it

Glorf IT

Bedenkliches aus dem IT-Alltag

27. Juni 2007 um 20:29

Und das alles nur wegen ein paar Querschlägern…

Ich sah heute bei Tobbi ein weiteres Beispiel dafür, dass jeder einzelne Quertreiber etwas Schönes und Gutes ein wenig blöder machen kann…

Bislang wurde die Domäne wikipedia.de auf den deutschsprachigen Teil der Wikipedia umgeleitet. Neuerdings ist die Seite nur noch eine Suchmaschine für die Wikipedia. Ich bin ziemlich sicher, dass der Grund darin liegt, dass Einzelne gegen wikipedia.de klagten, weil in der Wikipedia irgendwelche Namen genannt wurden. Einmal war es der Name eines berühmten inzwischen verstorbenen Hackers, ein anderes Mal ein Komiker mit eingeschränktem Repertoir. Daher ist das aus Sicht der Site-Betreiber eine vernünftige Änderung, aber für uns Anwender einfach blöd.

In unserer Firma gibt es auch immer rigidere Vorschriften wie wir uns unseren externen Kollegen gegenüber verhalten sollen. Sie dürfen bspw. nicht mehr an der Weihnachtsfeier teilnehmen, weil ein Externer mal auf Festanstellung geklagt hat und als Begründung nannte, dass er wie ein normaler Mitarbeiter behandelt worden sei, ja sogar bei der Weihnachtsfeier dabei gewesen sei. Das gilt natürlich auch für andere offizielle Feierlichkeiten. Aus Sicht der Firma ist die strikte Abgrenzung deswegen eine notwendige Maßnahme, aber für das miteinander Arbeiten einfach blöd.

26. Juni 2007 um 23:57

Keine Ahnung haben, aber es nicht merken

Mein Kollege Diethard machte mich heute auf den Artikel "Unskilled and unware of it" aufmerksam. Er ist sehr interessant, aber leider etwas länglich zu lesen. Die statistischen Teile habe ich ausgelassen… ;-)

An einer Stelle schreiben die Autoren:

Thus far, we have shown that people who lack the knowledge or
wisdom to perform well are often unaware of this fact. We attribute
this lack of awareness to a deficit in metacognitive skill.
That is, the same incompetence that leads them to make wrong
choices also deprives them of the savvy necessary to recognize
competence, be it their own or anyone else's.

Da fallen mir spontan zwei Dinge auf:

Erstens sind mir schon Leute begegnet, die sich tatsächlich für recht schlau hielten, die ich aber anders einschätzte. Aber natürlich kann man ihnen das so nicht sagen… ;-)

Zweitens muss ich mal kritisch hinterfragen, ob meine Einschätzung von mir selber der Realität entspricht. Aber wie kann man das anstellen? Soll ich andere fragen: "Hey, sag mal. Bin ich eigentlich ziemlich blöd, obwohl ich mich für halbwegs normal halte?" Das möchte ich ehrlich gesagt auch nicht machen…

25. Juni 2007 um 20:54

SQL-Server-2005: immer mit Named-Pipes

Mein Kollegen Vladimir entdeckte, dass man den SQL-Server-2005 nicht mehr so konfigurieren kann, dass er nur über Shared-Memory erreichbar ist.
Seit SQL-Slammer konfigurieren wir die an Arbeitspläzen installierten MSDEs so, dass sie nicht über das Netz erreichbar sind. Das wird auch von immer empfohlen, wenn man irgendwelche Sicherheitstipps liest.
Ist ja logisch, damit bietet der SQL-Server erheblich weniger Angriffsfläche.

Mit dem SQL-Server-2000 entfernt man einfach alle Protokolle "Server Network Utility" für die jeweilige Instanz. Dann kann man immer noch mittels Shared-Memory auf den lokalen SQL-Server zugreifen.

Der SQL-Server-2005 unterstützt das Shared-Memory-Protokoll aber nicht mehr. Im "SQL Server Configuration Manager" sieht man zwar noch das Protokoll "Shared Memory", aber das stimmt nicht. Das kann man auch ganz gut im Process-Explorer sehen, wenn man sich die beiden Prozesse ansieht. Es ist mit einem kleinen Tests aber auch leicht nachvollziehbar.
Dazu muss man einfach in dem Tool am SQL-Server-2005 alle Protokolle deaktivieren und nur Shared Memory übrig lassen. Danach muss man den Dienst neu starten.

Dann sieht man schon im Errorlog des SQL-Servers:
Server local connection provider is ready to accept connection on [ \\.\pipe\SQLLocal\SQLEXPRESS ].
Server local connection provider is ready to accept connection on [ \\.\pipe\MSSQL$SQLEXPRESS\sql\query ].

Wenn man sich nun explizit über Shared-Memory (LPC) zum SQL-Server verbindet, dann klappt der Zugriff:

>SQLCMD -S lpc:.\MyExpress -E
1> SELECT net_transport FROM sys.dm_exec_connections WHERE session_id = @@SPID
2> go
net_transport
—————————————-
Shared memory

(1 Zeilen betroffen)
1> exit

Der Zugriff verwendet aber nicht Shared-Memory, sondern eine spezielle Named-Pipe (obwohl Named-Pipes deaktiviert wurde):

>SQLCMD -S np:\\.\pipe\SQLLocal\MyExpress -E
1> SELECT net_transport FROM sys.dm_exec_connections WHERE session_id = @@SPID
2> go
net_transport
—————————————-
Shared memory

(1 Zeilen betroffen)
1> exit

Weil die alten Client, die bspw. ODBC nutzen, das "neue" Shared-Memory nicht kennen, werden sie auf etwas umgelenkt, dass sie kennen: die "bisherigen" Named-Pipes. Deswegen ist jetzt jeder SQL-Server immer auch über die Standard-Pipe erreichbar, selbst wenn das Protokoll Named-Pipes deaktiviert ist:

>SQLCMD -S np:\\.\pipe\MSSQL$MyExpress\sql\query -E
1> SELECT net_transport FROM sys.dm_exec_connections WHERE session_id = @@SPID
2> go
net_transport
—————————————-
Named pipe

(1 Zeilen betroffen)
1> exit

Man kann jetzt darüber streiten, ob das ein Sicherheitsproblem ist, aber es ist kein Bug, sondern ein beabsichtigtes Feature um abwärtskompatibel zu sein. Es ist auch kein Geheimnis, ich fand mehrere Artikel im Internet, die das bestätigen, wenn auch das Problem nicht als solches beschreiben (erkennen?), z.B. bei SQL-Protocols.

Der Zugriff über eine Remote-Pipe funktioniert hingegen nicht:

>SQLCMD -S np:\\MyPC\pipe\MSSQL$MyExpress\sql\query -E
HResult 0xE9, Level 16, State 1
Named Pipes Provider: Kein Prozess ist am anderen Ende der Pipe.

Sqlcmd: Error: Microsoft SQL Native Client : Communication link failure.
Sqlcmd: Error: Microsoft SQL Native Client : An error has occurred while
establishing a connection to the server. When connecting to SQL Server
2005, this failure may be caused by the fact that under the default settings
SQL Server does not allow remote connections..

Das geht nur, wenn man auch Named-Pipes erlaubt.

25. Juni 2007 um 20:42

Was muss im Impressum stehen?

In dem Artikel "5 Fragen zu Impressumspflichten in Weblogs" auf Telemedicus werden gängige Fragen beantwortet.

Auch den Link auf den Artikel zu Datenschutzerklärungen im Law-Blog finde ich gut.

gefunden im LawBlog
24. Juni 2007 um 15:04

Gibs ihm, Joe!

Ich bekomme dienstlich recht viele Anfragen per Mail, wie man mit SQL dies oder jenes am besten macht. Die BEschreibung ist meistens zweitdeutig, selten wird die Tabellenstruktur mitgeschickt und nach Daten muss ich förmlich betteln. dabei ist es mit den SQL-Server-Werkzeugen so einfach die CREATE-TABLE-Statements zu bekommen, dass es schon fast lächerlich ist.

Als ich die Antwort vom großen "Joe Celko" auf eine der typischen Anfragen um Hilfe las, stellte ich mir vor, wie ganz viele um ihn herum stehen und rufen: Gibs ihm, Joe!

Why do you spit on us and want us to do your homework/job for you?

Please post DDL, so that people do not have to guess what the keys, constraints, Declarative Referential Integrity, data types, etc. in your schema are. Sample data is also a good idea, along with clear specifications. It is very hard to debug code when you do not let us see it.

Hier steht der die komplette Anfrage: Joe Celko The SQL Apprentice: Updating based on values of two records

Leider fanden einige andere Diskussionsteilnehmer die Bemerkung von Joe nicht gut. Wahrscheinlich werden ihnen nicht so oft so Wischi-Waschi-Fragen gestellt…

24. Juni 2007 um 14:56

SQL-Server-2005: OVER() mit Aggregatfunktionen

Im Artikel "SQL Sever 2005: Using OVER() with Aggregate Functions" wird auf SQLTeam.com ein nettes Feature beschrieben, das mir bisher entging:

Man kann (ohne Angabe von Group-By) eine Aggregatfunktion nur auf gruppen berechnen lassen. "Früher" war dazu eine Subquery notwendig oder etwas performanter ein Join mit einer Derived-Table. Jetzt kann das sehr elegant in einem Schupps erledigen.

So steht es in einem Bespiel meiner TSQL-Schulung (Datenbank "Northwind", die mag ich immer noch recht gerne):

select P.ProductName,
P.UnitPrice,
P.CategoryID,
(select avg(Pc.UnitPrice)
from "Products" as Pc
where Pc.CategoryID=P.CategoryID)
as "durchschn. Preis der Produktklasse"
from "Products" as P

So könnte es zukünftig aussehen:

select P.ProductName,
P.UnitPrice,
P.CategoryID,
avg(P.UnitPrice) over (Partition by P.CategoryID)
as "durchschn. Preis der Produktklasse"
from "Products" as P

Allerdings bin ich mit dem Zugriffsplan der zweiten Variante noch nicht wirklich zufrieden. Durch die Subquery hat man einen Nested-Loop-Join, durch das Partition-By einen Sort. Was "besser" ist, kann man so pauschal nicht sagen, möglicherweise wäre ein Clustered-Index auf die Spalten in dem Partion-By ideal.

gefunden im SQL Server FAQ Blog

24. Juni 2007 um 14:36

PUSH und POP

Am Donnerstag meldete mit mein dienstlicher Virenscanner, ich habe gar schreckliche "Trojaner" auf dem Rechner. Nach einigen Umständen schaute ich die beiden CMD-Dateien mal an. Sie waren von einer PASS-Konferenz und richteten die Samples für eine der Vorträge ein bzw. entfernten sie wieder. Die Dateien sind ziemlich klein und übersichtlich. Die einzigen Befehle, die ich noch nicht kannte waren
waren PUSHD und POPD. Die enthielten bestimmt kein trojanisches Pferd – ich bin mal gespannt wie lange es dauert, bis unsere obersten Virenschützer zu dem gleichen Ergebnis kommen… ;-)

Mit dem Befehl "pushd" wechselt der Verzeichnis-Kontext wie angegeben. Das bisherige Verzeichnis wird aber gespeichert.

d:\test>pushd c:\temp

Jetzt kann man in dem neuen Verzeichnis arbeiten und am Ende des Batches wieder in das bisherige Verzeichnis wechseln. Das finde ich richtig schick:

C:\temp>popd

Hier werden ein paar weitere Details beschrieben: "PUSHD Windows 98 Windows 98, Windows XP, Windows 2003 .exe, .com .vbs Commands: Change the current directory/folder and store the previous folder/path"

Da man bei uns sofort aus dem System gekickt wird, wenn eine Prüfung einen Virus findet und beim nächsten Anmelden gleich eine Virenprüfung startet, kostete es mich einige Neuanmeldungen bis ich die "bösen" Batches in ein passwortgeschützes ZIP gesteckt hatte und in Ruhe arbeiten konnte. Bei ersten Anlauf hatte ich den Virenscan nur "angehalten", aber unser System scheint nach einiger Zeit auf einen Timeout zu laufen und einen dann rauszuwerfen… Da hatte ich die Dateien noch, weil ich auf eine schnelle Reaktion der Virenschützer hoffte. Später fand er sie noch mal im Recycler. Beim dritten Mal im Temp, weil ich Blödel das Zip noch mal anschaute, und der Zipper das aus irgendwelchen Gründen nicht gleich wegräumte. Erst nach dem vierten Scan, war dann Ruhe… :-)

19. Juni 2007 um 19:57

Seadragon: Fotos verlinken und verbinden

Bis gerade eben hatte ich noch keine Ahnung, was "Seadragon" ist, aber nachdem ich dieses wirklich interessante Video bei TED sah, bin ich schwer beeindruckt. Auf diese Weise werden wir in ein paar Jahren alle Bilder bei Flickr &Co vernetzen und einfach unglaubliche Dinge damit erreichen. Wenn man das jetzt noch mit Google-Earth verbindet, dann kann man im Prinzip jeden Bildband vergessen!

Hier steht mehr zu der Software: http://labs.live.com/Seadragon.aspx

gefunden im WiMaBlog
19. Juni 2007 um 19:23

SQL-Server: Paging von Ergebnismengen

Heute wollte ich einen Trick vorstellen, wie man es schafft eine Ergebnismenge seitenweise zu lesen. Das ist sinnvoll, wenn man in der Anwendung immer nur eine "Seite" voller Datensätze anzeigt. Es wäre in dem Fall Quatsch Tausende von Sätzen zu lesen und am Client dann doch nur eine oder zwei Seiten anzuzeigen.

Leider wird das derzeit schlaueste Verfahren im Artikel "Server Side Paging using SQL Server 2005" auf SQLTeam.com so schön beschrieben, dass ich mir meine Version an dieser Stelle schenke. Allerdings möchte ich ein paar persönliche Bemerkungen ergänzen:

  • Ich würde generell zu einem Index auf dem Sortierkriterium raten, am besten sollte man auf dem Clustered-Index "pagen". Für meinen untigen Trick ist das ein Muss.
  • Es ist wichtig, dass man die Menge der Datensätze mittels der Where-Klause auf die wirklich benötigten Sätze einschränkt, sonst beschäftigt man den SQL-Server unnötig. Aber ich gehe davon aus, dass Ihr das schon macht.
  • Wenn man sehr, sehr viele Datensätze im Ergebnis hat über das man "pagen" will, dann würde ich dazu raten, die Query so abzuspecken, dass nur der Primärschlüssel in der Common-Table-Expression ist. Dann kann die "Zählung" auf dem Sortierkriterium (und der Where-Klausel) mittels "Index Covering" durchgeführt werden. Das Ergebnis wird dann wieder mit der originalen Tabelle verjoint.

Frohes "pagen"…

16. Juni 2007 um 15:57

Einfach gediegen: Keyboards von Hacoa

Wenn man auf gediegenes Ambiente Wert legt, dann sollte man nach Fernost schauen: Hier gibt es von der Firma Hacoa PC-Zubehör aus Holz: Tastaturen, USB-Sticks, Card-Reader.

Hocao

Von der "Computex 2007" liefert AVING ein paar nette Bilder:


Den Preis will ich lieber gar nicht wissen…

Ähnliches Thema:

gefunden bei Tobbi
16. Juni 2007 um 13:31

SQL-Server-2005: Logon-Trigger

Wie ich heute festgestellt habe, wurde mit SP2 zum SQL-Server-2005 Logon-Trigger eingeführt. Sie werden gefeuert bevor die Benutzersitzung erstellt wird. Hier kann man dann Dinge protokollieren. Man kann die Anmeldung aber auch unter fachlichen Gesichtspunkten untersuchen und ggf. ablehnen… :-P

Damit sind solche handgestrickten Lösungen, die auf dem ungeliebten Polling aufbauen, unnötig geworden.

Eigentlich wollte ich eine kleine Beschreibung dazu verfassen, aber weil das schon so schön im " SQL Server FAQ Blog", den ich übrigens auch erst heute entdeckte, beschrieben ist, kann ich einfach darauf verweisen… ;-)

Gugst Du hier: "Trigger für Anmelde (Logon) Ereignisse"

Hinweis, falls einer meiner Kollegen auf den "running Gag" kommt: Man kann damit nicht generelle Verbindungsoptionen setzen.

16. Juni 2007 um 13:15

SQL-Server-2005: Kompatibilität mit "Common-Criteria"

Eher zufällig habe ich heute die "Common-Criteria-Kompatibilität" entdeckt. Das ist eine Möglichkeit die Sicherheit des SQL-Servers durch ein paar zusätzlich Details zu erhöhen. Sie erscheinen mir generell sinnvoll:

  • "Residual Information Protection" (mit der makabren Abkürzung "RIP"): Muss der SQL-Server Hauptspeicher abgeben, dann wird er mit Dummy-Daten überschrieben und erst dann freigegeben.
  • Der SQL-Server führt Anmeldestatistiken. Damit kann man "ungewöhnliche" Anmeldemuster entdecken und analysieren.
  • Ein DENY auf eine Tabelle, kann nicht durch ein GRANT auf Spalten dieser Tabelle umgangen werden.

Diese "erweiterte" Option ist laut Doku nur in den Editionen Enterprise, Evaluation und Developer des SQL-Servers-2005 mit Service Pack 2 verfügbar. Leider ist das wohl mit heißer Nadel eingeführt worden, anders kann ich diesen Hinweis nicht erklären:

Zusätzlich zur Aktivierung der Option Common Criteria-Kompatibilität aktiviert müssen Sie ein Skript downloaden und ausführen, mit dem die Konfiguration von SQL Server 2005 SP2 für die Kompatibilität mit der Common Criteria-Auswertungssicherungsstufe 4 (EAL4+) ausgeführt wird. Sie können dieses Skript von der Website Microsoft SQL Server Common Criteria (in Englisch) downloaden.

Weitere Informationen dazu: