Pl:Serwer polskiej społeczności

From OpenStreetMap Wiki
Jump to navigation Jump to search

Serwer polskiej społeczności jest widoczny pod nazwą osmapa.pl (85.11.120.18) i znajduje się w serwerowni zvid.net, obsługiwanej przez użytkownika zVID. Kontakt do adminów na Discordzie: kanał #serwer-osm-pl. Statystyki działania serwera: http://85.11.120.18:19999

Kontenery aktywne
Nazwa Strona/Usługa Repozytorium Opis Kontakt
c10-http-proxy - - Pośrednik HTTP do wszystkich kontenerów. jendrusk, Kocio
c21-osmapa-pl https://osmapa.pl/ - Starszy styl kafelków osmapa pl (read-only) -
c22-budynki https://budynki.openstreetmap.org.pl/ https://github.com/openstreetmap-polska/gugik2osm Strona z danymi z GUGIKu do importowania (budynki i adresy) tomczk
c24-aed-osm-org-pl https://aed.openstreetmap.org.pl/ https://github.com/openstreetmap-polska/aed-mapa Mapa defibrylatorów AED (Polska). tomczk, RicoElectrico, Ancymon
c26-aed-backup - https://github.com/openstreetmap-polska/aed_backup Backup danych AED (Polska) z generowaniem statystyk. NieWnen, Cristoffs
c40-www-osm-org-pl https://openstreetmap.org.pl - Strona polskiego stowarzyszenia OSMP (OpenStreetMap Polska). RicoElectrico
c60-garmin-gen https://garmin.osmapa.pl/ https://github.com/openstreetmap-polska/osmapa-garmin Generator plików mapowych na urządzenia Garmin i strona. Andrzej T.
c61-garmin-www https://garmin1.osmapa.pl/ https://github.com/openstreetmap-polska/osmapa-garmin/issues/5 Demo na wordpressie (porzucone?). RicoElectrico
c62-trigar-osmapa-www https://trigar.osmapa.pl/ - Strona autoryzowanego partnera garmina https://trigar.pl/ -
c70-vip-osm-org-pl https://vip.openstreetmap.org.pl https://github.com/openstreetmap-polska/vip Mapka demo dla projektu VIP (w ramach projektu MAD) NieWnen, Cristoffs
c80-josm-plbuildings-server https://josm-plbuildings-server.openstreetmap.org.pl/api/ https://github.com/praszuk/josm-plbuildings-plugin Back-end wtyczki do JOSM plbuildings NieWnen
c100-dc-rss 🔒https://dc-rss.openstreetmap.org.pl/ - Bot na Discord do RSS NorthCrab,NieWnen
Kontenery nieaktywne
Nazwa Repozytorium Opis Data wygaszenia Powód
c29-openaedmap https://github.com/openstreetmap-polska/openaedmap-backend

https://github.com/openstreetmap-polska/openaedmap-frontend

Back-end mapy defibrylatorów (cały świat). 2023-05-02 Przeniesienie na inną maszynę.
c50-tiles https://github.com/openstreetmap-polska/fractal Kafelki mapy Polski oparte o styl fractal (do postawienia na nowo). 2023-01-24 Zepsute – trzeba postawić na nowo.
c28-dopomoha-data-osm-org-pl https://github.com/openstreetmap-polska/pomagam-to-dopomoha Parser danych ze strony pomag.am dla projektu c27-dopomoha-pl 2022-11-19 Brak kontynuacji projektu.
c27-dopomoha-pl - To prawdopodobnie był kontener pod ten projekt. 2022-11-19 Brak kontynuacji projektu
c30-postgres - Wspólny kontener z bazą OSM dla innych kontenerów. 2022 Brak kontynuacji projektu.

Dyski są konfigurowane np. w macierze na fizycznym kontrolerze, a następnie formatowane jako pule ZFS lub/i BTRFS, i te zasoby są dopiero udostępniane dla kontenerów LXC. Serwer działa pod kontrolą Ubuntu 22.04 LTS.

Rozkład obciążenie serwera:

  • c22-budynki - największe obciążenie środa/czwartek parsowanie bdot, piątek wieczór/sobota noc aktualizacja bazy adresów/budynków, część rzeczy jest w cronie (/opt/gugik2osm/conf/cronfile na serwerze lub na githubie), część jest schedulowana przez airflow (airflow)
  • c60-garmin-gen - poniedziałek w nocy
  • c50-tiles - reimport do kafelków (dopóki nie naprawi się aktualizacja minutowa) - codziennie 5:00-6:30
  • Balansowanie dysków BTRFS (btrfs-ssd-pool, btrfs-tomczk-pool, docker-pool) co tydzień w niedzielę o 7:05-8:00 (powinno trwać znacznie krócej).

Dodawanie użytkowników

Komendy:

sudo adduser <user>
sudo usermod -aG sudo <user>
sudo usermod -aG lxd <user>
su <user>
mkdir .ssh
touch .ssh/authorized_keys
chmod 600 .ssh/authorized_keys
echo "<ssh public key>" >> .ssh/authorized_keys

Użytkownik będzie się mógł logować tylko kluczem SSH. Hasło jest tylko do sudo i użytkownik powinien je sobie zmienić z domyślnego.

Logowanie:

ssh <user>@85.11.120.18 -p <port kontenera na który się loguje>

Sprzęt

  • serwer: IBM System x3630 M3, 64 GB RAM, 16 wątków CPU
  • kontroler dyskowy: ServeRAID M5014

Dyski

Dokumentacja:

megaclisas-status - ogólny stan dysków

-a0 - adapter 0 (jedyny w tym systemie)

-L3 - 3 wirtualny dysk

Przykłady poleceń:

Diagnostyka i informacje

  • Stan 3 wirtualnego dysku
    • megacli -LDInfo -L3 -a0
  • Stan wszystkich dysków fizycznych
    • megacli -PDList -aALL

Dodawanie wirtualnych dysków

  • Dodanie RAID-1 na 2 dyski SSD (1 TB Evo 870):
    • megacli -CfgLdAdd -r1 [31:4,31:5] WB Direct -a0
  • Dodanie RAID-0 na 1 dysk SSD (120 GB):
    • megacli -CfgLdAdd -r0 [31:3] WB Direct -a0

Usuwanie wirtualnych dysków

  • Usuwanie wirtualnego dysku 4 (RAID-0 na 1 dysk SSD 120 GB):
    • megacli -CfgLdDel -L4 -a0

Dodawanie brakującego dysku do macierzy

  • Wstawienie do macierzy x na pozycji y (uwaga: to nie zwykły numer macierzy - The number N of the array parameter is the Span Reference you get using "MegaCli -CfgDsply -aALLâ€� and the number N of the row parameter is the Physical Disk in that span or array starting with zero (it’s not the physical disk’s slot!.") nieużywanego dysku (ważna jest kolejność parametrów!):
    • megacli -PdReplaceMissing -PhysDrv[31:0] -ArrayX -rowY -a0

Przywrócenie wypadłego dysku HDD z macierzy

Dysk 31:2 wypadł z macierzy i jest oznaczony jako Unconfigured(bad):

  • megacli  -PDMakeGood -PhysDrv[31:2] -a0

Adapter: 0: EnclId-31 SlotId-2 state changed to Unconfigured-Good.

  • megacli -PdReplaceMissing -PhysDrv[31:2] -Array3 -row0 -a0

Adapter: 0: Missing PD at Array 3, Row 0 is replaced.

Uwaga: Array3 to nie jest zwykła numeracja macierzy, to się bierze z "The number N of the array parameter is the Span Reference you get using "MegaCli -CfgDsply -aALLâ€� and the number N of the row parameter is the Physical Disk in that span or array starting with zero (it’s not the physical disk’s slot!)."

  • megacli -PDRbld -Start -PhysDrv[31:2] -a0

Started rebuild progress on device(Encl-31 Slot-2)

  • megacli  -PDRbld -ShowProg -PhysDrv[31:2] -a0

Rebuild Progress on Device at Enclosure 31, Slot 2 Completed 1% in 32 Minutes.

Gdyby odbudowa zamulała serwer (a w tym tempie to potrwa pewnie 2-3 doby), to można ją zatrzymać i zapewne potem wznowić przez -Start:

  • megacli -PDRbld -Stop -PhysDrv[31:2] -a0

Można zmniejszyć obciążenie systemu odbudową zmieniając parametr RebulidRate:

  • megacli -AdpGetProp RebuildRate -a0 # odczyt
  • megacli -AdpSetProp RebuildRate "wybrana wartość (w %)" -a0 # nowe ustawienie

obecnie na serwerze jest 80% a to dość dużo.

Kiedy już się skończy odbudowa, to zapewne przywracamy go do stanu Online:

  • megacli -PdOnline -PhysDrv[31:2] -a0

EnclId-31 SlotId-2 state changed to OnLine.

System plików BTRFS

Wszystkie pule BTRFS można wyświetlić przez:

  • btrfs filesystem show

Tworzenie i konfigurowanie BTRFS

Istnieją co najmniej 2 możliwości na konfigurację BTRFS razem z LXD:

Półautomatycznie z użyciem LXD:

  • Polecenie tworzy filesystem i storage: lxc storage create lxd-ssd-pool btrfs source=/dev/disk/by-id/wwn-<dalsze id>:
  • W przypadku błędu jeśli dysk nie był czysty, polecenie zwróci błąd. Taki dysk można wyczyścić: wipefs -a /dev/disk/by-id/<id dysku> UWAGA! TO POWODUJE UTRATĘ DANYCH Z DYSKU!
  • Po dodawaniu puli przez LXC prawdopodobnie storage z LXC jak i sam sam filesystem będą miały tą samą nazwę. Można zmienić etykietę dla BTRFS (choć to jest niepewne – z tym coś bywa nie tak i te nazwy się resetują): btrfs filesystem label /dev/disk/by-id/wwn-<id dysku> <nowa nazwa>

Manualnie (rekomendowane) – zamontować trwale, a następnie zlinkować do LXD:

  • Utworzenie filesystemu: mkfs.btrfs -f -L btrfs-ssd-pool /dev/disk/by-id/wwn-<dalsze id>
  • Edycja /etc/fstab/ i odpowiednie utworzenie folderu pod mountpoint: UUID=1e85ac28-1389-4285-b354-faff04159314 /btrfs-tomczk-pool btrfs compress=zstd:10 0 0, gdzie w tym przypadku:
    • UUID to identyfikator filesystemu BTRFS. Widoczny pod btrfs filesystem show
    • /btrfs-tomczk-pool to miejsce montowania dysku – NIEZMIENIALNE – inaczej to powoduje problemy w LXD. Katalog musi istnieć na dysku.
    • btrfs – filesystem
    • compress=zstd:10 0 0 – dodatkowe parametry, tu akurat wybrany algorytm kompresji zstd o sile 10 na 15
  • Aby sprawdzić poprawność edytowanego pliku fstab można wykonać mount -fav – komenda próbuje zamontować wszystko zgodnie z plikiem a parametr "f" oznacza "fake", więc zmiany są symulowane. Warto to zrobić potem bez "f" przed montowaniem do LXD (inną opcja jest np. reboot).
  • Następnie trzeba zlinkować nowy storage z LXD. Komenda jest taka jak w przypadku półautomatycznego z tą różnicą, że w source podajemy trwałą podmontowaną ścieżkę – w tym przypadku /btrfs-tomczk-pool lxc storage create lxd-tomczk-pool btrfs source=/btrfs-tomczk-pool. Nazwy inne w celu rozróżnienia tego co jest, a nie jest bezpośrednio zarządzane przez LXD.

Czyszczenie i utrzymanie BTRFS

Wadą BTRFS jest to, że lubi sztucznie zapełniać miejsce, mimo jego braku wykorzystania. Ma to miejsce np. w przypadku puli dockerowej. BTRFS ma możliwość sprzątania. Polecenie btrfs balance <path> zwalnia sztucznie zajęte miejsce, aby to zrobić BTRFS musi być zamontowany w systemie. UWAGA przy większym dysku może to długo potrwać. Status wykonywania można zobaczyć w 2 sesji wpisując btrfs balance status -v <path>.

Na serwerze na koncie roota został zdefiniowany cronjob, który uruchamia balance regularnie.

Usuwanie BTRFS

UWAGA ta sekcja może spowodować utratę danych. Ostrożnie!

Jeśli BTRFS był wykorzystywany przez jakiekolwiek oprogramowanie np. LXD, to warto najpierw je stamtąd odłączyć. Można to zrobić poprzez lxc storage delete <nazwa storage>

Następnie można po prostu wyczyścić dysk (o ile BTRFS był na dysku, a nie plikowy) używając wipefs -a /dev/disk/by-id/<id dysku>. Warto pamiętać o usunięciu wpisu z /etc/fstab o ile taki tam był.

System plików ZFS

Porady jak konfigurować ZFS:

Tworzenie i konfiguracja przestrzeni dla całej planety do kafelków pod ZFS:

  • Pula na wirtualny dysk 2x 1 TB Samsung Evo 870 SSD (/dev/sdc):
    • zpool create zfs-ssd /dev/disk/by-id/wwn-0x600605b004f93110284b3fccfae37e03
  • System plików bazy i kafelków (nie pozwala kaskadowo zrobić końcowego):
    • zfs create zfs-ssd/containers
    • zfs create zfs-ssd/containers/c50-tiles
    • zfs create zfs-ssd/containers/c50-tiles/data

Z powodu wielkiej ilości danych prawdopodobnie wszystko pójdzie dla serwera kafelków, więc wszystkie opcje są dopasowane do ich potrzeb i ustawiamy opcje dla całej puli, a nie dla systemu plików:

  • Czas dostępu jest zbędny dla bazy danych - wydłuża czas i zużywa nośnik:
    • zfs set atime=off zfs-ssd
  • Kompresja LZ4 niezbędna, żeby udało się zrobić import planety na 1 TB:
    • zfs set compression=lz4 zfs-ssd
  • Rozmiar rekordu polecany dla PostgreSQL:
    • zfs set recordsize=8K zfs-ssd
  • Opcja polecana dla PostgreSQL:
    • zfs set logbias=throughput zfs-ssd

Podłączenie systemu plików kafelkowych danych pod kontener LXC:

  • Montowanie w miejscu widoczny przez LXC
    • zfs set mountpoint=/var/lib/lxd/storage-pools/zfs-ssd-pool/containers/c50-tiles/data zfs-ssd/containers/c50-tiles/data
  • Montowanie w kontenerze c50-tiles:
    • lxc config device add c50-tiles ssd-data disk source=/var/lib/lxd/storage-pools/zfs-ssd-pool/containers/c50-tiles/data path=/media/data

Usuwanie przestrzeni dla całej planety

Najpierw wyprzęgamy z LXC:

  • lxc config device remove c50-tiles ssd-data

Potem wywalamy z poziomu ZFS (o ile nie ma oczywiście innych kontenerów które z tego korzystają) - pewnie wystarczy hurtem, zamiast po kolei każdy podkatalog:

  • zfs destroy zfs-ssd/containers

Kontenery LXC

Kontenery nieaktywne - do usunięcia?:

  • c30-postgres (zatrzymany) - ?
  • c62-trigar-osmapa-www (zatrzymany) - ?

Ustawianie autostartu dla kontenera c60-garmin-gen:

  • lxc config get c60-garmin-gen boot.autostart # sprawdzenie stanu
  • lxc config set c60-garmin-gen boot.autostart

Lista kontenerów:

  • lxc list

Wchodzenie do kontenera c61-garmin-www:

  • lxc exec c61-garmin-www -- sudo /bin/bash

budynki.openstreetmap.org.pl

Repozytorium GitHub: https://github.com/openstreetmap-polska/gugik2osm

W kontenerze większość jest w lokalizacji /opt/gugik2osm/

Opis ścieżek:

  • /opt/gugik2osm/
    • log - logi aplikacji i procesów przetwarzających dane
    • git - sklonowane repo z githuba
    • app - backend Pythonowy
    • web - frontend HTML+CSS+JS
    • venv - wirtualne środowisko Python z zainstalowanymi bibliotekami
    • imposm3 - folder z danymi programu imposm3, który importuje dane z OSM do bazy PostgreSQL
    • temp* - foldery na dane tymczasowe: pliki PRG, BDOT, etc.
    • conf - pliki konfiguracyjne, pomocne skrypty Bash etc.
  • /var/www/
    • html - symlink do folderu web wspomnianego powyżej
    • data - dodatkowe dane, które użytkownicy mogą pobierać z serwera np pliki geopackage z budynkami z BDOT itp są tam też backupy bazy danych (wystawiane publicznie, bo w tej bazie nie ma nic co nie było by publiczne)
    • overpass-layers - pliki geojson z danymi z Overpass, które można wyświetlić na mapie na stronie

W folderze /opt/gugik2osm/conf/ jest trochę plików które się przydają przy administracji serwerem:

  • cronfile - plik podlinkowany do CRONa, pełna lista odpalanych rzeczy razem ze schedule
  • deploy.sh - plik pobiera zmiany z github i wrzuca je do katalogów backendu i frontendu na serwerze. Załatwia to deployowania prostych zmian. Jeżeli coś wymaga zmian w bazie danych to nie ma automatycznych migracji i wymaga to dodatkowych akcji użytkownika. Ten plik jest odpalany też z CICD Githuba w przypadku dodania do repo Release.
  • deploy_*_mappings.sh - pliki pozwalające szybko wrzucić od bazy zawartość plików CSV z mapowaniem pewnych kategorii/nazw (nazwy ulic, kategorie BDOT)
  • maintenance_mode_on/off.sh - skrypty włączające tyb "maintenance", czyli strona zostaje zastąpiona prostym HTMLem "Trwają prace konserwacyjne" plus odznaczenie flagi w bazie danych, która powinna blokować requesty z backendu
  • services_restart.sh - restartuje serwisy postgresa, imposma, supervisora (gunicorna)

Import danych imposm3 w przypadku gdy chcemy dograć nowe tabelki albo coś:

Aktualizacja postgresa do nowej głównej wersji (np 13->14):

  1. sudo apt upgrade - powinno pobrać samego postgresa kiedy będzie dostępny
  2. sudo apt install postgresql-14-postgis-3 - doinstalowanie nowego postgisa
  3. sudo service imposm stop - zatrzymanie programu imposm3
  4. dobrze też zakomentować w cronfile żeby rzeczy nie chodziły co minutę
  5. sudo -u postgres pg_upgradecluster 13 main - upgrade serwera

c10-http-proxy

Kontener zawiera reverse http proxy, które terminuje SSL i przekierowuje ruch do odpowiednich podstron w innych kontenerach.

Odpowiada za certyfikaty SSL Let's Encrypt. Program certbot pozwala dodawać i odnawiać certyfikaty.

Listowanie certyfikatów: certbot certificates

Procedura tworzenia nowego kontenera

Nazwy kontenerów pochodzą od adresów IP oraz serwisów, które serwują. Adresy IP nadawane są indywidualnie, uznaniowo, staramy się aby poszczególne dziesiątki odpowiadały różnym grupą serwisów.

Procedura na przykładzie kontenera c24-aed-osm-org-pl

  1. Utworzenie nowego kontenera launch ubuntu:20.04 c24-aed-osm-org-pl.
  2. Kopiujemy konfigurację IP z istniejącego kontenera, np c10-http-proxy: lxc exec c10-http-proxy -- cat /etc/netplan/51-cloud-init.yaml. Kopiujemy konfigurację do schowka.
  3. Ustawienie adresu IP w kontenerze: lxc exec c24-aed-osm-org-pl -- nano /etc/netplan/51-cloud-init.yaml. Wstawiamy konfigurację i poprawiamy adres IP na nowy – w tym przypadku: 10.11.12.24. Zapisujemy i restartujemy kontener: lxc restart c24-aed-osm-org-pl. Poleceniem lxc list można sprawdzić, czy kontener używa ustawionego przez nas adresu IP, jeśli nie, to prawdopodobnie jest błąd w pliku (należy pamiętać, o odpowiednich wcięciach).
  4. Aktualizacja kontenera i instalacja potrzebnych pakietów: Wchodzimy do kontenera: lxc shell c24-aed-osm-org-pl, a następnie: apt update && apt upgrade -y && apt install -y nginx. Kontener jest gotowy – wychodzimy ctrl+d.
  5. W kolejnych krokach ustawiamy przekierowanie http w kontenerze z proxy: lxc shell c10-http-proxy
    1. Kopiujemy jakąś istniejącą konfigurację virtualhost-a: cd /etc/nginx/sites-available && cp garmin.osmapa.pl.config aed.openstreetmap.org.pl.config.
    2. W konfiguracji zmieniamy wszystkie wystąpienia starej domeny na nową (tak, wszystkie, te w ścieżkach też).
    3. W sekcji z przekierowaniem ustawiamy adres IP nowo utworzonego kontenera.
    4. Komentujemy tymczasowo całą sekcję dotyczącą https, żeby móc utworzyć certyfikat.
    5. Przed wyjściem kopiujemy do schowka ścieżkę do webroot-a nowego vhosta, zapisujemy config i wychodzimy.
    6. Tworzymy webroot i zmieniamy mu właściciela: mkdir -p /srv/www/aed.openstreetmap.org.pl/public && chown -R www-data:www-data /srv/www.
    7. Linkujemy nową konfigurację i restartujemy nginx: cd ../sites-enabled/ && ln -s ../sites-available/aed.openstreetmap.org.pl.config ., a następnie: service nginx reload.
    8. Wykonujemy próbę pobrania certyfikatu dla nowej domeny:
      1. Dla 1 domeny: certbot certonly --webroot -w /srv/www/aed.openstreetmap.org.pl/public/ -d aed.openstreetmap.org.pl --dry-run
      2. Dla 2+ domen (np. prod i dev): certbot certonly --cert-name aed.openstreetmap.org.pl -a webroot -w /srv/www/aed.openstreetmap.org.pl/public/ -d aed.openstreetmap.org.pl,aed-dev.openstreetmap.org.pl --dry-run
    9. Jeśli próba przebiegnie prawidłowo (IMPORTANT NOTES:- The dry run was successful.) uruchamiamy jeszcze raz, tym razem bez --dry-run: certbot certonly --webroot -w /srv/www/aed.openstreetmap.org.pl/public/ -d aed.openstreetmap.org.pl.
    10. Poleceniem certbot renew --cert-name aed.openstreetmap.org.pl --dry-run możemy sprawdzić, czy certyfikat sam się poprawnie odnowi (przy końcu terminu ważności).
    11. Edytujemy config strony i odkomentowujemy sekcję odpowiedzialną za https.
    12. Restartujemy nginx.


Na tym etapie wszystko powinno już działać prawidłowo. Wchodząc przeglądarką na nowy adres powinniśmy dostać stronę startową nowego serwisu zabezpieczoną po https

Żeby do kontenera można było logować się przez SSH należy dodać użytkownika w kontenerze, dodać mu klucz publiczny SSH oraz na poziomie hosta skonfigurować reguły firehol.

Jeśli to jest nowy projekt publiczny, dodaj go do spisu usług na tej stronie wiki i na stronie polskiej społeczności!

Docker w kontenerze:

Jest możliwa konfiguracja kontenera tak, aby dało się w nim uruchomić kontenery dockerowe, nie jest to wymagane oraz również może przez niektórych być niepolecane. Przykładem kontenera, który używa kontenera jest kontener c80-josm-plbuildings-server. Dynamicznie budowane są 2 oddzielne wersje aplikacji za pomocą docker-compose z serwisami różniącymi się od siebie na podstawie automatycznego deploymentu z githuba (z różnych branchy).

3 linki, które mogą być pomocne (w tym odnośnie do bezpieczeństwa):

W przypadku konfiguracji należy pominąć pierwsze polecenie utworzenia nowego storage'a, ponieważ taki prawdopodobnie się już tam znajduje. Poleceniem lxc storage list można to sprawdzić. Poniżej przekopiowane polecenia dla kontenera "demo":

# demo == nazwa naszego kontenera LXC
lxc storage create docker btrfs  # To należy pominąć jeśli już istnieje
lxc storage volume create docker demo
lxc launch images:ubuntu/20.04 demo  # To również należy pominąć jeśli kontener już istnieje
lxc config device add demo docker disk pool=docker source=demo path=/var/lib/docker
lxc config set demo security.nesting=true security.syscalls.intercept.setxattr=true security.syscalls.intercept.mknod=true
lxc restart demo

2 opcje konfiguracji: security.syscalls.intercept.setxattr=true oraz security.syscalls.intercept.mknod=true nie działają, ponieważ serwer ma starszą wersję kernela (na ten moment < 5.0). Samo nesting należy na ten moment podać bez znaku "=".

WAŻNE: Nie należy:

  • uruchamiać kontenera dockerowego w kontenerze lxc z uprawnieniami roota!
  • uruchamiać serwisów/aplikacji w kontenerach dockerowych z uprawnieniami roota!
  • umożliwiać dostępu z zewnątrz do kontenera dockerowego!

Restart zdalny za pomocą SysRq

Bezpieczny restart, żeby serwer nie zawisł (sprawdzone, faktycznie działa - kocio):

  • bash /root/reboot-sysreq.sh

Opis:

Restart zdalny za pomocą SysRq (kiedy jądro nie panuje nad procesami (zobacz: https://ngelinux.com/what-is-proc-sysrq-trigger-in-linux-and-how-to-use-sysrq-kernel-feature/):

  • echo 1 > /proc/sys/kernel/sysrq # włączenie sysrq
  • echo s > /proc/sysrq-trigger # synchronizacja plików
  • echo u > /proc/sysrq-trigger # odmontowanie systemu plików
  • echo b > /proc/sysrq-trigger # reboot

Zdalny dostęp do terminala IBM IMM

Z powodu starych technologii, dostęp do terminala IMM jest utrudniony. Najpierw należy podłączyć się do VPN od użytkownika użytkownika Zvid, a następnie zalogować się do web panelu. Niektóre przeglądarki mogą nie zezwolić na takie połączenie (na 2023 styczeń, w Firefoxie jest to możliwe).

Do podłączenia się z użyciem VPNa do zdalnego terminala należy zainstalować Javę w wersji 7, pobrać JLNP ze strony IMM z zakładki Tasks->Remote Control->Start Remote Control i uruchomić:

javaws jlnp.jlnp

Środowisko można sobie przygotować używając dockera:

# Host sharowanie Xów z dockerem
xhost +local:*

# Ten 3 mount to jest katalog w którym mamy nasze ISO np. z CloneZillą.
# Wersja ubuntu jest dosyć stara, aby obsługiwać starsze technologie IMM.
docker run --name imm -it -e DISPLAY=$DISPLAY -v /tmp/.X11-unix/:/tmp/.X11-unix/ -v /home/<user>/iso:/iso ubuntu:14.04 bash

# W dockerze
apt-get update && apt-get install -y ssh openjdk-7-jdk icedtea-netx vim

# Kopiujemy zawartość pliku jlnp.jlnp ze strony IMM z zakładki remote control
javaws jlnp.jlnp
# Java powinna być zainstalowana w /usr/lib/jvm/java-1.7.0-openjdk-amd64/bin
# jeśli powyższe by nie działało, to trzeba wejść w tę ścieżkę i stamtąd odpalić ./javaws /jlnp.jlnp
# jeśli nadal nie działa, można sprobować zmienić ustawienia bezpieczeństwa. Jest narzędzie graficzne w katalogu javy (jre) "itweb-settings"

# Po zakończeniu warto wyłączyć sharowanie Xów z dockerem na hoście
xhost -local:*

TODO

  • dodanie brakującego dysku HDD do RAID - zVid (kocio)
  • zmigrowanie stylu osmapa ze starego serwera balroga - nowy kontener c90-osmapa-topo (kocio+balrog):
  • postawienie docelowo wspólnej bazy na c30-postgres na 1 TB SSD - align do partycji: jendrusk (kocio)
  • dodanie brakującego dysku do macierzy systemowej - zVid (NieWnen+kocio)
  • tymczasowy pełny backup dysku systemowego (NieWnen)
  • upgrade systemu Ubuntu 18.04->22.04 (NieWnen + kocio)
  • migracja maszyn LXC z HDD na SSD 1 TB (NieWnen + kocio)
  • dodać diagram architektury dysków po migracji na SSD (NieWnen)
  • wdrożenie automatycznych backupów systemu i kontenerów (możliwe, że wybranych) na HDD po migracji
  • system zdalnego backupu