Trzy problemy i przysłowiowy MacGyver

Wczoraj był dzień MacGyvera, z rana zostałem wysłany do jednego klienta by rozwiązać tak naprawdę jeden problem, potem miałem mieć spotkanie w pracy ale spędziłem je przed telefonem w celu rozwiązania kolejnego problemu a na dowidzenia dostałem jeszcze jeden ;)

Zacznijmy od pierwszego.

Polecenie BULK INSERT nie może dostać się do pliku lub go odczytać.

Przyjechałem na miejsce gdzie na komputerze X został udostępniony katalog z plikiem, który ma zostać odczytany przez BULK INSERT a następnie przetworzony. Dostałem także informacje, że SQL Server stoi na clustrze. Błąd zwrócony był dość dziwny:

Cannot bulk load because the file "\Xfolderfile1.cvs" could not be opened. Operating system error code 5(error not found).

Jak się przeszuka Google pod względem tego błędu to wyskoczy wiele propozycji – złe uprawnienia, netpipes włączone, wyłączona jakaś konfiguracja w SQL Server i wiele wiele innych. Było ich aż tak dużo, że musiałem skontaktować się z Brejkiem bo zaczynałem głupieć. Oczywiście moje wytłumaczenie problemu było bym powiedział kiepskie co zresztą potem stwierdziliśmy. Jednak to co dało mi do myślenia po rozmowie to słowo Node, które użył Brejk. No więc (nigdy nie rozpoczynaj zdania od Więc ;)) przypomniałem sobie, że SQL Server stoi na clustrze. Skoro to cluster to istnieje jakiś wirtualny komputer, który po w sobie różne nody, jak się okazało to komputer X był jednym z nodów. Wystarczyło więc zobaczyć jakie zasoby są współdzielone przez cluster, i następnie stworzyć share z odpowiednimi uprawnieniami na dysku współdzielonym na komputerze wirtualnym i boom :) BULK INSERT zaczął działać.

Morał z tego jest taki: zanim zaczniemy cokolwiek robić należy sprawdzić, jaka jest konfiguracja aktualna sieci i komputerów. Co mi z tego, że spędziłem 3h rozwiązując ten problem, jak problem był błahy i nie powinien zająć więcej niż 10 minut. Należy też zapamiętać, clustry mają komputer wirtualny, na którym jest narządko CluAdmin.exe jak dobrze pamiętam podające, jakie zasoby dla określonych grup są współdzielone. I następnie albo należy stworzyć nowy zasób albo na istniejącym zasobie stworzyć share.

Problem drugi na szczęście udało się rozwiązać telefonicznie.

Ludzie należący do Domain Local Group nie mogą się zalogować do aplikacji, błąd: Missing Role.

Na początku wytłumaczę błąd Missing Role, gdyż jest on specyficzny dla aplikacji. Nasza aplikacja łączy Windows Authentication i Forms Authentication na jednej stronie dzięki nowej funkcjonalności IIS 7. Forms Authentication ma custom membership provider, który autoryzuje użytkownika z domeną. Czyli Windows Auth służy by użytkownik ordazu się zalogował zaś Forms wspomaga użytkownika jakby chciał się na innego użytkownika zalogować. Teraz by jakikolwiek użytkownik mógł korzystać z aplikacji musi należeć do jednej z 20 grup AD. Grupy zostały nam narzucone wraz z nazewnictwem i okazało się, że część druga nazwy grupy po podkreśleniu określa rolę jaką użytkownik ma mieć w systemie. Teraz, jeżeli nie można pobrać grupy AD z obiektu użytkownika to zwracany jest błąd Missing Role.

Sutacja była następująca, osoba z domeny X.pl w której Domain Local Group o roli Z była stworzona mogła się zalogować, zaś osoba z domeny Y.X.pl dostawała Missing Role.

Pierwszą rzeczą, jaka może się nasuwać to błąd w kodzie, jednak nie tym razem. Napisałem taka małą aplikację windowsową testująca wyszukiwanie po AD za pomocą naszego kodu. Sprawdziliśmy na początku, jakie grupy są pobierane dla osoby z domeny X.pl, a następnie z domeny Y.X.pl. Okazało się, że wszystkie grupy dobrze są pobierane dla obydwóch użytkowników, z mała różnicą. Użytkownik z domeny Y.X.pl nie miał informacji o grupie Domain Local Group. Za to grupa miała informacje o tym iż użytkownik z domeny Y.X.pl przynależy do niej. Czyli coś nie grało… okazało się, że problem w tkwi w typie grupy AD. Domain Local Group może zawierać użytkowników ze wszystkich domen i lasów, jednakże jest widoczna tylko i wyłącznie w domenie, w której została utworzona. Czyli domena Y.X.pl nie widzi informacji o grupie Domain Local Group z domeny X.pl. Zamiana na typ grupy Universal załatwiła sprawę i nagle wszyscy użytkownicy mogą się logować do aplikacji.

Morał: Poznaj dokładnie strukturę AD u klienta, by nagle nie wpakować się w bagno z powodu nie przewidywalnych okoliczności. Należy wiedzieć, z jakich domen użytkownicy mogą się logować, na jakich komputerach stoją domeny – czy są tam domeny 2000? Czy istnieją inne lasy, czy użytkownicy z innego lasu mają się logować do naszej aplikacji w drugim lesie. Itp. itd. ważne jest znanie na te pytania odpowiedzi, bo na przykład jak klient powie, że chce mieć kerberosa działającego pomiędzy domenami z ustawionym trustem, zaś jedna domena stoi na win2k a druga na win2k3 to możemy mu od razu powiedzieć, że tego się nie da zrobić do póki win2k nie zostanie podniesiona do minimum win2k3.

Trzeci ostatni błąd, nierozwiązany… jeszcze :)

Połączenie do Analysis Services za pomocą Connection String łączy się jako Anonymous user.

Tutaj dużo można gadać, nie licząc, że cała architektura i konfiguracja środowiska jest chyba jedną z największych porażek, jakie widziałem, ale skoncentruje się na tym jednym problemie.

Mamy aplikację WEB, która łączy się z usługami sieciowymi, które działają na usłudze Windows (usługa Windows je tworzy), komunikacja idzie po WCF, zaś usługa Windows udostępnia API do łączenia się z bazami danych plus także z Analysis Services. Teraz w connection string do analysis services ustawione są dwie właściwości User Id i Password, user Id zawiera użytkownika domenowego zaś Password jego hasło (blah hasło użytkownika domenowego plain textem… i to w pliku… nie no super architektura nie ma co). I teraz ta konfiguracja działała do zeszłego tygodnia, od zeszłego tygodnia (podobno zmian nie było) nagle połączenie do Analysis Services próbuje łączyć się jako Anonymous user… zaś jeżeli wykorzystamy ten sam connection string w innej domenie to… wszystko działa poprawnie. Jeżeli wykorzystamy zmodyfikowany connection string bez user ID i password i odpalimy aplikację na dedykowanym koncie to connection string działa, odpalimy na tym koncie, na którym cała usługa Windows chodzi, i nie działa. Ciekawy błąd choć ja najpierw bym poprawnie skonfigurował całe środowisko a nie wykorzystywał wszędzie Network Service, Local System i Anonymous user bo to po prostu jak podrzynać sobie żyły krakersem… bezsensowne prawda? :)

Morał: konfigurujcie dobrze swoje środowiska to przynajmniej jak coś padnie będziecie wstanie to szybko z diagnozować :)