Takovej selfhosting Notionu bez fancy tabulek.
Outline je open-source nástroj pro tvorbu a správu interní dokumentace a znalostních bází.

Použité technologie

Nginx

Nginx je výkonný webový server a reverzní proxy, který se používá pro obsluhu statického obsahu, směrování požadavků na backend služby a vyvažování zátěže. Je známý svou rychlostí, nízkou spotřebou paměti a spolehlivostí při vysoké zátěži.

Outline

Outline je open-source nástroj pro tvorbu a správu interní dokumentace a znalostních bází. Poskytuje jednoduché a přehledné uživatelské rozhraní pro týmovou spolupráci, verzování a rychlé vyhledávání obsahu.

Dex

Dex je open-source identitní služba, která funguje jako „OpenID Connect“ provider. Slouží k centralizovanému ověřování uživatelů a umožňuje propojit různé aplikace s externími identity providery (např. Google, GitHub nebo LDAP).

Postgres

PostgreSQL (Postgres) je pokročilý open-source relační databázový systém. Nabízí podporu pro komplexní dotazy, transakce, indexy, JSON data a rozšiřitelnost pomocí vlastních funkcí, čímž se hodí pro širokou škálu aplikací od menších po enterprise řešení.

Redis

Redis je in-memory databáze a cache systém, který umožňuje velmi rychlý přístup k datům. Často se používá pro ukládání relací, front, výsledků výpočtů nebo jako prostředník pro komunikaci mezi službami díky podpoře publikace a odběru zpráv (pub/sub).

Docker / Docker Compose

Docker je platforma pro kontejnerizaci aplikací, která umožňuje spouštět software izolovaně s veškerými závislostmi. Docker Compose pak usnadňuje definování a správu vícekontejnerových aplikací pomocí jednoduchého konfiguračního souboru.

Diagram

Postřehy

Outline

Outline neumožňuje přihlašování pomocí uživatelského jména a hesla, což je poněkud nepříjemné. Musí se nakonfigurovat jedna z podporovaných služeb. Aplikace umí pracovat se Slack identitami, Google identitami a dalšími poskytovateli. Pokud nemůžete použít žádnou z těchto služeb, je tam naštěstí možnost Magic Link via Email. Je to sice nepříjemné, ale funkční řešení. Pokaždé, když se chcete přihlásit, pošle vám aplikace email s přihlašovacím odkazem. V mém setupu jsem se rozhodl použít Dex jako OIDC službu, přes kterou se mohu přihlašovat pomocí emailu a hesla.

Dex

Dex je velmi minimalistický, takže nemá webové rozhraní. Navíc jeho dokumentace je hodně nekvalitní. Nejjednodušším způsobem, jak vše rozchodit, je přidat statického klienta a uživatele přímo do konfiguračního souboru. Musíte si ale vytvořit bcrypt hashovaná hesla. Vycházel jsem z tohoto návodu.

SMTP

Aby fungovalo odesílání emailů, je potřeba nakonfigurovat SMTP server. Pokud žádný po ruce nemáte, můžete použít váš Gmail účet. V nastavení Gmailu se musí vytvořit aplikační klíč, který se pak vloží do .env souboru do SMTP sekce.

Setup

.env

URL=https://outline.<domain.com>
PORT=3050
WEB_CONCURRENCY=1
SECRET_KEY=<secret key>
UTILS_SECRET=<utils secret>
DATABASE_URL=postgres://outline:<db password>@outline-postgres:5432/outline
PGSSLMODE=disable

POSTGRES_USER=outline
POSTGRES_PASSWORD=<db password>
POSTGRES_DB=outline

REDIS_URL=redis://outline-redis:6379

FILE_STORAGE=local

FORCE_HTTPS=true

OIDC_CLIENT_ID=outline
OIDC_CLIENT_SECRET=<oidc client secret>
OIDC_AUTH_URI=https://auth.<domain.com>/dex/auth
OIDC_TOKEN_URI=http://dex:5556/dex/token
OIDC_USERINFO_URI=http://dex:5556/dex/userinfo
OIDC_USERNAME_CLAIM=email
OIDC_DISPLAY_NAME=OIDC Provider
OIDC_SCOPES=openid profile email

SMTP_SERVICE=gmail
SMTP_USERNAME=<you>@gmail.com
SMTP_PASSWORD="<app code>"
SMTP_FROM_EMAIL=<you>@gmail.com

RATE_LIMITER_ENABLED=true
RATE_LIMITER_REQUESTS=1000
RATE_LIMITER_DURATION_WINDOW=60

ENABLE_UPDATES=true
DEBUG=http
LOG_LEVEL=info

DEX Config (config.yaml)

issuer: https://auth.<domain.com>/dex

storage:
  type: sqlite3
  config:
    file: /var/dex/dex.db

web:
  http: 0.0.0.0:5556

staticClients:
  - id: outline
    redirectURIs:
      - "https://outline.<domain.com>/auth/oidc.callback"
    name: "Knowledge Base"
    secret: <oidc client secret>

oauth2:
  skipApprovalScreen: true

enablePasswordDB: true

staticPasswords:
  # Admin
  - email: "<admin>@gmail.com"
    hash: "<bcrypt password hash>"
    username: "admin"
    userID: "admin-001"

  - email: "<user>@gmail.com"
    hash: "<bcript password hash>"
    username: "user"
    userID: "user-001"

# Pro debug
logger:
  level: "info"
  format: "text"

Docker Compose

services:
  outline:
    image: docker.getoutline.com/outlinewiki/outline:latest
    env_file: ./.env
    ports:
      - "3050:3050"
    expose:
      - "3050"
    volumes:
      - storage-data:/var/lib/outline/data
    depends_on:
      - outline-postgres
      - outline-redis

  outline-redis:
    image: redis
    env_file: ./.env
    expose:
      - "6379"
    volumes:
      - ./redis.conf:/redis.conf
    command: ["redis-server", "/redis.conf"]
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 30s
      retries: 3

  outline-postgres:
    image: postgres
    env_file: ./.env
    expose:
      - "5432"
    volumes:
      - database-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD", "pg_isready", "-d", "outline", "-U", "user"]
      interval: 30s
      timeout: 20s
      retries: 3

  dex:
    image: dexidp/dex:v2.37.0
    ports:
      - "5556:5556"  # Vystaveno pro nginx proxy
    expose:
      - "5556"
    volumes:
      - ./dex-config:/etc/dex:ro  # Read-only mount konfigurace
      - dex-data:/var/dex         # Persistentni SQLite databáze
    command: ["dex", "serve", "/etc/dex/config.yaml"]
    healthcheck:
      test: ["CMD", "wget", "--no-verbose", "--tries=1", "--spider", "http://localhost:5556/dex/healthz"]
      interval: 30s
      timeout: 10s
      retries: 3
    restart: unless-stopped

volumes:
  storage-data:
  database-data:
  dex-data:

Nginx

auth.

server {
    listen 80;
    server_name auth.<domain.com>;

    # P┼Öesm─Ťrov├ín├ş HTTP na HTTPS
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name auth.<domain.com>;

    # SSL certifik├íty (upravte cestu podle va┼í├ş konfigurace)
    ssl_certificate /etc/nginx/ssl/<domain.com>/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/<domain.com>/privkey.pem;

    # SSL konfigurace
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;

    # Proxy nastaven├ş pro Home Assistant
    location / {
        proxy_pass http://<service ip>:5556;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # Timeout nastaven├ş
        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;

        # Buffering nastaven├ş
        proxy_buffering off;
        proxy_request_buffering off;
    }

    # Logov├ín├ş
    access_log /var/log/nginx/auth.<domain.com>.access.log;
    error_log /var/log/nginx/auth.<domain.com>.error.log;
}

outline.

server {
    listen 80;
    server_name outline.<domain.com>;

    # P┼Öesm─Ťrov├ín├ş HTTP na HTTPS
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name outline.<domain.com>;

    # SSL certifik├íty (upravte cestu podle va┼í├ş konfigurace)
    ssl_certificate /etc/nginx/ssl/<domain.com>/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/<domain.com>/privkey.pem;

    # SSL konfigurace
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;

    # Proxy nastaven├ş pro Home Assistant
    location / {
        proxy_pass http://<service ip>:3050;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # Timeout nastaven├ş
        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;

        # Buffering nastaven├ş
        proxy_buffering off;
        proxy_request_buffering off;
    }

    # Logov├ín├ş
    access_log /var/log/nginx/outline.<domain.com>.access.log;
    error_log /var/log/nginx/outline.<domain.com>.error.log;
}

The post Outline – selfhostovaná znalostní báze first appeared on Hard Wired.

Článek navazuje na Gitea v Dockeru s daty na Synology a Gitea na veřejné subdoméně. Tentokrát si ukážeme, jak vytvořit nový soukromý repozitář a posílat do něj změny.

Předpoklady

• Máme funkční Giteu na vlastní subdoméně, do které se dokážeme přihlásit
• Byly provedeny všechny kroky z předchozích návodů
• Článek se zaměřuje na Windows ale na Linuxu to bude to samé nebo hodně podobné
• Na počítači máme funkční SSH a GIT.

Vytvoření soukromého repozitáře

Přihlásíme se do naší Gitey. Pluskem zvolíme nový repozitář. Zadáme název repozitáře, soukromy-repo-na-smazani. Vybereme Nastavit repozitář jako soukromý a potvrdíme. Vytvoří se prázdný repozitář.

Vytvoření SSH klíče

Pro komunikaci s repozitářem budeme používat SSH. Budeme muset vytvořit pár klíčů, soukromý a veřejný. Soukromý bude u nás na počítači a veřejný budeme nahrajeme k repozitáři, jako přístupový.

Ujistíme se že v c:\Users\<username> máme složku .ssh. Poté v terminálu zadáme příkaz na vygenerování klíče pro přístup do Gitea.

ssh-keygen -t rsa -b 4096 -C "<váš email>" -f ~/.ssh/gitea-example-com

To ve složce .ssh vytvoří dva soubory. gitea-example-com a gitea-example-com.pub. Ten druhý musíme nahrát k repozitáři.

Přidání klíče do Gitea repozitáře

Otevřeme si repozitář. Nastavení > Klíče pro nasazení > Přidat klič pro nasazení. Pojmenujeme si ho, například Domácí klíč. A obsah gitea-example-com.pub zkopírujeme do pole Obsah. Nesmíme zapomenout zaškrtnout volbu Povolit zápis a potvrdit.

Nastavení SSH na počítači

Pokud ve složce c:\Users\<username>\.ssh nemáte soubor config, vytvořte ho a přidejte následující.

Host gitea.example.com
  HostName gitea.example.com
  User git
  Port 222
  IdentityFile c:\Users\<username>\.ssh\gitea-example-com
  IdentitiesOnly yes

Pro hosta gitea.example.com se nastaví odpovídající host name, uživatel, port pro připojení a cesta k privátnímu klíči. Volba IdentitiesOnly zajistí, že pro konkrétního hosta se použijí parametry, které jsou nastaveny.

Připojení repozitáře

Buď můžete připojit už existující repozitář z vašeho počítače, nebo vytvoříte nový. Vytvoříme nový.

Vytvořte složku kde bude nový repozitář. Obecně se pojmenuje názvem repozitáře co jsme vytvořili na naší Gitea.

mkdir soukromy-repo-na-smazani

Přesuneme se do něj.

cd soukromy-repo-na-smazani

Inicializujeme prázdný repozitář.

git init

Vytvoříme první soubor README.md.

touch README.md

Vytvoříme hlavní větev main.

git checkout -b main

Přidáme soubor README.md do git repozitáře.

git add README.md

Vytvoříme první commit.

git commit -m "První commit"

Napojíme náš repozitář z Gitea.

git remote add origin git@gitea.example.com:<gitea username>/soukromy-repo-na-smazani.git

Odešleme změny do vzdáleného repozitáře.

git push -u origin main

Když se nyní podíváme do repozitáře na gitea.example.com, uvidíme náš první commit.

The post Gitea a první soukromý repozitář first appeared on Hard Wired.

Volné pokračování Gitea v Dockeru s daty na Synology. Tentokrát nastavíme aby nám naše self-hostovaná Gitea jela na naší veřejné doméně.

Předpoklady

• Máme nainstalovanou Giteu podle předchozího návodu.
• Máme koupenou vlastní doménu. (pro tutoriál to bude example.com)
• Používáme Nginx jako reverzní proxy.
• Máme přistup do routeru nebo možnost přesměrovávat porty.
• Už jste Giteu jednou spustili a nastavili admin účet.

Nastavení reverzní proxy

Vytvoříme soubor gitea.example.com.

nano /etc/nginx/sites-available/gitea.example.com

server {
    listen 80;
    server_name gitea.example.com;

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl;
    server_name gitea.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        proxy_pass http://:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Při zadání gitea.example.com budou všechny požadavky přesměrovávány na server, kde sedí Gitea a naslouchá na portu 3000. Také se automaticky provede přesměrování z HTTP na HTTPS.

Certifikáty jsou pomocí Let's Encrypt a Certbot, ale to je na jiný návod.

Poté je potřeba dostat symlink do /etc/nginx/sites-enabled.

sudo ln -s /etc/nginx/sites-available/gitea.example.com /etc/nginx/sites-enabled/

Pak je dobré zkontrolovat, jestli Nginx naši novou konfiguraci vezme za svou.

sudo nginx -t

Jestli je vše OK, tak bude potřeba Nginx restartovat.

sudo systemctl restart nginx

Od teď bude gitea.example.com směrovat na naši Giteu.

Nastavení Gitea

Předpoklad je, že Gitea běží v kontejneru. Musíme upravit nastavení. Do Docker kontejneru se můžete dostat pomocí příkazové řádky docker exec -it <container_name_or_id> /bin/bash. Pokud máte rozchozený Portainer, stačí v něm kliknout na ikonku shellu a připojíte se do kontejneru jako root.

Po připojení do kontejneru bude pravděpodobně jako uživatel root. Gitea (v závislosti na typu image) má data uložena v /data. Ale jako uživatel git. Proto než začnete něco měnit, tak je dobré se přepnout za uživatele git. To provedete pomocí su git.

Bude potřeba udělat pár úprav v souboru app.ini, ten se nachází v /data/gitea/conf. (v Gitea kontejneru je dostupný editor VI)

DOMIAN = gitea.example.com
SSH_DOMAIN = gitea.example.com
ROOT_URL = https://gitea.example.com

Tím nastavíme Giteu na naši doménu.

Je předpoklad, že je to soukromý git server, takže nechceme aby se tam mohli lidé samovolně registrovat. Takže je potřeba vypnout registrace.

DISABLE_REGISTRATIONS = true

Poté je potřeba kontejner restartovat.

Přesměrování portů

Gitea cotainer (pokud jste to nezměnili) propaguje porty 3000 (web) a 222 (ssh). Proto je potřeba zajistit aby byl port 222 zvenku dostupný a přesměrovával na server kde Gitea sedí. Jestli máte domácí router který sedí na veřejné IP adrese tak provedete přesměrování portů na něm.

Závěr

Existují ještě další nastavení, ale po těchto pár krocích by už měla Gitea fungovat na vaší doméně.

The post Gitea na veřejné subdoméně first appeared on Hard Wired.

Gitea je self-hostovaná varianta Bitbucketu nebo GitHubu. V následujícím krátkém návodu se podíváme jak nainstalovat Giteu pomocí Dockeru a ukládat data na Synology NAS.

Prerekvizity

• Nainstalovaný a nastavený Docker
• Nainstalovaný a nastavený Synology NAS

Myšlenka

Pro spuštění Gitea serveru použijeme docker compose. Gitea bude používat PostgreSQL databázi. Pro ukládání dat jak pro Giteu, tak i pro Postgres, použijeme docker volumes. Docker volumes nebudou lokální, ale přes protokol NFS budou směřovat na Synology NAS.

Pro potřeby tutoriálu bude mít server IP adresu 192.168.10.1 a Synology NAS 192.168.10.2.

Nastavení Synology

Ovládací panel > Souborové služby > NFS povolte službu NFS.

Ovládací panel > Sdílená složka > Vytvoření sdílené složky. Název docker-volumes. Nepřiřazujeme oprávnění pro uživatele nebo skupiny.

Klikneme na složku docker-volumes a zvolíme upravit. Poté Oprávnění NFS. Klikneme na tlačítko Vytvořit. Do pole Název hostitele nebo IP adresa vložíme IP adresu našeho serveru, tedy 192.168.10.1. Tím umožníme našemu serveru přístup k této složce. Dále nastavíme:

• Oprávnění: Čtení/Zápis
• Squash: Žádné mapování
• Zabezpečení: sys
• Povolit asynchronní
• Povolit připojení z portů bez oprávnění (porty vyšší než 1024)
• Umožňuje uživatelům přístup k připojeným podsložkám

A uložíme.

Poté otevřeme File Station a v naší složce docker-volumes vytvoříme následující podsložky:

• gitea-data
• gitea-postgres

To je na Synology vše.

docker-compose.yaml

Konfigurační soubor vytvoří síť gitea kde na sebe uvidí kontejnery gitea a gitea-db. Vytvoří dva volumes a pomocí protokolu NFS je nasměruje na námi sdílenou složku v Synology NAS.

Docker-compose soubor můžeme spustit pomocí docker-compose up -d. Pokud máte na serveru nainstalovaný a spuštěný Portainer, tak jde docker-compose konfigurace spustit jako stack.

Webové rozhraní poté bude přístupné na http://192.168.10.1:3000.

networks:
  gitea:

volumes:
  gitea-data:
    driver: local
    driver_opts:
      type: nfs
      o: addr=192.168.1.251,rw
      device: ":/volume1/docker-volumes/gitea-data"

  gitea-postgres:
    driver: local
    driver_opts:
      type: nfs
      o: addr=192.168.1.251,rw
      device: ":/volume1/docker-volumes/gitea-postgres"

services:
  server:
    image: gitea/gitea:latest
    container_name: gitea
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - GITEA__database__DB_TYPE=postgres
      - GITEA__database__HOST=gitea-db:5432
      - GITEA__database__NAME=gitea
      - GITEA__database__USER=gitea
      - GITEA__database__PASSWD=supersecretpassword
    restart: always
    networks:
      - gitea
    volumes:
      - gitea-data:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "3000:3000"
      - "222:22"
    depends_on:
      - gitea-db

  gitea-db:
    image: postgres:16
    container_name: gitea-db
    restart: always
    environment:
      - POSTGRES_USER=gitea
      - POSTGRES_PASSWORD=supersecretpassword
      - POSTGRES_DB=gitea
    networks:
      - gitea
    volumes:
      - gitea-postgres:/var/lib/postgresql/data

The post Gitea v Dockeru s daty na Synology first appeared on Hard Wired.

O co jde

Uděláme bota co načte webovou stránku, klikne na čudlík a stáhne soubor.

Použijeme k tomu knihovnu Puppeteer a samotný kód budeme pouštět v Dockeru.

Větší podrobnosti a vysvětlení zakládání NodeJs projektu v Dockeru najde v článku NodeJS develompent v Dockeru.

Příprava projektu

Založíme nový projekt:

mkdir puppet
cd puppet
npm init -y

Upravíme package.json a přidáme do něj knihovnu puppeteer:

{
  "name": "puppet",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "start": "node index.js"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "puppeteer": "^19.2.0"
  }
}

Vytvoříme Dockerfile, který použije jako základ obraz s node v16, nainstaluje Chrome prohlížeč a nakopíruje projekt do Docker obrazu.

FROM node:16

RUN apt-get update && apt-get install gnupg wget -y && \
  wget --quiet --output-document=- https://dl-ssl.google.com/linux/linux_signing_key.pub | gpg --dearmor > /etc/apt/trusted.gpg.d/google-archive.gpg && \
  sh -c 'echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list' && \
  apt-get update && \
  apt-get install google-chrome-stable -y --no-install-recommends && \
  rm -rf /var/lib/apt/lists/*

ENV PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true \
    PUPPETEER_EXECUTABLE_PATH=/usr/bin/google-chrome-stable

WORKDIR /app
COPY package*.json .
RUN npm install
COPY . ./

Vytvoříme index.js soubor a necháme ho jen vypsat zprávu do konzole.

touch index.js

console.log('Hello from docker')

Není úplně špatné vytvořit i .dockerignore soubor.

node_modules
Dockerfile
.dockerignore
.git
.gitignore
README.md
docker-compose*

Sestavíme obraz.

docker build -t puppet-app-image .

A spustíme Docker kontejner.

# %cd% je aktuální složka ve Windows, pro jiné systémy použijte adekvátní náhradu

docker run -d --tty --name puppet-app -v %cd%:/app -v /app/node_modules puppet-app-image

--tty parametr je nutný. V opačném případě se Docker kontejner spustí a pak hned úspěšně ukončí. Za normálních okolností předpokládá, že v něm něco poběží a až se to ukončí tak skončí taky. TTY toto chování potlačí.

Jakmile kontejner běží, můžeme se do něj přihlásit:

docker exec -it puppet-app bash

Vevnitř se ocitneme ve složce /app, kde je náš projekt a můžeme zkusit spustit náš program.

nodejs index.js

Měl by nám odpovědět Hello from docker.

Bot

Pro ukázku bude bot stahovat zdrojový kód puppeteeru z githubu. Upravíme index.js následovně.

const puppeteer = require('puppeteer')

;(async () => {
    const browser = await puppeteer.launch({
        headless: true,
        args: ['--no-sandbox'],
    })

    const page = await browser.newPage()
    page.setViewport({ width: 1920, height: 1080 })

    const client = await page.target().createCDPSession()
    await client.send("Page.setDownloadBehavior", {
        behavior: "allow",
        downloadPath: './'
    })

    await page.goto(
        'https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v19.2.0',
        { waitUntil: 'networkidle2' }
    )
    await page.waitForTimeout(1000)

    await page.click('#repo-content-turbo-frame div.mb-3 > details > div > div > ul > li:nth-child(1) > div.d-flex.flex-justify-start.col-12.col-lg-9 > a')
    await page.waitForTimeout(5000)

    await page.screenshot({ path: './screen.jpg', fullPage: true })

    await browser.close()
})()

Naimportujeme do našeho projektu knihovnu puppeteer.

const puppeteer = require('puppeteer')

Budeme volat asynchronní funkce v java scriptu a budeme používat klíčové slovo await, které čeká na provedení asynchronní funkce. Problém je to, že await se může objevit jen v asynchronní funkci. Tudíž náš kód musíme do jedné takové zabalit a rovnou spustit.

;(async () => {
    // code
})()

Vytvoříme nový headless prohlížeč.

const browser = await puppeteer.launch({
    headless: true,
    args: ['--no-sandbox'],
})

Vytvoříme novou stránku/tab a nastavíme rozlišení.

const page = await browser.newPage()
page.setViewport({ width: 1920, height: 1080 })

Pro tuto konkrétní stránku nastavíme automatické stahovaní do určitého adresáře. V našem případě adresář s projektem. Takhle nebudeme vyvolávat dialog pro umístění stahovaného souboru.

const client = await page.target().createCDPSession()
await client.send("Page.setDownloadBehavior", {
    behavior: "allow",
    downloadPath: './'
})

V naší stránce/tabu otevřeme požadovanou github stránku.

await page.goto(
    'https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v19.2.0',
    { waitUntil: 'networkidle2' }
)
await page.waitForTimeout(1000)

Klikneme na odkaz pro stažení a chvíli počkáme, než se soubor stáhne

await page.click('#repo-content-turbo-frame div.mb-3 > details > div > div > ul > li:nth-child(1) > div.d-flex.flex-justify-start.col-12.col-lg-9 > a')
await page.waitForTimeout(5000)

K definování toho na co se má kliknout se používá CSS Selector (draft, mdn). Ten pomocí html elementů, tříd, atributů a dalších dokáže sestavit unikátní cestu k prvku na stránce. Stránky generované nějakým frameworkem umí potrápit i s takhle dlouhým selektorem, jako v tomto případě.

Pak už si jen uděláme momentku, v jakém stavu stránku opouštíme.

await page.screenshot({ path: './screen.jpg', fullPage: true })

A prohlížeč korektně zavřeme.

await browser.close()

Spuštění kódu

V konzoli se připojíme k našemu kontejneru.

docker exec -it puppet-app bash

A spustíme našeho bota.

node index.js

Pokud vše proběhne, jak má, tak ve složce projektu budete mít jak stažený soubor, tak fotku stránky těsně před tím než jste ji opustili.

Toto je velice hrubý nástřel toho, co Puppeteer dokáže na konkrétním případě. Výhodou je, že se opravdu spustí prohlížeč, ve kterém můžeme ovládat i dynamicky generované single page aplikace. Nevýhodou je, že pokud se struktura stránky změní moc, tak musíte upravit i váš kód.

Happy coding!

The post Puppeteer download BOT first appeared on Hard Wired.

Pokud se motáte okolo webového vývoje (frontendy, api a pod...) a používáte JavaScript (respektive NodeJS), tak jste se určitě už setkali s následujícím problémem. Různé projekty jsou napsány pod různými verzemi programovacího jazyka a ne vždy je možné vše upgradovat na poslední verzi.

• Můžete používat knihovny, které ještě nejsou upraveny pro novou verzi.
• Starší verze frameworku s poslední verzí jazyka nefunguje.
• Zpětná nekompatibilita.
• Prostě nejsou peníze nebo není čas zabývat se přechodem a přepisem aplikace na poslední verzi.

Důvodů může být milión, ale klíčové je to, že pokud jste to vy co musí do těchto projektů zasahovat, tak musíte provozovat více verzí jazyka.

Pokud se potýkáte s tímto problémem, tak nehledě na jakém operačním systému se nacházíte, budou scénáře podobné.

Scénář 1 - Jedna verze v systému

Tohle je pro popisovaný problém asi nejhorší situace. Máte v systému jednu verzi jazyka. Všechny projekty, na kterých pracujete, musejí běžet pod touhle verzí. Zpravidla to skončí tak, že verze jazyka bude taková, jakou potřebuje ten nejstarší (legacy) projekt. Může vás to zablokovat na tolik, že nebudete moci použít poslední verze frameworků nebo poslední funkcionalitu, protože nebudou tak starou verzi jazyka podporovat.

Scénář 2 - NVM

Node Version Manager (NVM) je utilita, která vám umožní provozovat více verzí jazyka na jednom stroji a přepínat mezi nimi. Existuje jak pro Linux, MacOs, tak i pro Windows. Ve chvíli kdy se přepínáte mezi verzemi a používáte současně jednu, je to přímočaré a elegantní řešení. Ve chvíli, kdy potřebujete mít několik projektů puštěných naráz, pod různými verzemi jazyka, už samozřejmě vyžaduje určitou míru konfigurace. Ale zrovna k tomuto scénáři nemám moc co říct, protože jsem provozoval jen tu nejprimitivnější formu čistě přepínání mezi verzemi. Každopádně se jedná o funkční řešení.

Scénář 3 - Vagrant

Vagrant od HashiCorp používá pro oddělení prostředí virtualizaci. Vytvoříte předpis, který nakonfiguruje virtuální stroj, ve kterém následně aplikaci vyvíjíte. Je možné nakonfigurovat celý ekosystém, aplikace, databáze, cache atd. Teoreticky je to geniální věc. Nehledě na systém máte předpis, který spustíte na jakémkoliv systému a vytvoří vám stejné prostředí pro vývoj. V praxi to už tak veselé nebylo. Je pravda, že jsem Vagrant použil naposledy před několika lety. Problémy byly zpravidla nějaká specifika operačních systému, zvláště Windows. Nebo situace co se musely řešit "hackem", protože ještě neexistovalo nativní řešení a samozřejmě hromada virtuálních mašin, když bylo prostředí pro vývoj rozsáhle. I tak jsem na tom byl nějakou dobu schopný vyvíjet a šlo to docela dobře. Čas pokročil a určitě byla hromada věcí dotažena. Určitě se jedná o funkční řešení.

Scénář 4 - Docker

Jak už název článku napovídá, budeme řešit Docker. Docker používá kontejnery. Kontejner je softwarová jednotka, která zapouzdřuje kód i s jeho závislostmi. Na rozdíl od standardní virtualizace, nerozebíhá znovu celý operační systém, ale používá operační systém hostitele. Nejlíp to asi vysvětlí přímo citace ze stránek Dockeru.

A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another. A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings.

Container images become containers at runtime and in the case of Docker containers – images become containers when they run on Docker Engine. Available for both Linux and Windows-based applications, containerized software will always run the same, regardless of the infrastructure. Containers isolate software from its environment and ensure that it works uniformly despite differences for instance between development and staging.

from https://www.docker.com/resources/what-container/

V praxi to znamená, že máte v kontejneru souborový systém operačního systému dle libosti. Doinstalujete si potřebné balíčky pro běh vašeho projektu a tento kontejner můžete izolovaně pouštět tam, kde jsou kontejnery podporované. Speciálně Docker funguje pod Linuxem, MacOs i Windows.

+------------++-----------+
|    APP1    ||   APP2    |
+------------++-----------+
+------------++-----------+
|  Bin/Libs  ||  Bin/Libs |
+------------++-----------+
+-------------------------+
|         Docker          |
+-------------------------+
+-------------------------+
|    Operační systém      |
+-------------------------+
+-------------------------+
|         Server          |
+-------------------------+

"Back in my days", když jsem si chtěl na serveru rozjet nějaké služby, buď jsem provozoval nějakou virtualizaci nebo jsem to všechno naplácal do jednoho operačního systému. Jedno ze zásadních úskalí bylo to, že různé služby potřebovaly různé balíky, verze knihoven a míru konfigurace. Pokud člověk nebyl dostatečně obezřetný mohl si "roze***t" celý systém a vše poslat do kytek. V lepším případě byla mašina v jakémsi meta ezo stavu, kdy něco jelo a něco ne.

S Dockerem hromada problémů opadla. Každá služba je izolovaný kontejner, který si své závislosti bere sebou. Pokud něco nefunguje, vadný kontejner se vymaže, ale vše ostatní jede dál. Drtivé množství běžných služeb (wiki, databáze, ...) mají už dnes nachystané a nakonfigurované obrazy. V uvozovkách je stačí jen spustit. Jako všechno si to sebou nese i negativa. Neaktualizované knihovny v kontejneru jsou bezpečnostní riziko. Nebo pokud si nevytváříte kontejner sami tak musíte důvěřovat autorovi, že tam nenasadil nějakou breberku. Ale vždy je něco za něco.

Jak už asi tušíte, z tohoto stručného popisu, použití pro výše popsaný problém bude jasné. Vytvoří se pro projekt Docker kontejner a tak budou všechny závislosti projektu izolovány od hlavního operačního systému. Takhle můžete mít pohodlně puštěné aplikace pod různou verzí NodeJS na jednom stroji. Je to v podstatě jako Vagrant, VirtualBox nebo obecně virtualizace. Akorát teda ne tak úplně.

Nešpinit systém, na kterém vyvíjíte, závislostmi projektu je podle mě dlouhodobě udržitelná cesta.

Plus mají kontejnery dnes ještě jednu výhodu. Cloudové služby vám zpravidla umožňují posílat kontejnery i do produkce.

Čestná zmínka

Výše uvedené scénáře nejsou určitě jediné, ale jsou to ty, se kterými jsem se setkal osobně.

Minimálně ještě existuje možnost vyvíjet na vzdáleném operačním systému přes SSH. Visual Studio Code tento vzdálený vývoj umožňuje. Jako taky možnost, ale za mě teda trochu exotická. Ale když není zbytí, lepší než drátem do oka.

NodeJS projekt v Dockeru

Toto není kompletní návod pro člověka, který se v životě neotřel o Docker nebo o NodeJS a vývoj API. Do takových podrobností článek nejde. Zabývá se jak rozjet projekt v Dockeru a předpokládá už určité znalosti. Pardon.

V první řadě budeme potřebovat nainstalovat Docker. Případně na desktopu (a hlavně na Windows) to bude Docker Desktop.

Pokusíme se rozjet vývoj REST API s použitím ExpressJs.

Pro náš projekt budeme mít následující strukturu.

nodejs-docker-workflow \
    .dockerignore
    .env
    Dockerfile
    index.js
    package.json
    package-lock.json

pakcage.json obsahuje konfiguraci projektu.

{
  "name": "nodejs-docker-workflow",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "start": "node index.js",
    "dev": "nodemon -L index.js"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "express": "^4.18.1"
  },
  "devDependencies": {
    "nodemon": "^2.0.20"
  }
}

V části závislostí budeme pro náš jednoduchý projekt potřebovat pouze balíček express. V rámci vývojových závislostí (devDependencies) budeme používat nodemon. Ten nám umožní restart serveru, pokud se vyskytne změna v hlídaném adresáři.

index.js obsahuje kód našeho REST API.

const express = require('express')

const app = express()

app.get('/', (req, res) => {
    res.send({
        data: {
            message: 'Hello world!',
            exclamation: '!!!',
        },
    })
})

const port = process.env.PORT || 3000

app.listen(port, () => console.log(`listening on port ${port}`))

Primitivní API vracející "Hello world!".

Dockerfile obsahuje sestavení našeho obrazu kontejneru.

FROM node:16
WORKDIR /app
COPY package*.json .
RUN npm install
COPY . ./
ENV PORT 3000
EXPOSE $PORT
CMD ["npm", "run", "dev"]

FROM node:16 říká, že použijeme základní image, na kterém je už nachystán NodeJS verze 16.

WORKDIR /app nás v rámci kontextu přesune do složky /app.

COPY package*.json . překopíruje do obrazu do /app soubor package.json.

RUN npm install spustí instalaci závislostí na základe package.json.

COPY . ./ překopíruje soubory z aktuálního adresáře do obrazu do /app.

ENV PORT 3000 vytvoří proměnou prostředí.

CMD ["npm", "run", "dev"] spustí skript definovaný v package.json, který spustí nodemon.

.dockerignore obsahuje seznam souboru a složek co se nebudou kopírovat do obrazu.

node_modules
Dockerfile
.dockerignore
.git
.gitignore
README.md
docker-compose*

.env je seznam proměnných prostředí, které chceme aplikovat na kontejner.

PORT=4000

Základní projekt máme nachystaný. A sestavíme na základě Dockerfile obraz pro náš kontejner.

docker build -t node-app-image .

Následně pak můžeme překontrolovat, že obraz skutečně existuje.

docker image ls

Obraz je nachystaný a můžeme spustit samotný kontejner.

# WINDOWS %cd%
# POWERSHELL ${pwd}
# MAC, LINUX $(pwd)

# --env PORT=4000
# --env-file ./.env

docker run -p 3000:4000 -d --name node-app --env-file ./.env -v %cd%:/app -v /app/node_modules node-app-image

-p 3000:4000 přesměruje port 3000 z hostitelského systému na port 4000 Docker kontejneru.

-d spustí Docker kontejner na pozadí.

--name node-app pojmenuje kontejner.

--env-file ./.env nastaví proměnné systému na základě souboru .env.

-v %cd%:/app zajistí zrcadlení aktuálního adresáře a jeho změny do /app v kontejneru.

-v /app/node_modules vytvoří volume pro node moduly. Díky tomu se nestane to, že přes zrcadlený adresář pošleme příkaz k jejich smazání v kontejneru. Je to trochu "ohák", ale funční.

node-app-image je název obrazu na základě kterého vytváříme kontejner.

Pokud nedostaneme nějaké chybové hlášení, můžeme zkontrolovat, že vše jede.

Můžeme se podívat na aktuálně běžící kontejnery.

docker ps

A můžeme také zkontrolovat logy pro konkrétní kontejner.

docker logs node-app

Když do prohlížeče zadáme localhost:3000 dostaneme následující.

{"data":{"message":"Hello world!","exclamation":"!!!"}}

Pokud v souboru index.js upravíme odpověď serveru, nodemon na to zareaguje a restartuje API s aktuální změnou.

Jestliže se potřebujeme "přihlásit" dovnitř kontejneru do příkazové řádky, použijeme docker exec.

docker exec -it node-app bash

V této chvíli máme plně funkční NodeJS projekt v Dockeru. Pokud přidáme nebo odebereme balíčky, musím znovu sestavit obraz pomocí docker build -t node-app-image . a Docker kontejner spustit.

Předtím je teda nutné kontejner zabít, to uděláme pomocí docker rm.

docker rm node-app -fv

-fv odstraní i běžící kontejner (nemusíme zastavovat) a na něj navázané anonymní volumes (svazky).

Tohle je taková "základní" verze. Spouštění Docker kontejneru, s veškerou konfigurací v příkazové řádce může být po čase otrava. Jednodušším řešením je použití Docker-Compose.

V našem projektu vytvoříme soubor docker-compose.yml.

version: "3"
services:
  node-app:
    container_name: node-app
    build: .
    ports:
      - "3000:4000"
    volumes:
      - ./:/app
      - /app/node_modules
    env_file:
      - ./.env
#    environment:
#      - PORT=4000 

version: "3" je verze zápisu Docker Compose souboru.

node-app: uvozuje sekci našeho kontejneru.

container_name: node-app pojmenuje náš kontejner. Pokud ho nepojmenujeme sami, Docker to udělá za nás.

build: . sestaví obraz pomocí Dockerfile.

ports: přesměrování portů.

volumes: seznam volumes.

env_file: nastavuje proměnné prostředí.

Docker Compose soubor jen kopíruje to, co jsme nastavovali pro docker run. Ale takhle nám zůstane nastavení pěkně a strukturovaně uloženo.

Předpis spustíme pomocí příkazu docker-compose.

docker-compose up -d

Pokud přidáme parametr --build, tak se při každém spuštění znovu sestaví obraz.

docker-compose up -d --build

Pomocí docker-compose provádíme i smazání.

docker-compose down -v

-v jako v předchozím případě smaže i připojené anonymní volumes.

Tohle je už o něco lepší verze, ale nepočítá s tím, že bychom chtěli různá prostředí. Například development a production. Budeme muset upravit Dockerfile, docker-compose.yml a přidat docker-compose.dev.yml a docker-compose.prod.yml.

Do Dockerfile přidáme podmínku pro různá prostředí.

FROM node:16
WORKDIR /app
COPY package*.json .

ARG NODE_ENV
RUN if [ "$NODE_ENV" = "development" ]; \
        then npm install; \
        else npm install --only=production; \
        fi

COPY . ./
ENV PORT 3000
EXPOSE $PORT
CMD ["node", "index.js"]

ARG NODE_ENV definujeme použití argumentu NODE_ENV.

RUN if [ "$NODE_ENV" = "development" ]; \ na základě aktuální typu prostředí provedeme klasický npm install nebo produkční.

CMD ["node", "index.js"] je příkaz do produkčního prostředí, protože nespouštíme nodemon. Každopádně ho stejně budeme definovat znovu v Docker Compose souborech.

docker-compose.yml trošku zeštíhlíme a necháme v něm jen společná nastavení pro všechna prostředí.

version: "3"
services:
  node-app:
    container_name: node-app
    build: .
    ports:
      - "3000:4000"
    environment:
      - PORT=4000  

docker-compose.dev.yml nastavím pro naše development prostředí.

version: "3"
services:
  node-app:
    build:
      context: . 
      args:
        NODE_ENV: development
    volumes:
      - ./:/app
      - /app/node_modules
    environment:
      - NODE_ENV=development  
    command: npm run dev

Všimněte si, že jsme rozšířili definici build a přidali argument NODE_ENV, který se používá v Dockerfile. Nastavení volumes je stejné jako předtím a přepsali jsme CMD v Dockerfile na náš development příkaz.

docker-compose.prod.yml bude jednodušší, protože pro produkci nepotřebujeme zrcadlit adresáře.

version: "3"
services:
  node-app:
    build:
      context: . 
      args:
        NODE_ENV: production
    environment:
      - NODE_ENV=production
    command: node index.js

Principiálně je to to samé co docker-compose.dev.yml.

Pokud budeme chtít spustit development verzi, zavoláme.

docker-compose -f docker-compose.yml -f docker-compose.dev.yml up -d

Popřípadě, pokud chceme spustit i vytváření obrazu.

docker-compose -f docker-compose.yml -f docker-compose.dev.yml up -d --build

Odstranění kontejneru provedeme promocí.

docker-compose -f docker-compose.yml -f docker-compose.dev.yml down -v

Pro produkční build to bude analogické.

docker-compose -f docker-compose.yml -f docker-compose.prod.yml up -d
docker-compose -f docker-compose.yml -f docker-compose.prod.yml up -d --build
docker-compose -f docker-compose.yml -f docker-compose.prod.yml down -v

TADÁ a to je vše přátele. Aplikace funguje pořád stejně, ale už můžeme rozlišovat mezi development a production prostředtím.

ad1) Článek popisuje pouze absolutní základ, pravá síla Dockeru se projeví ve chvíli, kdy si nakonfigurujete kompletní ekosystém a budete ho schopni jednoduše replikovat.

ad2) Článek ukazuje situaci, kdy nebudete mít na svém stroji nainstalován NodeJS a nepustíte npm install na svém stroji. Tím si nevygenerujete package-lock.json. To může být problém při generování produkčních kontejnerů. package-lock.json obsahuje deterministický popis závislostí. Do produkce chcete jít s takovým stromem závislostí, který už máte odzkoušený. Pro doplnění citace z docs.npm.com.

package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, or package.json. It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates.

Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies.

from https://docs.npmjs.com/cli/v8/configuring-npm/package-lock-json

Proto je vhodnější postup na hostitelské systému používat npm i pro instalaci nových balíčku do projektu. Tím se bude generovat i package-lock.json. Toto nijak neomezuje používání rozličných verzí NodeJS v kontejnerech.

ad3) Docker se chová tak, že spustí příkaz a když doběhne, tak se vypne. V případě, že rozjíždíte NodeJs API, tak je to jedno. Tam se předpokládá, že pouštíte nějaký nodemon nebo něco co udrží API v běhu. Pokud ale chcete vyvíjet něco co neběží ve smyčce a z Dockerfile odeberete CMD příkaz, tak se Docker container spustí a úspěšně ukončí. Jde tím předejít přidáním parametru tty.
Ten zajistí, že se kontejner hned neukončí.

Pro docker-compose:

mydocker:
    tty: true

Pro docker run:

docker run -d --tty ......

The post NodeJS develompent v Dockeru first appeared on Hard Wired.

Těžko by jste asi hledali někoho, kdo nikdy neposlal ani jednu zprávu přes Messenger nebo podobnou službu. Asi můžeme říct, že je to jeden z nejrozšířenějších komunikačních prostředků současnosti.

S rostoucím podílem těchto služeb v oblasti všeobecné komunikace vyvstal i takový nešvar. Hovorově bychom mohli říct "fízlování". V reálu to bude nějaká sada algoritmů, která se snaží na základě klíčových slov, frází nebo nějaké sofistikovanější analýzy rozpoznat závadný či protiprávní obsah. Tyto praktiky se většinou zaštiťují ochranou dětí před XYZ a podobné zavádějící důvody. Ale o problematice svobody slova a práva na soukromí tento příspěvek není.

Klasické textové komunikační služby ukládají vaše zprávy v nešifrované podobě. Nemáte vůbec tušení jak dlouho se vaše data uchovávají a za jakým účelem (většinou marketing) mohou být přeprodávána. A už vůbec nevíte, kdy a kdo, to může použít proti vám. (byť třeba vytržené z kontextu)

Situaci si můžete vylepšit tím, že používáte "end-to-end" šifrované komunikátory. Telegram, Signal, Threema a podobně. Při této metodě komunikace by v ideálním případě zprostředkovatel neměl být schopný zprávy jakkoliv dešifrovat.

Tak je to možná v ideálním světě. V tom našem můžeme narazit na pár úskalí. Musíme zprostředkovateli věřit, že dodává takovou službu jakou inzeruje. I když nemusí vidět přímo obsah zpráv, stále si může uchovávat kdo, kdy a s kým komunikoval. Nepříjemností taky je registrace podmíněná poskytnutím telefonního čísla. Telefonní číslo za určitých podmínek dává smysl a používání aplikace je díky němu komfortnější, ale taky je to další vektor útoku na vaši identitu.

Alternativní možností je zprovoznit vlastní Matrix server. Pokud o tom slyšíte poprvé, můžete prozkoumat Fediverse ekosystém a pořádně se ponořit do králičí nory.

Jen ve zkratce popis na wikipedii.

The fediverse (a portmanteau of federation and universe) is an ensemble of federated (i.e. interconnected) servers that are used for web publishing (i.e. social networking, microblogging, blogging, or websites) and file hosting, but which, while independently hosted, can communicate with each other. On different servers (instances), users can create so-called identities. These identities are able to communicate over the boundaries of the instances because the software running on the servers supports one or more communication protocols which follow an open standard.[1] As an identity on the fediverse, users are able to post text and other media, or to follow posts by other identities.[2] In some cases, users can show or share data (video, audio, text, and other files) publicly or to a selected group of identities and allow other identities to edit other users\' data (such as a calendar or an address book). from https://en.wikipedia.org/wiki/Fediverse

Pro naše účely není tento aspekt úplně klíčový.

Co vlastně získáme tím, že zprovozníme vlastní Matrix server?

• Komunikace používá end-to-end šifrování. Nikdo kromě příjemce by neměl být schopný zprávu vidět.
• Data leží na našem "železe" a v námi kontrolovaném operačním systému. Sami si můžete překontrolovat jak a jaká data jsou v databázi ukládána.
• Starou dobrou registraci s uživatelským jménem a heslem. Nejsou potřeba žádné emaily nebo telefonní čísla.
• Nikdo probíhající komunikaci "nefízluje".
• Kód je open source. Každý do něho může nahlédnout. Možnost úmyslného zanešení nějakého škodlivého kusu kódu je hodně malá. Komunita by jim to brzy omlátila o hlavu.
• Máte na výběr z vícero klientů. I když tohle může být někdy i negativum než pozitivum.
• Moderní klienti moc nezaostávají za předními hráči na trhu. Ano jde poznat, že do toho nebylo nasypáno tolik peněz a „user experience“ není tak „smooth“. To ale nic nemění na tom, že můžete posílat zprávy, fotky, videa, emoji, nálepky, gify nebo provádět video telefonáty. Všechno je technicky funkční.
• Je možné provozovat komunikaci s jednotlivými lidmi, skupinové komunikace nebo vytvářet místnosti.

Výhod se najde asi ještě více, ale tou nejdůležitější vlastní kontrola.

Nevýhod se najde taky dost. Vůbec samotné rozeběhnutí vyžaduje lehce technický „skill“. Plus věci okolo jako domény, reverzní proxy atd.

Tak a teď teda k tomu co a jak je potřeba rozeběhnout.

Rozeběhnout to můžete skoro na čemkoliv, ale já pro naše účely použil RPi 3B+ s SSD diskem. Pro běh jednotlivých služeb použijeme Docker a Docker-Compose. Jak nainstalovat Docker je popsáno v jiném článku na tomto blogu.

Náš stack obsahje následující Docker obrazy.

• portainer/portainer-ce:latest
• matrixdotorg/synapse:latest
• postgres:14
• vectorim/element-web:latest

Portainer slouží jen pro pohodlnější správu Docker kontejnerů.

Jako Matrix server použijeme Synapse. Je to implementace Matrix serveru v Pythonu.

Postgres 14 bude naše databáze. V základu používá Synapse Sqlite3, ale pokud máme tu možnost, bude lepší použít Postgres.

Element je webový klient pro Matrix server.

V domovském adresáři si vytvoříme složku matrix-stack a začneme skládat Docker-Compose soubor.

cd ~
mkdir matrix-stack
nano ./matix-stack/docker-compose.yml

version: '3.3'

services:
  portainer:
    container_name: portainer
    image: portainer/portainer-ce:latest
    restart: always
    ports:
      - "9000:9000"
    volumes:
      - portainer_data:/data
      - /var/run/docker.sock:/var/run/docker.sock

  synapse:
    container_name: synapse
    image: matrixdotorg/synapse:latest
    restart: always
    ports:
      - 8008:8008
    volumes:
      - /var/docker_data/matrix:/data

  postgres:
    container_name: postgres
    image: postgres:14
    restart: unless-stopped
    ports:
      - "5432:5432"
    volumes:
     - /var/docker_data/postgresdata:/var/lib/postgresql/data

    environment:
     - POSTGRES_DB=synapse
     - POSTGRES_USER=synapse
     - POSTGRES_PASSWORD=SUPERSECRETLONGPASSWORD
     - POSTGRES_INITDB_ARGS=--lc-collate C --lc-ctype C --encoding UTF8

  element:
    container_name: element
    image: vectorim/element-web:latest
    restart: unless-stopped
    ports:
      - "80:80"
    volumes:
      - /var/docker_data/element-config.json:/app/config.json

volumes:
  portainer_data:

Pro Synapse místo Sqlite3 použijeme Postgre databázi. Víceméně se standardním nastavením kromě jedné věci.

POSTGRES_INITDB_ARGS=--lc-collate C --lc-ctype C --encoding UTF8

Matrix vyžaduje aby LC_COLLATE a LC_TYPE nastaveny na C. Má to co do činění s akceptováním různých znakových sad.

When LC_CTYPE is C or POSIX, any character set is allowed, but for other settings of LC_CTYPE there is only one character set that will work correctly. Since the LC_CTYPE setting is frozen by initdb, the apparent flexibility to use different encodings in different databases of a cluster is more theoretical than real, except when you select C or POSIX locale (thus disabling any real locale awareness).

Před tím, než pustíme docker-compose, je potřeba udělat ještě pár věcí.

Potřebujeme vygenerovat konfigurační soubor pro Synapse server.

docker run -it --rm \
    -v "/var/docker_data/matrix:/data" \
    -e SYNAPSE_SERVER_NAME=matrix.YOUR_DOMAIN.com \
    -e SYNAPSE_REPORT_STATS=no \
    matrixdotorg/synapse:latest generate

A v nově vygenerovaném souboru předělat Sqlite3 na Postgre. Stačí zakomentovat sekci s Sqlite3 a vložit novou.

database:
  name: psycopg2
  args:
    user: synapse
    password: SUPERSECRETLONGPASSWORD
    database: synapse
    host: postgres
    cp_min: 5
    cp_max: 10

Potom je potřeba vytořit konfigurační soubor pro Element.

sudo nano /etc/docker_data/element-config.yaml

{
    "default_server_config": {
        "m.homeserver": {
            "base_url": "https://matrix.YOUR_DOMAIN.com",
            "server_name": "matrix.YOUR_DOMAIN.com"
        },
        "m.identity_server": {
            "base_url": "https://vector.im"
        }
    },
    "brand": "Element",
    "integrations_ui_url": "https://scalar.vector.im/",
    "integrations_rest_url": "https://scalar.vector.im/api",
    "integrations_widgets_urls": [
        "https://scalar.vector.im/_matrix/integrations/v1",
        "https://scalar.vector.im/api",
        "https://scalar-staging.vector.im/_matrix/integrations/v1",
        "https://scalar-staging.vector.im/api",
        "https://scalar-staging.riot.im/scalar/api"
    ],
    "hosting_signup_link": "https://element.io/matrix-services?utm_source=element-web&utm_medium=web",
    "bug_report_endpoint_url": "https://element.io/bugreports/submit",
    "uisi_autorageshake_app": "element-auto-uisi",
    "showLabsSettings": true,
    "piwik": {
        "url": "https://piwik.riot.im/",
        "siteId": 1,
        "policyUrl": "https://element.io/cookie-policy"
    },
    "roomDirectory": {
        "servers": [
            "matrix.org",
            "gitter.im",
            "libera.chat"
        ]
    },
    "enable_presence_by_hs_url": {
        "https://matrix.org": false,
        "https://matrix-client.matrix.org": false
    },
    "terms_and_conditions_links": [
        {
            "url": "https://element.io/privacy",
            "text": "Privacy Policy"
        },
        {
            "url": "https://element.io/cookie-policy",
            "text": "Cookie Policy"
        }
    ],
    "hostSignup": {
      "brand": "Element Home",
      "cookiePolicyUrl": "https://element.io/cookie-policy",
      "domains": [
          "matrix.org"
      ],
      "privacyPolicyUrl": "https://element.io/privacy",
      "termsOfServiceUrl": "https://element.io/terms-of-service",
      "url": "https://ems.element.io/element-home/in-app-loader"
    },
    "sentry": {
        "dsn": "https://029a0eb289f942508ae0fb17935bd8c5@sentry.matrix.org/6",
        "environment": "develop"
    },
    "posthog": {
        "projectApiKey": "phc_Jzsm6DTm6V2705zeU5dcNvQDlonOR68XvX2sh1sEOHO",
        "apiHost": "https://posthog.element.io"
    },
    "features": {
        "feature_spotlight": true
    },
    "map_style_url": "https://api.maptiler.com/maps/streets/style.json?key=fU3vlMsMn4Jb6dnEIFsx"
}

V horní části souboru upravte pro vaši doménu.

"default_server_config": {
        "m.homeserver": {
            "base_url": "https://matrix.YOUR_DOMAIN.com",
            "server_name": "matrix.YOUR_DOMAIN.com"
        },
        "m.identity_server": {
            "base_url": "https://vector.im"
        }
    }

Tak a teď už můžeme pustit ten docker. Přesuneme se do složky s Docker-Compose souborem a spustíme příkaz docker-compose.

cd ~/matrix-stack
docker-compose up -d

Pokud všechno proběhne dle plánu, tak se můžete zkusit přihlásit do Portaineru a měli byste vidět něco takového.

Teď se potřebujeme připojit do docker kontejneru kde beží Synapse odkud budeme přes příkaz register_new_matrix_user přidávat uživatele.

docker exec -it synapse /bin/bash

register_new_matrix_user -c /data/homeserver.yaml http://127.0.0.1:8008

Příkaz vás následně navede co vyplnit.

V tomto bodě nám už vše běží a máme vytvořeného prvního uživatele. Pokud se přes prohlížeč podíváte na http://<ip-adresa-vaseho-stroje>:8008 uvidíte že Matrix server běži.

Určitě se nechceme vždy připojovat na http://<ip-adresa-vaseho-stroje>:8008. To by bylo poněkud nepohodlné a pravděpodobně by to fungovalo jen v lokální síti. Ještě bychom mohli přesměrovat porty na router, ale to je prašť jako uhoď.

Lepší bude použít doménu jako matrix.nasedomena.eu a samozřejmě https protokol, aby naše data po internetu nelítala jen tak.

Bude to chtít zařídit několik věcí.

• Je potřeba mít veřejnou statickou IP.
• Koupit nějakou doménu.
• Vyřídit si certifikát. Například přes službu Let's Encrypt.
• Zprovoznit reverzní proxy, která bude zpracovávat příchozí požadavky. Pro tento článek použijeme webový server Nginx jako reverzní proxy. Jak zprovoznit Nginx jako reverzní proxy najdete v článku na tomto webu.

Budeme chtít používat https://matrix.nasedomena.eu a https://element.nasedomena.eu.

Pro element.nasedomena.eu bude konfigurační soubor pro Nginx vypadat nějak takhle.

 server {
    listen 80;
    server_name element.nasedomena.eu;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name element.nasedomena.eu;

    ssl on;
    ssl_certificate /etc/letsencrypt/live/nasedomena.eu/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/nasedomena.eu/privkey.pem; # managed by Certbot

    location / {
        proxy_pass http://192.168.1.111:80;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Veškerý nešifrovaný provoz směrující na element.nasedomena.eu bude přesměrován na šifrovaný.

Pro samotný Matrix server je nutné do konfigurace přidat ještě pár věcí.

server {
    listen 80;
    server_name matrix.nasedomena.eu;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    listen 8448 ssl http2 default_server;
    listen [::]:8448 ssl http2 default_server;

    server_name matrix.nasedomena.eu;

    ssl on;
    ssl_certificate /etc/letsencrypt/live/nasedomena.eu/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/nasedomena.eu/privkey.pem; # managed by Certbot

     location /.well-known/matrix/client {
                return 200 '{"m.server": {"base_url": "matrix.nasedomena.eu:443"}}';
                default_type application/json;
                add_header Access-Control-Allow-Origin *;
        }

    location /.well-known/matrix/server {
                default_type application/json;
                add_header Access-Control-Allow-Origin *;
                return 200 '{"m.server":"matrix.nasedomena.eu:443"}';
        }

    location / {
        proxy_pass http://192.168.1.111:8008;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Jestli máme všechno dobře nakonfigurováno, můžeme zkusit https://element.nasedomena.eu. Poběží tu webový klient pro Matrix. Budeme muset upravit domovský server na náš matrix.nasedomena.eu, protože v základu je tam nastavený matrix.org. Poté se můžeme přihlásit jako uživatel, kterého jsme vytvořili v jednom z předchozích kroků.

K připojení můžete samozřejmě využít jakéhokoliv klienta Matrixu. Přidejte další další uživatele pomocí kroků výše a můžete začít komunikovat naprosto soukromě. Komunikace s dalšími uživateli v rámci Fediverse je také možná. Samotný Synapse jde různě nakonfigurovat. Můžete například povolit registraci uživatelů přes klienty a další možnosti. Konfigurace Synapse ale není náplní tohoto článku.

The post Self hosted Matrix server first appeared on Hard Wired.

Rychlý přehled jak nainstalovat Docker a Docker-Compose.

Vždy je dobré systém aktualizovat.

sudo apt update && sudo apt upgrade -y

Instalace dockeru.

curl -sSL https://get.docker.com | sh

Povolíme uživateli používat Docker. V opačném případě je nutné používat docker jako root. Přidáme uživatele do skupiny docker.

sudo usermod -aG docker <user_name>

Nainstalujeme Docker-Compose.

sudo apt install libffi-dev libssl-dev python3-dev python3 python3-pip -y
sudo pip3 install docker-compose

Zapneme docker po startu systému.

sudo systemctl enable docker

Tadá, je možné používat Docker a Docker-Compose.

Pokud vám nedělá dobře spouštět "on demand" stažené skripty, můžete vše udělat pěkně postupně.

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get install apt-transport-https ca-certificates curl gnupg lsb-release -y

sudo apt-get update

sudo apt-get install docker-ce docker-ce-cli containerd.io -y

sudo usermod -aG docker $USER

The post Instalace Dockeru first appeared on Hard Wired.