Pl:Serwer polskiej społeczności
Główny serwer polskiej społeczności jest widoczny pod domeną openstreetmap.org.pl i jest sponsorowany przez CloudFerro.
Najlepszym sposobem kontaktu w sprawach serwerowych jest kanał #serwer-osm-pl na Discord.
Udostępnione usługi
| Strona/Usługa | Repozytorium | Opis | Kontakt |
|---|---|---|---|
| https://osmapa.pl | https://github.com/openstreetmap-polska/osmapa-pl | Starszy styl kafelków osmapa pl (tylko do odczytu) | - |
| https://budynki.openstreetmap.org.pl, | https://github.com/openstreetmap-polska/gugik2osm | Strona z danymi z GUGIKu do importowania (budynki i adresy) | tomczk |
| https://openstreetmap.org.pl | - | Strona stowarzyszenia OpenStreetMap Polska | RicoElectrico |
| https://garmin.osmapa.pl, | https://github.com/openstreetmap-polska/osmapa-garmin | Generator plików mapowych na urządzenia Garmin i strona | Andrzej T. |
| https://josm-plbuildings-server.openstreetmap.org.pl/api/ | https://github.com/praszuk/josm-plbuildings-plugin | Back-end wtyczki do JOSM plbuildings | NieWnen |
| https://dc-rss.openstreetmap.org.pl | - | Bot Discord do śledzenia kanałów RSS (https://monitorss.xyz) | NorthCrab, NieWnen |
Dostęp do serwera poprzez SSH
Konfiguracja klienta (ssh_config)
Host osm
User eouser
HostName 64.225.140.71
Klucz publiczny serwera (known_hosts)
64.225.140.71 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPDnQTkKSfx98UIcrrjaACrBaq/TvHewEaEcc61sH0MD
Udostępnianie dostępu administracyjnego
Serwer akceptuje jedynie logowanie przy pomocy kluczy ssh. Zmiana dozwolonych kluczy odbywa się poprzez edycję pliku .ssh/authorized_keys. Prosimy aby wszystkie klucze posiadały w komentarzu nazwę osoby, do której należą.
Sprzęt
Serwer to maszyna wirtualna w opcji eo2a.xlarge:
- 4 wątki procesora (AMD EPYC)
- 16 GB pamięć RAM
- 64 GB dysk SSD
Posiadamy również dodatkową przestrzeń dyskową HDD o pojemności 1.5 TB.
Oba dyski działają w technologii Ceph, więcej informacji na https://creodias.eu/cloud/cloudferro-cloud/storage-2/.
Serwer posiada dodatkowo skonfigurowany swap file o rozmiarze 12 GB (bez kompresji).
Kopia zapasowa
Co 8 godzin najważniejsze pliki są kopiowane na zewnętrzny serwer, który przechowuje ich zrzut przez 30 dni.
Poniżej znajduje się konfiguracja filtrowania danych (według rclone):
- *.{lock,sock,pid}
- .git/**
- general_log*
- slow_log*
- pg_stat_tmp/**
- diagnostic.data/**
- /opt/caddy/data/**
- /opt/cfp/data/data/{htmlexport,logs}/**
- /opt/cfp/data/public/**
+ /opt/{caddy,cfp,josm-plbuildings-server,monitorss}/**
- /lxd/containers/openstreeetmap-org-pl/rootfs/srv/www/openstreetmap.org.pl/logs/**
+ /lxd/containers/openstreeetmap-org-pl/rootfs/srv/www/**
+ /lxd/containers/openstreeetmap-org-pl/rootfs/var/lib/mysql/**
- *
Kontakt w sprawach kopii zapasowych: NorthCrab.
System plików BTRFS (tymczasowo nieaktualne)
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 (tymczasowo nieaktualne)
Porady jak konfigurować ZFS:
- https://jrs-s.net/2018/08/17/zfs-tuning-cheat-sheet/
- https://openzfs.readthedocs.io/en/latest/performance-tuning.html#postgresql
- https://vadosware.io/post/everything-ive-seen-on-optimizing-postgres-on-zfs-on-linux/
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 (tymczasowo nieaktualne)
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):
- sudo apt upgrade - powinno pobrać samego postgresa kiedy będzie dostępny
- sudo apt install postgresql-14-postgis-3 - doinstalowanie nowego postgisa
- sudo service imposm stop - zatrzymanie programu imposm3
- dobrze też zakomentować w cronfile żeby rzeczy nie chodziły co minutę
- 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
- Utworzenie nowego kontenera launch ubuntu:20.04 c24-aed-osm-org-pl.
- 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.
- 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).
- 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.
- W kolejnych krokach ustawiamy przekierowanie http w kontenerze z proxy: lxc shell c10-http-proxy
- Kopiujemy jakąś istniejącą konfigurację virtualhost-a: cd /etc/nginx/sites-available && cp garmin.osmapa.pl.config aed.openstreetmap.org.pl.config.
- W konfiguracji zmieniamy wszystkie wystąpienia starej domeny na nową (tak, wszystkie, te w ścieżkach też).
- W sekcji z przekierowaniem ustawiamy adres IP nowo utworzonego kontenera.
- Komentujemy tymczasowo całą sekcję dotyczącą https, żeby móc utworzyć certyfikat.
- Przed wyjściem kopiujemy do schowka ścieżkę do webroot-a nowego vhosta, zapisujemy config i wychodzimy.
- 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.
- Linkujemy nową konfigurację i restartujemy nginx: cd ../sites-enabled/ && ln -s ../sites-available/aed.openstreetmap.org.pl.config ., a następnie: service nginx reload.
- Wykonujemy próbę pobrania certyfikatu dla nowej domeny:
- Dla 1 domeny: certbot certonly --webroot -w /srv/www/aed.openstreetmap.org.pl/public/ -d aed.openstreetmap.org.pl --dry-run
- 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
- 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.
- 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).
- Edytujemy config strony i odkomentowujemy sekcję odpowiedzialną za https.
- 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):
- https://discuss.linuxcontainers.org/t/run-docker-in-lxc-is-secure/1962
- https://discuss.linuxcontainers.org/t/how-to-run-docker-inside-lxc-container/13017/8
- https://www.youtube.com/watch?v=_fCSSEyiGro – zawiera przykład uruchomienia.
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 demo2 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 (tymczasowo nieaktualne)
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 (tymczasowo nieaktualne)
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:*
Lista rzeczy do zrobienia
Ostatnia aktualizacja: 2024-08-28
- Dokończenie migracji na serwer CloudFerro (w trakcie)
- Do przeniesienia pozostała instancja garmina
- NorthCrab: Oczekuję na dostęp DNS domen osmapa.pl oraz openstreetmap.pl.
- Aktualizacja tej strony wiki
- Wraz z postępem migracji