Niektóre mechanizmy PostgreSQL, jak np. replikacja logiczna wymagają, aby tabele posiadały primary key. Dlatego przyda się wiedzieć, czy baza danych spełnia wymogi dla replikacji logicznej. Oto polecenie, które wyświetli informację o tabelach bez primary key:

select tab.table_schema,
       tab.table_name
from information_schema.tables tab
left join information_schema.table_constraints tco 
     on tab.table_schema = tco.table_schema
        and tab.table_name = tco.table_name 
        and tco.constraint_type = 'PRIMARY KEY'
where tab.table_type = 'BASE TABLE'
      and tab.table_schema not in ('pg_catalog', 'information_schema')
      and tco.constraint_name is null
order by table_schema, table_name;

I co jeśli takie tabele się znajdą? Ogólnie masz kłopot, ale w najlepszym przypadku, znajdzie się w tabelach kolumna, która może być potraktowana jako primary key. Zaczynamy więc od sprawdzenia struktur tabel:

mytest=> \d towns
 Table "public.towns"
 Column     | Type                  | Collation | Nullable | Default 
------------+-----------------------+-----------+----------+-----------------------------------
 id         | integer               |           | not null | nextval('towns_id_seq'::regclass)
 code       | character varying(10) |           | not null | 
 article    | text                  |           |          | 
 name       | text                  |           | not null | 
 department | character varying(4)  |           | not null | 
Indexes:
 "towns_code_department_key" UNIQUE CONSTRAINT, btree (code, department)
 "towns_id_key" UNIQUE CONSTRAINT, btree (id)

Dodanie indeksu opartego o kolumnę id wyglądałoby tak:

alter table towns add primary key (id);

I gotowe!

Problem:

Dane pochodzące z wielu plików, zostały zaimportowane do Pandas Data Frame w następującej postaci:

Chcielibyśmy uniknąć wielokrotnie powtarzanej daty, wartości numeryczne znajdujące się w col1, col2 i col3 powinny się nasumować, dając taki efekt:

Rozwiązanie:

Wydaje się, że funkcjonalnością stworzoną do takiego celu jest grupowanie. Wystarczy na rzecz obiektu data frame wywołać metodę groupby wskazując, że grupowanie ma się odbyć ze względu na datę, a dla kolumn numerycznych chcemy zobaczyć sumę. Oto propozycja rozwiązania:

import pandas as pd
data = ({
 'date' :['2000-01','2000-02','2000-01','2000-02','2000-01','2000-02'],
 'col1' :[22000,25000,0,0,0,0],
 'col2' :[0,0,23000,24000,0,0],
 'col3' :[0,0,0,0,26000,25000]
 })
df = pd.DataFrame(data, columns=['date','col1','col2','col3'])
print(df)

df2 = df.groupby('date').sum()
print(df2)

Zadanie z jakim się zmierzam, to ustalenie minimalnych uprawnień jakie powinien posiadać użytkownik, aby wykonać pewną czynność. W tym przypadku chodziło o budowanie specyficznej infrastruktury z wykorzystaniem skryptu Terraform, ale metoda sprawdzi się też w innych scenariuszach.

Zacząłem od stworzenia service principal, bo w moim przypadku skrypt miał być uruchamiany na service principal. Gdyby miało to być zwykłe konto użytkownika, to oczywiście należało by stworzyć konto:

az ad sp create-for-rbac --name myserviceprincipal

W wyniku tego polecenia jest tworzony service principal, a  w zwróconym output można znaleźć coś w tym stylu:

{
  "appId": "6...XXX...",
  "displayName": "myserviceprincipal",
  "password": "y...XXX...",
  "tenant": "6...XXX..."
}

Mamy tu: appId, bo jest on wykorzystywany przez dalsze polecenia i można go utożsamiać z określonym service principal i password, bo to tajna część utworzonego właśnie service principal i wreszcie tenant określający, gdzie tego service principal można używać (w jakiej organizacji). Czytaj dalej »

CTRL+w  s   podział okna na 2 ułożone obok siebie – s jak split

CTRL+w  v  podział okna na 2 ułożone jedno pod drugim – v jak vertical

CTRL+w  n  otwarcie nowego okna, poniżej – n jak new

CTRL+w  q  wyjście z okna – q jak quit

CTRL+w i jeden z klawiszy hjkl lub strzałki – zmiana aktywnego okna na po lewej, prawej u góry lub na dole

CTRL+w w – zmiana aktywnego okna na kolejne (pętelka)

CTRL+w r – zmiana miejscami okien – r jak rotate

CTRL+w i jeden z klaiszy + – = – zmiana wielkości okna: powieksz, pomniejsz, ułóż równo

:ter – uruchomienie terminala (można dzięki temu symulować wygląd code)

:set cursorline cursorcolumn – bieżący wiersz i kolumna będą wyróżnione

:highlight CursorColumn ctermbg=Grey ctermfg=Black – zmiana koloru kolumny wyróżniającej

Jeśli w trakcie testowania klawiszy przypadkiem naciśniesz CTRL+s, to terminal się „zamrozi”. Odmrożenie można wykonać naciskając CTRL+q

Ustawienia, zwłaszcza te dotyczące kolorów, można na stałe zapisać w pliku .vimrc o tak:

 cat .vimrc
set cursorline cursorcolumn
highlight CursorColumn ctermbg=Grey ctermfg=Black

Pełny help dotyczący również innych skrótów zobaczysz wpisując polecenie:

:help windows.txt

Domyślne linki pozwalające na instalację przeglądarki MS Edge na Windows Server 2019 nie działają… dzięki Microsoft!

Ale ten link zadziała:

https://www.microsoft.com/en-us/edge/business/download

Co istotne, może być wymagana zmiana ustawień bezpieczeństwa w IE, żeby instalator edge dało się pobrać.

1. Należy przejść do IE -> Internet Options
2. Na zakładce Security wybrać Custom Level
3. Przewinąć prawie na sam dół. Jest tam sekcja Scripting
4. Upewnić się,  że opcja Active Scripting jest ustawiona na „Enable”

Enjoy!

Gdy skrypt, który przygotowujesz musi pracować z róznymi tenantami i subskrypcjami przyda się wiedza na temat tego jak wybrać właściwą subskrypcję z linii komend. A robi się to tak:

Logowanie poleceniem az do Azure:

az login

Sprawdzenie „a gdzie to ja się właściwie zalogowałem”:

 az account show

{
  "environmentName": "AzureCloud",
  "homeTenantId": "7d*****-****-****-****-**********aa",
  "id": "cc******-****-****-****-**********78",
  "isDefault": true,
  "managedByTenants": [],
  "name": "Azure Pass - Sponsorship",
  "state": "Enabled",
  "tenantId": "7d*****-****-****-****-**********aa",
  "user": {
    "name": "m******@*****.pl",
    "type": "user"
  }
}

Identyfikator subskrypcji widać już właściwie powyżej w polu id.

Wyświetlenie dostępnych subskrypcji:

az account list --output table

Name                      CloudName    SubscriptionId                        State    IsDefault
------------------------  -----------  ------------------------------------  -------  -----------
Azure Pass - Sponsorship  AzureCloud   cce*****-****-****-****-**********78  Enabled  True
MSDN Platforms            AzureCloud   b0f*****-****-****-****-**********56  Enabled  False

Przełączenie się do innej subskrypcji:

az account set --subscription "MSDN Platforms"

To polecenie jest ciche, więc po wszystkim radziłbym ponownie wylistować konta i sprawdzić, czy aktywna jest właściwa subskrypcja

Więcej: https://docs.microsoft.com/pl-pl/cli/azure/manage-azure-subscriptions-azure-cli

XXI wiek, a ciągle używamy haseł? Bez haseł jest prościej i hahahah… bezpieczniej! Wiem, wiem, koniec końców to hasło gdzieś się tam pojawi, ale…

Jeśli między systemami opartymi o Linux/Unix chcesz logować się bez podawania hasła w oparciu o uwierzytelnie kluczem prywatnym i publicznym to:

Zacznij od wygenerowania tych kluczy. Służy do tego polecenie ssh-keygen. Polecenie zaproponuje zapisanie klucza prywantego w katalogu domowym w .ssh/id_rsa, a publicznego w .ssh/id_rsa.pub.

Taka lokalizacja nie jest zła, jeśli ten prywatny klucz chcesz zachować lokalnie na swoim komputerze, a publiczny przegrać na zdalną maszynę, która powinna akceptować Twoje logowanie bez prośby o hasło:

ssh-keygen

Generating public/private rsa key pair.
Enter file in which to save the key (/home/boss/.ssh/id_rsa): 
/home/boss/.ssh/id_rsa already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/boss/.ssh/id_rsa
Your public key has been saved in /home/boss/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:tmvrlp4/kvgPulfa7Bl4qiD0bd2mNQwACtBLgi756gc boss@u20
The key's randomart image is:
+---[RSA 3072]----+
|=.  .            |
|o.o. .           |
|.+..  .          |
|o..    .         |
|...     S        |
| E.. . o *.      |
| .o o o.=BO      |
|.  o o..OX++     |
|...   +XX*=.     |
+----[SHA256]-----+

Tworząc te klucze można (i w sumie jest to zalecane), zabezpieczyć je hasłem. W takim  przypadku przed skorzystaniem z klucza prywatnego będziemy musieli najpierw go otworzyć podając to hasło.

Polecenie ssh-keygen pozwala na określenie dodatkowych parametrów kluczy jak, ich algorytm, czy długość.

Gdy klucz już jest wygenerowany, to należy go rozdystrybuować na systemy, które powinny go akceptować  i pozwalać logować się bez hasła. Zrobisz to poleceniem

ssh-copy-id username@host.address.com

Jeśli klucz publiczny miałby być wykorzystywany tylko na lokalnym serwerze, to należy go umieścić w pliku authorized_keys.

Jeśli masz więcej wygenerowanych kluczy, to możesz je przesyłać wybiórczo do zdalnego stystemu korzystając z opcji -i o tak:

ssh-copy-id -i ./servername username@host.address.com

gdzie servername to nazwa pliku z kluczem wygenerowanym wcześniej za pomocą ssh-keygen.

Od tej pory można się już łączyć do zdalnej maszyny przez

ssh username@host.address.com

Na docelowej maszynie plik powinien zostać umieszczony w katalogu domowym użytkownika w podkatalogu .ssh. Uwaga – ten podkatalog musi mieć w odpowiedni sposób zdefiniowane bezpieczeństwo: właścicielem musi być użytkownik, a uprawnienia powinny być odebrane dla grupy i innych (700)

Jeśli z jednego serwera chcesz łączyć się do większej liczby innych serwerów, możesz w katalogu ~/.ssh utworzyć plik config o zawartości podobnej jak ta:

# Control node
Host dbserv10
HostName dbserv11
PreferredAuthentications publickey
IdentityFile ~/.ssh/dbserv10

# Client node
Host dbserv11
HostName dbserv11
PreferredAuthentications publickey
IdentityFile ~/.ssh/dbserv11

Wykonując połączenie na konto user@hostname, zostanie pobrany od razu właściwy klucz.