2017-02-20
Zazwyczaj, konta w AD nie mają przypadkowych nazw. Nazwy muszą być nadawane zgodnie z przyjętą polityką. Np nazwy użytkowników mogą zawierać pierwsze litery nazwiska, a nazwy kont serwisowych mogą określać środowiska w jakich są wykorzystywane, jakie usługi będą z nich korzystać, na jakich serwerach itp.
W takim przypadku dość łatwo przeprowadzić inwentaryzację kont wykorzysywanych przez daną aplikację na danym serwerze lub w danym środowisku. Wystarczy do tego takie polecenie:
Get-ADUser -Filter "name -like 'sys*sql*p'" | Select name| Sort name
Zakładając, że konwencja nazewnicza
- kontom wykorzystywanym przez usługi określa nazwy rozpoczynające się od SYS
- kontom wykorzystywanym przez SQL określa występowanie w nazwie liter SQL
- kontom wykorzystywanym w środowisku produkcyjnym nadaje nazwy kończące się na P
powyższe polecenie wyświetli najprawdopodobniej właśnie konta usług SQL w środowisku produkcyjnym. Filtry mogą być oczywiście o wiele bardziej złożone!
2017-02-19
Dawno dawno temu kiedy chciałeś uruchomić usługę w systemie Linux dodawałeś plik o nazwie
S<XY><Name> oraz K<XY>Name
w katalogu /etc/init.d a potem w folderach /etc/rc[12345].d tworzyłeś link do odpowiednich plików. Pliki S* były uruchamiane podczas przechodzenia systemu do danego, określonego przez numer katalogu tzw. run-level, w celu uruchomienia usługi a pliki K miały za zadanie kończyć pracę tych usług. Liczby <XY> określały natomiast kolejność w jakiej usługi będą uruchamiane. Proste i logiczne.
W miarę ewolucji RedHat/Fedory, postanowiono jednak skorzystać z mechanizmów charakterystycznych dla systemd. Generalnie init.d ani rc2.d, rc3.d itd. nie są wykorzystywane.
Podczas definiowania nowej usługi należy korzystać z plików o nazwach
<ServiceName>.service
znajdujących się w
/etc/systemd/system
Jeśli instalujesz nowy serwis to należy w tym folderze utworzyć nowy plik, którego zawartość może wyglądać np. tak (przykład dla usługi Sybase): Czytaj dalej »
2017-02-09
Obiekty WMI mają złą sławę. Można z nich na prawdę dużo wyciągnąć, ale akurat ten kawałek platformy windows mógłby być trochę lepiej udokumentowany. Jednym z najbardziej tajemniczych tematów w pracy z WMI jest wywoływanie metod dla obiektów. Bez zbędnego rozwlekania tematu zobaczmy, jak to zrobić na 2 sposoby. Naszym zadaniem jest uruchomienie metodyDefragAnalysis na rzecz pierwszego dysku:
Metoda 1 – administacyjna
Polecenie Get-WMIObject zwraca obiekt klasy WMI. Wynik tego polecenia można więc potokiem przesłać do Select-Object aby wybrać właściwy dysk (tutaj pierwszy lepszy). Mając już tylko jeden obiekt wywołujemy dla tego obiektu metodę WMI korzystając z polecenia Invoke-WMIMethod. Istnieje również możliwość przekazania argumentów, ale DefragAnalysis nie wymaga żadnego. Oto te trzy polecenia połaczone w potok:
Get-WmiObject -Class win32_volume | select -First 1 | Invoke-WmiMethod -Name DefragAnalysis
Metoda 2 – programistyczna
Zaczynamy znowu od polecenia Get-WMIObject, ale tym razem zapominamy o zabawie potokiem. Aby wybrać właściwy wolumen (u nas pierwszy lepszy) znowu posługujemy się poleceniem Select-Object -Firs 1. Wynik tego potoku zapisujemy w zmiennej $volume. To czym jest teraz $volume? Ano obiektem WMI, ze wszystkimi jego właściwościami i metodami! Żeby wywołać metodę obiektu, po zmiennej napisz kropkę, potem nazwę metody do wywołania i w nawiasach ewentualnie umieść parametry:
$volume = Get-WmiObject -Class win32_volume | select -First 1
$volume.DefragAnalysis()
Podsumowanie:
Zależy jak wolisz, możesz korzystać i z jednej i z drugiej metody. Ja wybieram metodę 2, bo tam łatwiej jest przekazywać parametry i na dodatek, będąc programistą preferuję właśnie taki styl kodu… ale to moja prywatna opinia.
2017-01-28
Już od wersji SQL 2005 można w tabelach przechowywać dane w kolumnach o typie XML. Dane tam umieszczone mogą być krótkim fragmentem XML, ale równie dobrze może się tam znajdować obszerny dokument sięgający rozmiarem do 2 GB. To sporo! I co tu zrobić jeśli użytkownik chce wyświetlić tylko te rekordy które w polu XML mają okeśloną wartość? Bez dodatkowych indeksów trzebaby było po prostu przejrzeć wszystkie rekordy i dla każdego z nich oddzielnie analizować XML czy spełnia warunki czy nie. W przypadku dużych dokumentów będzie to ekstremalnie nieefektywne i dlatego właśnie wymyślono indeksy na kolumnach typu XML.
Istnieją dwa rodzaje indeksów XML:
PRIMARY indeks to miejsce w którym składowany jest XML w już przetworzonej postaci. Zauważ, że przechowywanie XML w kolumnie tabeli powoduje, że dane te są nadal podzielone na rekordy. Jeśli więc stworzysz zapytanie, które będzie miało pobrać tylko niektóre rekordy, spełniające określone warunki, to trzeba by było przetwarzać wszystkie dane z wszystkich rekordów, a tego chcemy uniknąć. Dlatego indeks PRIMARY to właśnie miejsce, którym składowany jest sparsowany i przetworzony XML. XML jest już tutaj podzielony na tagi (znaczniki), wartości wyrażone w elementach i atrybutach, ścieżki opisujące jak te wartości były zagnieżdżone w XML. Jeśli pewne pozycje tego PRIMARY indeksu zostaną w jakiś sposób odnalezione (a o tym już za chwilę), to w indeksie PRIMARY znajdzie się klucz podstawowy do podstawowej tabeli, czyli już do właściwego szukanego rekordu. Aby zacząć tworzyć kolejne indeksy SECONDARY musi najpierw istnieć indeks PRIMARY a tabela musi posiadać klucz podstawowy. Mając indeks PRIMARY można już lokalizować obiekty odpowiadające np. następującym wyrażeniom:
- //ContactRecord/PhoneNumber
- /Book/*/Title
Czytaj dalej »
2017-01-09
W Powershell wersji 5 pojawił się bug powodujący, że polecenie Get-Help about* zwraca tylko kilka wyników, podczas gdy tych plików z dokumentacją języka powinno być o wiele więcej…
Przyczyną była zła nazwa przypisywana plikom pomocy i można ten problem naprawić uruchamiając następujące polecenie:
Get-ChildItem -Path $pshome -Filter about*.txt -Recurse |
Where-Object { $_.Name -notlike '*.help.txt' } |
Rename-Item -NewName { $_.Name -replace '\.txt$', '.help.txt'}
Rozwiązanie skopiowane z http://community.idera.com/powershell/powertips/b/tips/posts/fixing-powershell-5-help-bug
Na szczęście w najnowszych wersjach, błąd wygląda już na poprawiony!
2017-01-02
Tak, wiem. To co najmniej dziwne, że wraz z Nowym Rokiem robimy sobie postanowienia noworoczne. Co najmniej, jakby postanowienie z dnia 13 marca było mniej ważne niż postanowienie z 1 stycznia… Wychodzę jednak z założenia, że na dobre rzeczy każda chwila jest odpowiednia! Przypuszczalnie większość noworocznych postanowień jest dobra, bo ma na celu poprawę naszej kondycji fizycznej lub umysłowej. Gdybym więc prowadził klub fitness, to teraz zaprosiłbym każdego do regularnego uprawiania wysiłku fizycznego, ale… nie prowadzę klubu fitness…
Za to ze mną w Nowym Roku możesz się nauczyć czegoś nowego. Zapraszam do wspólnej nauki SQL i PowerShell w ramach akademii UDEMY. Na razie do dyspozycji są trzy kursy:
Kto ma ochotę powiedzieć „dość” swoim brakom w wiedzy i nauczyć się SQL lub PowerShell jest mile widziany. Na powitanie prezent:
z kuponem STUDY2017 cena kursu spada do 10€ !
Oczywiście ja też mam postanowienie noworoczne! Chcę dla Was i z Wami przygotować jescze więcej kursów. Mam nadzieję, że się uda. Kursy po publikacji, będą przez pewien czas dostępne za darmo, więc jeśli chcesz aby cię o tym poinformować, zapisz się już teraz do newslettera. Kiedy publikuję na blogu nowy wpis, ty dostaniesz na ten temat maila. W ten sposób nie ominie cię darmowy okres w jakim będzie można bez kosztów zapisać się na moje szkolenie.
Więcej o nauce na Udemy
2016-12-27
Bardzo nie lubię literówek w moich skryptach, dlatego gdzie mogę korzystam z intellisence, wybieram wartości z listy, korzystam ze zmiennych zamiast stałych napisowych itp. W C# uwielbiam typ enum, bo dzięki niemu mogę korzystać z nic mi nie mówiących wartości liczbowych za pomocą nazwanch tekstów. W Powershellu również można korzystać z typu enum:
Add-Type -TypeDefinition @"
public enum ShareMode
{
Shared = 1,
Private = 2,
Hidden = 4
}
"@
W powyższym przykładzie zadeklarowałem typ FeaturesMap. Zmienne tego typu mogą przyjmować wartości:
[ShareMode]::Shared
[ShareMode]::Private
[ShareMode]::Hidden
Aby zadeklarować zmienną tego typu skorzystać można z następującej składni:
[ShareMode]$myVariable = [ShareMode]::Shared
Gdzieś pod spodem moja zmienna ma wartość 1, ale podczas pisania skryptu można ją porównywać do wartości zapisywanej jako [ShareMode]::Shared, np tak
if($myVariable -eq [ShareMode]::Shared)
{
echo 'shared mode'
}