Nie ma lepszych narzędzi do wydobycia informacji o środowisku niż prosty skrypt, który można sklecić „na kolanie”

Znajdź mi użytkowników, którzy mają nazwę kończąca się na service:

Get-AdUser -filter „name -like ‚*service'” | select name

Znajdź mi grupy, które mają w nazwie PRD I kończą się na SYS:

Get-ADGroup -filter „name -like ‚*PRD*SYS'” | select name

Co oczywiście ważne przed uruchomieniem tych poleceń trzeba mieć zainstalowany feature „Active Directory Domain Services Tool”:

Get-WindowsFeature *adds* | Add-WindowsFeature

Proste!

Chociaz FTP nie jest bezpiecznym protokolem to czasami jeszcze gdzie niegdzie sie stosuje. Tym razem chodzilo o wyslanie plikow z serwera Windowsowego na serwer Linux. Idealnie jesli bedzie to zrobione przez PowerShella wlasnie.

Oto najwazniejszy kawalek kodu:

$localfile = ‚c:/temp/filename.txt’
$ftp = „ftp://servername/dir1/dir2/”
$user = „username”
$pass = „password”
$destinationFileName = ‚filename.txt’
$webclient = New-Object System.Net.WebClient
$webclient.Credentials = New-Object System.Net.NetworkCredential($user,$pass)
$uri = New-Object System.Uri($ftp+$destinationFileName)
$webclient.UploadFile($uri, $localfile)

Niestety w czasie ladownia pliku pojawial sie blad:

The remote server returned an error: (553) File name not allowed. Czytaj dalej »

Aplikacja nie chciała się uruchomić zgłaszając (i za to brawa dla programisty), że opcja ALLOW SNAPSHOT ISOLATION musi być włączona.

Niby prosta rzecz

ALTER DATABASE ... SET ALLOW_SNAPSHOT_ISOLATION ON

I co? Czekam i czekam… sprawdzam, co blokuje sesję. Wait time to ENABLE_VERSIONING. No dobrze – jeśli to pierwsza baza z tym ustawieniem, to może rzeczywiście coś tam się musi w tempdb przebudować? Ale komenda nie chce się skończyć!

Jak można przeczytać w https://www.sqlskills.com/help/waits/enable_versioning/

“Occurs when SQL Server waits for all update transactions in this database to finish before declaring the database ready to transition to snapshot isolation allowed state. This state is used when SQL Server enables snapshot isolation by using the ALTER DATABASE statement.

No dobrze, ale w mojej bazie nie ma już żadnych połączeń. Co może być nie tak? Nawet checkpoint wyzwoliłem ręcznie, ale nic…. Czytaj dalej »

expr1 if cond else expr2

print(price-bonus) if bonus_granted else print(price)

print(price-bonus) if bonus_granted else price = 200
print(price-bonus) if bonus_granted  else pass

Ale po kolei:

A teraz odpowiadając na pytanie. Przypomnijmy, że Pythonie można mieć statement i expressions:

• statement – coś robi i niekoniecznie cokolwiek zwraca. Przykładem statement jest pass i przypisanie wartości do zmiennych
• expression – to jest jedna lub więcej instrukcji, które coś zwracają. Przykładem expression jest np dowolny napis, dowolne obliczenie, ale też np. polecenie print (!!!!!!)

Jak sprawdzić czy coś jest expression? Prosto. Do zmiennej przypisz wynik wykonania polecenia, np.: Czytaj dalej »

Stare bazy migrowane ze starych systemow SQL moga miec ustawiona opcje PageVerify na TORN_DETECTION. Oczywiscie to metoda z zeszlego wieku i aktualnie powinnismy uzywac CHECKSUM. Obie wartosci mowia o tym w jaki sposob kontrolowac, czy zapis strony bazy danych na dysk wykonal sie w 100%, czy tez sa jakies problemy. TORN_PAGE pozwoli dowiedziec sie tylko o tym czy zapis zostal zakonczony poprawnie, podczas gdy CHECKSUM pozwala sprawdzic czy podczas zapisu (lub odczytu) nie doszlo do przeklamania.

Zalozmy ze jedna z baz przetrwala od roku 2005 do dzisiaj z opcja TORN_PAGE. Co sie stanie kiedy zmienimy opcje na CHECKSUM? Czy ta jedna zmiana spowoduje, ze serwer przeczyta wszystkie strony z dysku, wyliczy na nich sume kontrolna i zapisze dane spowrotem na dysk? Czy jezeli jakas strona byla uszkodzona i miala ustawiony bit odpowiadajacy za TORN_DETECTION to czy ten blad bedzie nadal widoczny? Czytaj dalej »

Sam nie wiem z czego to wynika, ale uzytkownicy proponuja czasami nieco abstrakcyjne rozwiazania zwiazane z ustawieniem uprawnien do bazy danych.

W tym przypadku klient chcial aby uzytkownicy bazy danych mogli pracowac na poziomie uprawnien db_owner, ale z jednym malym haczykiem. Uzytkownicy nie powinni moc usunac bazy danych. Dlaczego uwazam, ze zyczenie jest nieco abstrakcyjne? Otoz db_owner to bardzo wysokie uprawnienie, wiec zlosliwy uzytkownik moze:

• pousuwac tabele
• zmodyfikowac procedury
• zabrac uprawnienia innym uzytkownikom
• itp.

Wydaje sie ze lepszym rozwiazaniem byloby wybranie tylko tych uprawnien, ktore sa rzeczywiscie potrzebne i nadanie ich do roli bazy danych. Potem uzytkownikow wystarczy przypisywac do tej roli. Byloby bezpieczniej.

No ale… usuniecie bazy danych jak opisano w https://docs.microsoft.com/en-us/sql/t-sql/statements/drop-database-transact-sql?view=sql-server-2017 moze byc wykonane tylko w 3 przypadkach:

• uzytkownik ma upranienie ALTER ANY DATABASE
• uzytkownik ma uprawnienie CONTROL
• uzytkownik jest db_ownerem

Requires the CONTROL permission on the database, or ALTER ANY DATABASE permission, or membership in the db_owner fixed database role.

Skoro u nas uzytkownik jest db_ownerem, to mozna mu zabrac uprawnienie do kasowania bazy tylko na 2 sposoby:

• deny alter any database to user_name
• deny control on database::db_name to user_name

Czytaj dalej »

Podczas instalacji Windows Failover Cluster na nodach clustra tworzony jest udostpniony zasob wskazujacy na C:\ClusterStorage

Takie „ukryte” zasoby sa czesto wychwytywane przez osoby pilnujace bezpieczenstwa serwerow, tymczasem ten powinien byc od razu wciagniety na white-list. Katalog ten pozwala w clustrze sledzic wykorzystanie Cluster Shared Volume (CSV), co jest dokladniej opisane na stronie Microsoft:

https://docs.microsoft.com/en-us/windows-server/failover-clustering/failover-cluster-csvs