katalog stricte sieciowy

w jaki sposób 'dostarczyć’ jakiś katalog na kilka serwerów/VDI? łatwym i popularnym sposobem jest wykorzystanie Azure Files i po prostu podmapować dysk sieciowy.

takie rozwiązanie ma (potencjalnie) kilka wad. potencjalnie – ponieważ wszystko zależy od założeń po co i dla kogo to robimy:

• dodatkowa litera dysq
• trzeba dodatkowe polisy GPO żeby ścieżka była zaufana i żeby system nie pluł się przy każdym uruchomieniu

chodziło o dostarczenie wspólnego repozytorium, dostępnego na wszystkich VDI. można taki efekt osiągnąć mapując udział sieciowy jako katalog.

potrzebny do tego jest Storage Account wspierający Azure Files, dodany do domeny. jest to konieczne ze względu na możliwość uwierzytelnienia. a kiedy mamy już założony Azure Files, wystarczy utworzyć w systemie katalog, który będzie na niego wskazywał:

PS> new-item -type SymbolicLink -path c:\myRepo -target \\wfilesrepo.file.core.windows.net\repo

as simple as that. i mamy katalog, który zachowuje się i wygląda (niemal) jak normalny katalog. nie trzeba już polis GPO ponieważ Windows już nie traktuje tego jako dysq sieciowego a zwykły katalog lokalny.

dodam do tego kilka uwag i ciekawostek:

• taki symlink jest tylko wskazaniem. a to oznacza, że każdy oddzielnie musi mieć uprawnienia dostępu – to nie jest tak, że admin ma dostęp i podmapuje i każdy wlezie. trzeba więc odpowiednio posiedzieć nad uprawnieniami
• standardowo uprawnieniami dostępu do Azure Files jest moduł IAM – to zresztą ogólna zasada. pojawia się tutaj problem nadania uprawnienia wszystkim – ponieważ nie nadamy na poziomie IAM uprawnienia dla 'authenticated users’. jest od jakiegoś czasu możliwość obejścia tego problemu, ustawiając atrybut ’defaultSharePermissions’ dla Storage Account.
• ponieważ jest to link do sieci, jest problem z cache przy operacjach zapisu. zauważyłem, że czasem zapis jest odrzucany.
• SymLink zachowuje się jak katalog… ale nie do końca. SymLink jako katalog odziedziczy uprawnienia z katalogu nadrzędnego, ale nawet jeśli jest włączona flaga dziedziczenia, nie do końca uprawnienia spływają poniżej. należy uważać i dobrze przetestować. najlepiej odpowiednio przygotować strukturę i wyłączyć dziedziczenie:
  \\wfilesrepo.file.core.windows.net\repo\wlasciwykatalog – i wyłączyć dziedziczenie na poziomie 'wlasiciwykatalog’
  albo
  c:\root\[repo] – gdzie [repo] to symlink – i wyłączyć dziedziczenie na poziomie 'root’…
  to problemu nie będzie. tylko jest wtedy bzdurny dodatkowy katalog /:
• dodatkowy problem z uprawnieniami jaki zauważyłem, to fakt, że uprawnienia nadane dla grupy 'administrators’ bezpośrednio na file share, nie działają O_o . ogólnie: UWAGA NA UPRAWNIENIA, bo zachowują się dziwnie.
• i jeszcze – jak takiego symlinka usunąć? najlepiej:

(get-item c:\symlink).delete()

mimo pewnych dziwnych zachowań sprawdza się fajnie a dla użytkowników wygląda i zachowuje się jak folder lokalny.

eN.