Komenda lsof pozwala na wyświetlenie otwartych na systemie plików. Taka informacja przydaje się czasami. Np. kiedy chcesz odmontować system plików, ale jakiś proces otworzył plik w tym systemie plików i blokuje twoją operację.

Ponieważ w Linuxie wszystko jest plikiem, to można sprawdzić, czy jakiś proces otworzył zasoby związane z siecią. Dlatego żeby sprawdzić na jakich portach nasłuchują lokalne procedy można posłużyć się komendą:

Za co odpowiadają opcje?

-i listuje tylko pliki związane z zasobami sieciowymi

-P powstrzymuje komendę przed zamianą numeru portu na jego dobrze znaną nazwę, jak np http, ssh itp.

-n powstrzymuje komendę przez zamianą adresu IP na skojarzoną z nim nazwę

Oto przykładowy wynik:

Oto pełny komunikat błędu:

[root@dbserv10 ~]# dnf -y install edb-as13-server edb-pem
Updating Subscription Management repositories.
Unable to read consumer identity
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
Extra Packages for Enterprise Linux Modular 8.2 140 kB/s | 70 kB 00:00
Errors during downloading metadata for repository ‚epel-modular’:
– Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 18.159.254.57)
– Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 18.185.136.17)
– Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 85.236.55.6)
Error: Failed to download metadata for repo ‚epel-modular’: Cannot prepare internal mirrorlist: Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 18.185.136.17)

W pliku /etc/yum/vars/releasever można „na sztywno” zdefiniować release, dla którego należy dopasować pakiety podczas instalacji. Tymczasem w plikach repo, jest wykorzystywana zmienna $releasever, z domyślną wartością „8” (w przypadku RedHat 8).

Jeśli instalacja odbywa się w oparciu o takie repo, to instalacja kończy się błędem jak powyżej. Żeby wyeliminować błąd wystarczy zamienić w plikach repo $releasever na wartość 8. Można to zrobić poleceniem sed:

Domyślne opcje polecenia find związane z szukaniem pliku po dacie modyfikacji pracują z wykorzystaniem okresów 24-godzinnych. Zazwyczaj to nie problem, bo np. usuwając stare pliki z katalogu /tmp można jako kryterium przyjąć „pliki starsze niż 30 dni”. To czy plik zmodyfikowany o 9:30 złapie się do usunięcia dzisiaj czy jutro nie ma żadnego znaczenia 🙂

Co jednak zrobić jeśli chcesz z jakiegoś powodu znaleźć pliki zmodyfikowane w określonym czasie (godzina, minuta, sekunda)? Otóż z pomocą przychodzi parameter -newerXY.

Szczegóły znajdziesz w helpie, a tutaj przykładowa komenda wyszukująca pliki zmodyfikowane między 9:30, a 9:32

Jeśli stworzyłeś kilka tablespace w bazie postgresql i chcesz sporządzić kopię korzystając z pg_basebackup w formacie plain, to możesz spotkać problem w postaci błędu:

O co chodzi?

Backup w formacie plain kopiuje pliki i katalogi 1-1. Nie ma problemu z danymi znajdującymi się w katalogu data clustra SQL. Tutaj Postgres jest na tyle mądry, że wie, że należy go przekopiować do katalogu z kopią. Niestety co do pozostały tablespace, domyślnie jest tak, że kopia katalogu ma być wykonana w tym samym miejscu (sic!). Tego się oczywiście nie da zrobić wykonując kopię lokalnie na maszynie z zainstalowanym postgresem. Wydaje mi się to co najmniej dziwne, że taka jest logika wykonywania kopii, ale najwyraźniej chłopaki, którzy to robili mieli ku temu jakieś istotne powody – nie wnikam w to.

Jak obejść ten problem?

Na całe szczęście mamy w poleceniu pg_basebackup opcję, która pozwala wskazać do jakich katalogów mają być zapisane odpowiednie tablespace. Jest to opcja T. W tym przypadku komenda mogła by wyglądać tak:

Tablespace znajdujący się w katalogu /home/4pg/app_data zostanie teraz skopiowany do /home/pg_archives/sunday_plain/app_data i podobnie będzie z katalogiem /home/4pg/temp_tblspc, który zostanie skopiowany do /home/pg_archives/sunday_plain/temp_tblspc.

Dziękuję za wskazówki na innych blogach i forach:

https://www.percona.com/blog/2018/12/21/backup-restore-postgresql-cluster-multiple-tablespaces-using-pg_basebackup/

https://programmer.ink/think/introduction-to-temporary-tablespaces-of-postgresql-and-greenplum.html

pg_basebackup: error: directory “dir_abc” exists but is not empty OR ERROR: tablespace “ABC” is not empty

Zdarza się (często), że w Idle, który jest domyślnym i bodajże najprostszym edytorem skryptów Pythona, nie działają podpowiedzi. Czasami pomaga proste uruchomienie skryptu przed jego dalszym pisaniem (Idle uświadamia sobie wtedy z jakimi zmiennymi ma do czynienie i „zaskakuje”), ale czasami to nie pomaga.

1. Poszukaj w Finder pliku autocomplete_w.py . Jeżeli plików o takiej samej nazwie jest więcej, to pewnie jest zainstalowanych kilka wersji Pythona. W takim przypadku wybierz ten zgodny z właśnie wykorzystywaną wersją (zgodną z Idle) np.:

2. Otwórz plik autocomplete_w.py i znajdź w nim dwie sąsiadujące linie::

3. Wstaw między nie dodatkową linijke::

4. Zapisz plik i trzymaj kciuki, aby po naciśnięciu klawisza ⇥ zobaczyć okienko z  autouzupełnieniem

Jedną z popularniejszych usług w Azure są maszyny wirtualne (Virtual Machines – VM). Budując rozwiązanie dla klienta i wpasowując je w jego wymagania, określamy dostępność maszyny. Ten parametr jest wpisany w Service Level Agreement (SLA). Na maszynach wirtualnych mogą być oparte kolejne serwisy i zależnie od zdefiniowanej architektury, te serwisy mogą oferować lepsze SLA. Wejściowym parametrem do obliczenia SLA dla całego rozwiązania pozostaje jednak SLA maszyn wirtualnych. Co mamy do wyboru?

• Pojedynczą maszynę, która oferuje dostępność na poziomie 99.9%
• Dwie lub więcej maszyn w tym samym availability set – 99.95%. Co istotne oznacza to już dostępość dla Availability Set – dostępność pojedynczej maszyny to nadal 99.9%.
• Jeśli by te maszyny rozrzucić jeszcze w różnych availability zones, to ich dostępność wzrośnie do 99.99%.

Co istotne podane tu wartości dotyczą konfiguracji maszyny opartej o storage premium lub ultra. Jeśli zdecydowalibyśmy się korzystać ze standard HDD, to gwarantowany czas dotępności spadnie do 95% w przypadku pojedynczej maszyny.

SLA dotyczy „gołego” systemu operacyjnego, to jakby włączyć w domu laptopa z czystym windows i nic na nim nie robić. Na VM  będzie oczywiście pracować aplikacja i jej dostępność to już inna sprawa. Sama zaś maszyna może być narażona na ataki malware, które również nie są brane pod uwagę przez Microsoft – w końcu samo zarządzanie systemem operacyjnym w modelu IaaS pozostaje po stronie klienta.

Pełny komunikat z błędem prezentuje się następująco:

TITLE: Microsoft SQL Server Management Studio
——————————

The Activity Monitor is unable to execute queries against server XXXXXXXXXX
Activity Monitor for this instance will be placed into a paused state.
Use the context menu in the overview pane to resume the Activity Monitor.

——————————
ADDITIONAL INFORMATION:

Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) (mscorlib)

Żeby było ciekawie, to (1) jestem sysadminem na SQL (2) jestem lokalnym administratorem na Windows. Jedna z pierwszych prób naprawy błędu „Access Denied”, to zwykle uruchomienie programu „jako administrator”. I w tym przypadku pomogło. Jednak jest to nieco dziwne, dlatego poszukałem dalej i znalazłem:

https://sqltimes.wordpress.com/tag/access-is-denied-exception-from-hresult-0x80070005-e_accessdenied-mscorlib/

Artykuł opisuje, jakie uprawnienia i gdzie należy nadać, żeby można było korzystać z Activity Monitora. Grupa administratorzy wszędzie posiadała wszystkie wymagane uprawnienia, ale kiedy na serwerze jest skonfigurowany UAC, to token grupy administracyjnej jest wyrzucany podczas uruchamiania aplikacji. To dlatego SSMS uruchomione jako zwykły użytkownik nie mogło uruchomić Activity Monitora. Kiedy jednak  SSMS uruchamiałem jako administrator, to SSMS mając token grupy administrator mogło śmiało robić wszystko co chciało.

Żeby bez problemów uruchamiać SSMS jako normalny użytkownik nadałem opisane w artykule uprawnienia i wszystko działa jak należy! W skrócie:

• Uruchom Component Services – DCOMCNFG
• Przejdź Console Root >> Component Services >> Computers >> My Computer >> Properties
• Na zakładce COM Security kliknij „Edit Limits” – zarówno w sekcji „Launch and Activation Permissions” jak i „Access Permissions” i nadaj swojej grupie zarówno „Remote Launch & Remote Activation”
•  

  W My Computer, w drzewku po lewej stronie znajdziesz jeszcze >> DCOM Config. Przejdź do Windows Management and Instrumentation >> Properties.

• W zakładce Security w sekcji Launch and Activation Permissions kliknij Edit i jeśli nie ma tam twojej grupy, to dodaj ją i przypisz uprawnienia Remote Launch & Remote Activation

Gotowe!