Microsoft udostępnił SP2 do systemu operacyjnego Windows Server 2003, który może być zainstalowany także na systemie Windows XP Professional x64 Edition. Service Pack zawiera wszystkie wcześniej opublikowane hotfixy i wprowadza szereg zmian mających usprawnić zarządzanie serwerem, podnieść wydajność sieci (Scalable Networking Pack), czy np. ułatwić diagnostykę domeny (Domain Controller Diagnostics). SP2 najlepiej instalować na systemie z SP1 - pozwoli to uniknąć szeregu potencjalnych problemów.
Więcej informacji:
Technet: Windows Server 2003 Service Pack 2
Technet: Top 10 Reasons to Install Windows Server 2003 SP2
Resultset to zbiór elementów - krotek (realizowanych w postaci rekordów), z których wszystkie posiadają określone cechy - atrybuty (zmaterializowane w postaci wartości kolumn). Jest to założenie formalne, tzn. że nie wszystkie rekordy muszą dysponować merytorycznie doniosłą informacją zawartą w danej kolumnie (sytuacja NULLa). W rzeczywistości zachodzi czasem potrzeba, aby do zbioru rekordów włączyć wiersze o specjalnym znaczeniu (np. takie z pustymi wartościami w kolumnach, dzielące wizualnie zbiór rekordów na odpowiednie grupy). Oczywiście w sensie formalnym nie będą się one niczym różniły od pozostałych rekordów (tożsamość kolumn), jednak ich funkcja będzie szczególna (formatująca, separacyjna). W takiej sytuacji wymaga się także odpowiedniego uporządkowania całego zbioru, aby nadać mu określoną wizualną postać.
Załóżmy, że posiadamy tabelę Osoby:
CREATE TABLE Osoby
(
id_osoby int IDENTITY(1,1) PRIMARY KEY,
imie nvarchar(50) NOT NULL,
nazwisko nvarchar(50) NOT NULL,
plec char(1) NOT NULL,
id_pary int NULL
);
Osoby z równymi wartościami w kolumnie id_pary stanowią parę (nie chcę być posądzony o homofobię, ale w przykładzie dopuszczam tylko pary heteroseksualne w liczebności 2 - jak przystało na parę :) ).
Celem jest wyświetlenie par na takiej zasadzie, że każda para reprezentowana będzie przez 3 rekordy: pierwszy - kobieta, drugi - mężczyzna, trzeci - rekord z pustymi polami dla oddzielenia od kolejnej pary. Oczywiście pary można też pokazać w orientacji horyzontalnej - na zasadzie joina. W sytuacji rekordów z dużą ilością kolumn (np. dane teleadresowe) jeden rekord pod drugim może być jednak zasadniczo lepszym rozwiązaniem.
Napełnijmy tabelę Osoby testowymi danymi (przy okazji warto zwrócić uwagę na sposób dodawania rekordów, konstrukcja jest mało znana, a co ważne - bardzo wydajna):
INSERT Osoby (imie, nazwisko, plec, id_pary)
EXEC
('
SELECT ''Stefan'', ''Kowalski'', ''m'', 1
SELECT ''Alberto'', ''Mampuaye'', ''m'', NULL
SELECT ''Leokadia'', ''Puszczalska'', ''k'', 1
SELECT ''Krystyka'', ''Waleczna'', ''k'', 2
SELECT ''Eryk'', ''Tajemniczy'', ''m'', 3
SELECT ''Stachu'', ''Waleczny'', ''m'', 2
SELECT ''Danuta'', ''Nuta'', ''k'', 4
SELECT ''Anna'', ''Kosmiczna'', ''k'', 3
SELECT ''Lech'', ''Barwny'', ''m'', 6
SELECT ''Hellena'', ''Kolorowa'', ''k'', 6
SELECT ''Jarek'', ''Specjalny'', ''m'', 5
SELECT ''Marianna'', ''Niekonieczna'', ''k'', 5
SELECT ''Ernest'', ''Samoobronny'', ''m'', 4
');
Rozwiązanie zadania to kwestia tzw. pionowych operacji na zbiorach (w odróżnieniu od poziomych - joinów). W naszym przypadku zastosujemy operator UNION. Potrzebujemy rekordów z kobietami mającymi parę, rekordów z mężczyznami mającymi parę i rekordów z pustymi wartościami w liczbie równej ilości par. Zapytanie wygląda następująco:
SELECT imie, nazwisko, plec, id_pary
FROM Osoby Os
WHERE plec = 'k' AND
EXISTS(
SELECT 1 FROM Osoby
WHERE id_pary = Os.id_pary AND
plec = 'm')
UNION
SELECT imie, nazwisko, plec, id_pary
FROM Osoby Os
WHERE plec = 'm' AND
EXISTS(
SELECT 1 FROM Osoby
WHERE id_pary = Os.id_pary AND
plec = 'k')
UNION ALL
SELECT '' as imie, '' as nazwisko, '' as plec, id_pary
FROM (
SELECT id_pary FROM Osoby
GROUP BY id_pary
HAVING Count(*) = 2
) sq;
Warto zwrócić uwagę na właściwość ALL drugiego operatora UNION. Należy pamiętać, że operator UNION usuwa wszystkie duplikaty z dołączanego zbioru rekordów. Aby dołączyć także powtarzające się wiersze, konieczne jest użycie opcji ALL. Jeżeli ALL nie zostałaby powyżej użyty, nie dołączylibyśmy rekordów z pustymi wartościami w liczbie równej ilości par, tylko w liczbie równej 1.
Zapytanie zwraca nam dokładnie te rekordy, których potrzebujemy do realizacji zadania. Nasz cel nie zostanie jednak osiągnięty, dopóki odpowiednio nie posortujemy wynikowego rezultatu. Sortowanie musi odbywać się dwubieżnie - po pierwsze trzeba posortować całe 3-elementowe podzbiory rekordów, po drugie - rekordy w ramach 3-elementowych podzbiorów (pierwszy rekord - kobieta itd.). Do pierwszego porządku potrzebna jest kolumna, która ma te same wartości w ramach 3-elementowego podzbioru, a jest unikalna w skali całego zbioru. Mamy szczęście, gdyż warunki te spełnia kolumna id_pary. Szczęście nie jest jednak absolutne, bo w przypadku drugiego założenia musimy zastosować sztuczną kolumnę - ordc (ordering column). W ostatecznym wyniku wyświetlimy tylko imię i nazwisko, całość logiki zawarta zostanie w podzapytaniu. Finalne zapytanie ma następującą postać:
SELECT imie, nazwisko
FROM
(
SELECT imie, nazwisko, id_pary, 1 as ordc
FROM Osoby Os
WHERE plec = 'k' AND
EXISTS(
SELECT 1 FROM Osoby
WHERE id_pary = Os.id_pary AND
plec = 'm')
UNION
SELECT imie, nazwisko, id_pary, 2 as ordc
FROM Osoby Os
WHERE plec = 'm' AND
EXISTS(
SELECT 1 FROM Osoby
WHERE id_pary = Os.id_pary AND
plec = 'k')
UNION ALL
SELECT '' as imie, '' as nazwisko, id_pary, 3 as ordc
FROM (
SELECT id_pary FROM Osoby
GROUP BY id_pary
HAVING Count(*) = 2
) sq
) subq
ORDER BY subq.id_pary, subq.ordc;
Powyższy SELECT w pełni realizuje cel zadania.
Nie trzeba wnikliwie obserwować rynku IT, żeby dojść do wniosku, że popyt na specjalistów jest dużo większy niż podaż. W efekcie od jakiegoś czasu określa się go mianem rynku pracownika, co z resztą ma miejsce także w przypadku innych dziedzin gospodarki. Płace idą w górę, dużo łatwiej uzyskać od pracodawcy różnego typu świadczenia dodatkowe (od nowej komórki czy laptopa, przez kompleksową opiekę medyczną i darmowe wczasy, po samochód, mieszkanie do dyspozycji).
Naturalnie wzrost faktycznych kosztów działalności firm szybko doprowadzi (w niektórych przypadkach już doprowadził) do wzrostu cen usług i produktów informatycznych. Nie ma jednak specjalnej obawy o to, że ze względu na poziom cen usługi i produkty przestaną się sprzedawać. Rynek IT rośnie w postępie kilkunastoprocentowym rocznie, potrzeby innych branż w zakresie informatyzacji i nowoczesnych usług teleinformatycznych są ogromne, a sytuacji nie ulegnie zmianie dopóki gospodarka nie zwolni w sposób zasadniczy.
Wyżej opisane zmiany wpływają także na proces rekrutacji. Najprościej mówiąc: dużo łatwiej dostać teraz pracę, gdyż pracodawcy musieli obniżyć wymagania, aby zwiększyć zatrudnienie w warunkach braku specjalistów. Jeżeli już o rekrutacji mowa, to proszę o kontakt osoby zainteresowane pracą na pełny etat związaną z następującymi technologiami (wystarczy zainteresowanie jedną z poniższych):
- bazy danych (preferowany Microsoft SQL Server, ale absolutnie nie jest to warunek)
- platforma .NET
- Java
- Perl
Wszelkie dodatkowe informacje podam indywidualnie. Doświadczenie w zasadzie nie jest wymagane, ale wtedy trzeba pokazać, że umie się szybko uczyć i przede wszystkim - że umie się myśleć.
Wracając do głównego wątku posta, chciałbym jeszcze pokreślić, że w mojej skromnej opinii za braki w kadrach IT wcale nie odpowiada exodus polskich pracowników do krajów UE, tylko niedostosowany do potrzeb system edukacji. Uczelnie wyższe namnażają bezrobotnych w postaci ekonomistów, prawników, historyków itp., podczas gdy zawody produkcyjne niezbędne gospodarce (inżynierowie różnych branż, osoby związane z technologią) były od dawna traktowane w sposób drugoplanowy. Efekty zaniechań są dziś widoczne bardzo wyraźnie. Dodatkowym problemem jest też fakt, że jeżeli już uczelnie kształcą inżynierów, to program nauczania jest zupełnie anachroniczny i niedostosowany do realnych potrzeb. Oczywiście teraz każda szkoła wyższa, widząc potrzeby rynkowe, będzie chciała wprowadzić kierunek ze słowem "informatyka" w nazwie, co według mnie - ze względu na poziom tego typu placówek - wcale nie przysłuży się do tego, że przybędzie odpowiednio wykształconych absolwentów.
Najlepszym dowodem na to, że sytuacja wygląda w praktyce dość nieciekawie, jest stałe odwlekanie realizacji różnych zadań z harmonogramów produkcyjnych na kolejne miesiące, a czasem - lata. Coraz częściej powoduje to z resztą frustrację klientów, którzy czują się źle traktowani. Właściwie przez to wszyscy stają się bardziej nerwowi, a to też niczemu dobremu nie służy. Ciekawi mnie tylko, czy za kilka lat system edukacji zostanie przeorientowany na kierunki techniczne, a za kilkanaście lat zabraknie prawników i humanistów. Jest to całkiem możliwe, gdyż obecna sytuacja jest właśnie efektem analogicznego zjawiska sprzed lat, gdy wszyscy chcieli być ekonomistami i prawnikami, bo akurat takich zawodowców brakowało. Skala przestawiania się edukacji na zawody techniczne będzie jednak prawdopodobnie znacznie mniejsza, gdyż osoby zainteresowane tymi dziedzinami muszą posiadać pewne predyspozycje (podobno prawa może nauczyć się każdy, a nie ma to zastosowania np. do matematyki).
Wszystkie SP2 pobrane przed 5 marca 2007 roku zawierają m.in. błąd powodujący nieprawidłowe działanie zadań czyszczenia (cleanup tasks) w pakietach Integration Services i planach utrzymania bazy (maintenance plans). Problem polega m.in. na tym, że SQL Server wykona czyszczenie wcześniej niż wynika to z harmonogramu (będzie uruchamiał cleanup task z inną częstotliwością niż zamierzona). Zalecana jest instalacja poprawki. Co ciekawe, Microsoft przemilczał informację, że hotfix (nazwany z resztą Cumulative Hotfix 3050) naprawia też kilka usług dodatkowych i silnik serwera. Skutkuje to zmianą wersji produktu z 3042 na 3050.
Więcej informacji i pobieranie:
KB933508: SQL Server 2005 SP2 issue: Cleanup tasks run at different intervals than intended
Critical Update for SQL Server 2005 Service Pack 2 (KB:933508)
Hasła są jedną z najstarszych i najbardziej popularnych metod uwierzytelniania w systemach komputerowych, ale także i w systemach nieinformatycznych. Wszelkiego typu klucze znakowe, tajne słowa, PINy itp. to często jedyne zabezpieczenie systemu przed niepowołanym dostępem. Z tego właśnie powodu przykłada się do nich duże znaczenie i zaleca się, żeby jedynym miejscem ich składowania była pamięć osób uprawnionych (a nie żółta karteczka naklejona na monitorze).
Od lat funkcjonuje pojęcie tzw. słabych haseł (weak passwords), którym określa się hasła bardzo podatne na złamanie (metodą słownikową lub brute-force). Chodzi oczywiście o krótkie łańcuchy znaków, często będących imieniem, nazwiskiem danej osoby itp. Jako przeciwieństwo haseł słabych wprowadzono termin haseł mocnych (strong passwords), czyli najlepiej takich, których... w ogóle nie da się zapamiętać i trzeba je zapisać na żółtej karteczce :) Oczywiście intencjonalnie ironizuję, ale ilość haseł, którymi bombarduje się przeciętnego użytkownika - nie mówiąc już o administratorze czy deweloperze - jest coraz większa. Stawia się także coraz większe wymagania co do jakości haseł, m.in. głosząc postulat losowości i odpowiedniej ilości znaków. Prosty przykład: jeszcze kilka lat temu spora część specjalistów była w stanie uznać prawidłowo sformułowane hasło 8-znakowe za dostatecznie mocne. Dziś w programie TrueCrypt ( pisałem o nim jakiś czas temu) spotykamy się z zaleceniem, żeby używać haseł dłuższych niż 20 znaków. Ta tendencja jest nieodwracalna, gdyż wraz z gwałtownym wzrostem mocy obliczeniowej systemów komputerowych, moc wszystkich haseł na świecie równie gwałtownie maleje.
Interesującą wielkością jest przeciętna ilości haseł przypadająca na jednego użytkownika. Zakładając, że do każdego systemu uwierzytelniającego stosować będziemy oddzielne hasło (a jest to jedyne rozsądne założenie), można szybko dojść do ciekawych wniosków. Zastanowiłem się na swoim przykładzie i policzyłem, że muszę pamiętać około 40 haseł (do kilku komputerów, kont pocztowych, serwerów w pracy, kont FTP, partycji szyfrowanych, kont bankowych i systemów innych instytucji, komórki, bloga i innych stron itd.). Warto zaznaczyć, że często nie wystarczy zapamiętanie samego hasła, gdyż konieczne jest również dysponowanie dodatkową informacją - identyfikatorem, numerem klienta (który sam w sobie jest przecież czymś w rodzaju hasła sensu largo). Jeżeli uznamy, że długość bezpiecznego hasła zaczyna się od 15 losowych znaków (małe/duże litery, cyfry i znaki niealfanumeryczne) i wykonamy następujące działanie:
40 x 15 = 600
to otrzymamy, że przeciętnie człowiek z IT powinien zapamiętać 600 znaków czegoś, czego nawet nie da się fonetycznie wymówić, a co wygląda mniej więcej tak:
suA(knAeFfroO4tADhLe2TapoIoL2eGSspU/SpagRnEi?TueMneG?laPsNd
teN@OfeVDur7WaiHudYu1OydyAeC*AsFiG?IllSwuBu^yoUaSSwu,zArAlD
muN{LuneGOe/jeLMuRas8GybiLOe|oWAoR5VoTeeEx2fIOduT(tHrHAs=th
pY9RudIefF,bUpRiYe~LoqnUlRat*GadLoe)dEdwAtuR!zUaCyfO8alFeNg
Oc9oOcAnhY?lUrSlpUm]aMnAsiblO3yANu|NuviLEj~sKgIggEo.EanAupU
sN*nOxzURa4XyLyaC(twOtOgSad/oYheKa.SlIrexI@DefStIc0SexmNiV!
pLo6aToSmaAxi#vUsiBnE^tSdUbiA8PaRe6fLdAgsU|tWiNwsP.rIiASy}S
Fae[nyLVogzI=IgiCpIp6AgopHorA"MudH0BifJVor@AlywHRut9OvafIjA
Pas(AwJaMou9FugclOZl9aBiNaFl!dObfUn!AbSfcZa{caLnOsL!NumFoas
nOb1tSnaMpY.qUoMTr@hIrrEeoP=EnrdDw0oTPilsP*VigPtsiN^leVyOoF
Problem z ilością haseł jest więc całkiem spory. Oczywiście wypracowano różne metody, by zminimalizować jego oddziaływanie. Jedni stosują w swoich hasłach część stałą dla wszystkich haseł i część zmienną - niepowtarzalną. Nie jestem jednak pewien czy jest to w wypadkowym rozrachunku opłacalne. Nie ułatwia to jakoś zasadniczo zapamiętywania, a znacznie osłabia moc hasła. Innym pomysłem również nie pozbawionym wad jest przechowywanie wszystkich haseł w zaszyfrowanym pliku i pamiętanie wyłącznie silnego hasła szyfru. Ujawnienie tego hasła ma jednak kolosalne konsekwencje, nie polecałbym więc stosowanie tego rozwiązania zbyt intensywnie. Nie polecam również zapamiętywania haseł w programach (np. przeglądarkach), choć w przypadku mniej ważnych haseł może to być akceptowalne. Najrozsądniej jest opracować we własnym zakresie pewien prywatny system tworzenia i kojarzenia haseł, gdzie poszczególne jego fragmenty zależne będą od np. aktualnego miesiąca, nazwy systemu i danych znanych wyłącznie nam. Całość musi być oczywiście odpowiednio wkomponowana w elementy czysto pamięciowe, aby złamanie jednego z naszych haseł nie ułatwiało złamania pozostałych.
Kiedyś uczestniczyłem w pewnym projekcie, którego głównym celem było rozwijanie stricte webowego portalu dla ograniczonej grupy użytkowników (forum, zasoby wewnętrzne, private messaging itp.). Uwierzytelnianie opierało się oczywiście na dedykowanych hasłach dostępowych. Jako administratorzy postanowiliśmy swego czasu rejestrować hasła podawane podczas nieudanych prób logowania. Oczywiście najczęstszym przypadkiem były drobne literówki w hasłach, jednak wcale nie rzadko użytkownicy wprowadzali łańcuchy znaków zupełnie odmienne od ich haseł w systemie. Jak się później okazało, były to hasła do innych systemów - najczęściej do kont pocztowych... Od tamtego czasu zawsze staram się podkreślać, że zanim zaczniemy wprowadzać do jakiegokolwiek systemu nasze hasło, zastanówmy się dwa razy, czy jest ono przeznaczone rzeczywiście dla niego.
Ostatnią kwestią, którą chciałbym tutaj poruszyć, jest częstotliwość zmiany haseł. Każde hasło można złamać (odgadnąć) - to tylko kwestia czasu odwrotnie proporcjonalnego do mocy obliczeniowej, jaką się dysponuje. Oczywiście inny jest poziom trudności odgadywania hasła w zdalnym systemie informatycznym, gdzie system może bronić się przed atakami blokując dostęp dla hosta po X nieudanych próbach logowania, a inna - jeżeli chodzi np. o hasło do zabezpieczonego archiwum z danymi. Z punktu widzenia właściciela hasła, całą sytuację da się jednak zredukować do swoistego wyścigu, w którym jakiś byt próbuje odgadnąć hasło, a my musimy okresową zmianą hasła zmuszać go do tego, aby zaczynał od początku. Oczywiście także i niedawno zmienione hasło może zostać szybko złamane. Wszystko w bezpieczeństwie jest kwestią prawdopodobieństwa i analizy zagrożeń, a z tego punktu widzenia zmiana hasła przynajmniej raz na miesiąc wydaje się całkiem rozsądną ucieczką do przodu.
Wraz z wypuszczeniem SP2 dla SQL Server 2005 Microsoft podjął decyzję o zmianie sposobu licencjonowania SQL Server 2005 w środowisku wirtualizacyjnym. Od razu zaznaczę, że nie chodzi wyłącznie o Microsoft Virtual Server 2005, tylko o każdą platformę wirtualizacyjną (m.in. VMware). Do niedawna konieczne było opłacenie tylu licencji SQL Server 2005, na ilu maszynach wirtualnych miał działać ten produkt. Od 19 lutego 2007 zakup jednej licencji SQL Server 2005 Enterprise Edition uprawnia do instalowania MSSQLa na nieograniczonej liczbie instancji wirtualnych, co pozwoli w niektórych scenariuszach znacznie obniżyć koszty. Koncern z Redmond chyba zrozumiał, że stosując dotychczasową politykę licencjonowania więcej może stracić, niż zyskać. Jest to jednak dopiero pierwszy krok w rozsądnym kierunku, gdyż w przypadku np. wersji Standard obowiązują stare zasady.
Więcej informacji:
virtualization.info: Microsoft unlocks SQL Server 2005 license for virtualization
|
