Příspěvky

46

Server / Re:iSCSI Multipathing v Proxmox

« kdy: 12. 04. 2023, 17:05:59 »

Aby byl funkcni multipath, co je potreba?
[a dál dotaz na kombinace IP subnety vs. porty na storage boxu]

To je dobrá otázka. Podle mého záleží, co umí ten storage box.

Pokud to má uvnitř jedinou instanci firmwaru, která vidí ty své čtyři porty jako eth0...eth3, tak bez dalšího bych řekl, že nemá smysl dávat těm čtyřem rozhraním IP adresy z jediného společného subnetu. V tom případě totiž traffic směrem ven pojede nejspíš jediným rozhraním. Aspoň takto by se choval standardní Linux.

Jak se tu nedávno probíralo, i v tom Linuxu se dá zařídit, aby "odpovědi odcházely stejným rozhraním, odkud přišel dotaz" (per TCP spojení) - ale znamená to nějaké hraní s iptables, ten storage box by musel řešit connection tracking a nějaké navazující věci... odhadem by to mohlo být procesorově náročné a tedy nežádoucí. Nebo by na to výrobce musel mít nějaký svůj vlastní modul v kernelu - nemohu vyloučit, viděl jsem už různá zvěrstva.

Tezko rict, dovnitr nevidim. Ale sitovky se daji konfigurovat L2,L3, bonding, port groupy, etc, takze...

Uměl by ten storage box proti switchi trunking / bonding? Toto buď pomocí LACP nebo i bez. Pokud ano uměl, můžou se dvě a více rozhraní chovat jako "failover group", možná dokonce s jakýmsi load balancingem, a tím pádem ten storage box může mít klidně jedinou společnou IP adresu.

Umi. Ale v pripade bondingu bude prece vykon degradovany minimalne na urovni linky ne? Jedine spojeni pve(ip:port)->box(ip:port)?

Obecně by mělo fungovat, postavit to jako dvojhvězdu. Každý PVE box po jednom fousu do každé hvězdy, každý storage box taktéž (dva porty storage boxu by zůstaly "na ocet"). A na každou L2 hvězdu jiný L3 subnet.

Grammar nazi poznámka: mít dva samostatné storage boxy připojené k jedinému hostiteli, a provozovat nad nimi nějaký (geograficky) rozprostřený mirror, to je terminologicky něco jiného, než multipath.

Multipath znamená, že máte jeden storage box (dokonce jeden LUN) vidět z jednoho hostitele dvěma nezávislými cestami. Za starých časů bych ke "sloučení do jednoho blokového zařízení" použil v Linuxu modul dm-multipath.

Nad temi boxy bude HA sluzba, takze ten mirror by nemel byt problem.

Ono v Linuxu jde ledacos poskládat "holýma rukama" na kterékoli distribuci, ale některé distribuce mají své vlastní specifické uživatelsky příjemné nástroje...

Mimochodem než geograficky rozprostřený mirror z blokových zařízení, zvážil bych možná spíš CEPH, pokud tomu jde naproti geografické rozmístění počítačů. A tahat storage traffic skrz L3 router by mi kdysi taky připadalo jako svatokrádež. Já vím - lepším switchům je už asi dvacet let dost jedno, jestli forwardují L2 nebo L3.

ceph jsme zvazovali, nakonec dostal prednost SAN. Co se tyce L3, vzdy peclive premyslime, zda roztahnute L2 ma smysl (konfiguracni schopnosti switche). Tohle je asi prvni pripad roztahnute L2 (replikace), ale iscsi zatim mame L3.

Tldr: zatim resim, jak vlastne nastavit site na PVE, aby spravna kombinace adresace/portu fungovala - je tam lacp, bridge atd...proste sdilena sitova konfigurace. A nez budu predelavat na subnet per sitovy port, tak zjistuji, zda nemam botu jinde. Prvotni predpoklad je, ze ten box ten multipath umi podle ocekavani - tzn. vice IP na pve a vice IP na boxu.

47

Vývoj / PHP 8.2 nevrací ve funkci date čas s timezone

« kdy: 12. 04. 2023, 16:19:26 »

php.ini:

Kód: [Vybrat]

root@testphp:/opt# grep timezone /etc/php/8.?/cli/php.ini
/etc/php/8.1/cli/php.ini:; Defines the default timezone used by the date functions
/etc/php/8.1/cli/php.ini:; https://php.net/date.timezone
/etc/php/8.1/cli/php.ini:;date.timezone =
/etc/php/8.2/cli/php.ini:; Defines the default timezone used by the date functions
/etc/php/8.2/cli/php.ini:; https://php.net/date.timezone
/etc/php/8.2/cli/php.ini:;date.timezone =

Skript:

Kód: [Vybrat]

cat /opt/date.php
<?php

$date = date('Y-m-d H:i:s');
echo $date;
echo "\n";
?>

Testy:

Kód: [Vybrat]

root@testphp:/opt# /usr/bin/php8.2 /opt/date.php 
2023-04-12 14:00:22

root@testphp:/opt# /usr/bin/php8.1 /opt/date.php 
2023-04-12 16:00:26

root@testphp:/opt# timedatectl 
               Local time: Wed 2023-04-12 16:00:34 CEST
           Universal time: Wed 2023-04-12 14:00:34 UTC
                 RTC time: Wed 2023-04-12 14:00:35
                Time zone: Europe/Prague (CEST, +0200)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no

Kód: [Vybrat]

root@testphp:~# apt-cache policy php8.2-cli
php8.2-cli:
  Installed: 8.2.4-1+0~20230409.18+debian11~1.gbp556b04
  Candidate: 8.2.4-1+0~20230409.18+debian11~1.gbp556b04
  Version table:
 *** 8.2.4-1+0~20230409.18+debian11~1.gbp556b04 990
        990 https://packages.sury.org/php bullseye/main amd64 Packages
        100 /var/lib/dpkg/status
root@testphp:~# apt-cache policy php8.1-cli
php8.1-cli:
  Installed: 8.1.17-1+0~20230409.38+debian11~1.gbp0c3ecb
  Candidate: 8.1.17-1+0~20230409.38+debian11~1.gbp0c3ecb
  Version table:
 *** 8.1.17-1+0~20230409.38+debian11~1.gbp0c3ecb 990
        990 https://packages.sury.org/php bullseye/main amd64 Packages
        100 /var/lib/dpkg/status

Je to bug ci ne? Nemuzu najit v release notes php8.2, co by se k tomu dalo priradit.

48

Server / iSCSI Multipathing v Proxmox

« kdy: 12. 04. 2023, 12:05:35 »

Ahoj,

mam v ruce 2x storage (bude v HA), ktere ma byt pripojeno pres iscsi multipath. Bohuzel aplikace vyrobce resici multipath je pouze pro windows a redhat-style systemy, debian/ubuntu podporovany neni, takze s tim budeme muset trochu laborovat.

1] Kazda storage ma 4x fyzicky port do switchu, momentalne ma tedy 4x IP z jednoho iscsi subnetu.
2] Testovaci PVE ma 2x fyzicky port do switchu, openvswitch+lacp+bridge+2 virtual iscsi porty, tzn. 2 IP ze stejneho iscsi subnetu jako v 1]
3] datove toky na PVE momentalne jedou jen pres jeden iscsi port

Aby byl funkcni multipath, co je potreba?
a1] dedikovany subnet per port na storage
a2] 1 subnet per  storage
b1] dedikovany subnet per port na pve
b2] 1 subnet per pve
c1] iscsi over lacp na pve
c2] iscsi bez lacp na pve (tzn. dedikovane fyzicke porty)

Kombinace a2+b2+c2 je jasna. Ale jak se tam pak resi treba to, ze by pve mel jen 2x iscsi vs storage 4x iscsi z hlediska adresace/routovani?
Je mozna jina kombinace, ktera by byla jeste rozumne jednoducha? napr. a1+b1+c1 atd.?

Jeste je nutno vzit v uvahu, ze kazdy pve by mel propoj na obe storage, kazda v jine lokalite s jinou L3 adresaci - tedy bez roztahnuti L2. Celkove se tedy v tuto chvili jedna o 2x4 iscsi target, momentalne 2 ruzne iscsi subnety (1 per lokalita).

Diky.

49

Distribuce / Re:Upgrade grub-pc na Proxmoxu rozbije boot

« kdy: 05. 04. 2023, 13:40:32 »

Ted jsem narazil na druhou vec. Kdyz obraz VM naklonuji a pridam cloud-init, tak mam po nabehnuti systemu ten spatny DM disk. Pokud tu VM po naklonovani spustim bez cloud-init, tak je grub-pc ukazuje na ten QEMU disk.

50

Distribuce / Re:Upgrade grub-pc na Proxmoxu rozbije boot

« kdy: 05. 04. 2023, 09:06:43 »

Jinak nasel jsem tento prikaz:

Kód: [Vybrat]

root@debian11-default-cloud:~# debconf-show grub-pc
  grub-pc/kopt_extracted: false
  grub-pc/chainload_from_menu.lst: true
* grub-pc/install_devices: /dev/disk/by-id/dm-name-vg0-root    <------------------
  grub-pc/install_devices_failed: false
  grub-pc/disk_description:
  grub2/force_efi_extra_removable: false
  grub-pc/postrm_purge_boot_grub: false
  grub-pc/install_devices_failed_upgrade: true
  grub2/kfreebsd_cmdline_default: quiet
  grub2/update_nvram: true
  grub2/kfreebsd_cmdline:
* grub2/linux_cmdline_default: quiet
  grub-pc/mixed_legacy_and_grub2: true
  grub2/device_map_regenerated:
  grub-pc/partition_description:
* grub-pc/install_devices_empty: false
  grub-pc/install_devices_disks_changed:
* grub2/linux_cmdline:
  grub-pc/hidden_timeout: false
  grub-pc/timeout: 5

Neni divu, ze to porad pada. Ma tam byt:

Kód: [Vybrat]

  grub-pc/partition_description:
  grub-pc/postrm_purge_boot_grub: false
  grub-pc/install_devices_failed: false
  grub-pc/kopt_extracted: false
* grub2/linux_cmdline:
  grub2/kfreebsd_cmdline:
  grub-pc/install_devices_failed_upgrade: true
  grub2/force_efi_extra_removable: false
* grub-pc/install_devices_empty: false
  grub-pc/disk_description:
  grub2/kfreebsd_cmdline_default: quiet
  grub2/device_map_regenerated:
  grub-pc/install_devices_disks_changed:
  grub-pc/chainload_from_menu.lst: true
* grub-pc/install_devices: /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi0   <-------------
  grub-pc/timeout: 5
  grub2/update_nvram: true
  grub-pc/hidden_timeout: false
  grub-pc/mixed_legacy_and_grub2: true
* grub2/linux_cmdline_default: quiet

Pregeneroval jsem zakladni obraz VM, aby to tam bylo fixnute, ale matne si vybavuji, ze jsem to tam jiz fixoval.

51

Distribuce / Re:Upgrade grub-pc na Proxmoxu rozbije boot

« kdy: 05. 04. 2023, 08:53:41 »

To je mysleno tak, ze bych to mel spoustet pred kazdym updatem, nebo je to jednorazovka?

52

Distribuce / Upgrade grub-pc na Proxmoxu rozbije boot

« kdy: 04. 04. 2023, 09:49:09 »

Ahoj,

uz nejakou dobu se potykam s problemem ohledne upgrade grub-pc na debian 11 jako VM v proxmoxu. Rozpadne se detekce boot oddilu. Skace to nahodne po serverech, zakladni VM, kterou pouzivam pro klonovani jsem upravil, ale i tak se to objevuje. Mam s tim pak problemy v ansible updatech serverech, kdy je nutny zasah. Oprava spociva ve volbe "NO" a nasledne zruseni "/dev/dm0" a zaskrtnuti "/dev/sda" jako boot disk.

Nevi nekdo, jak to definitivne fixnout?

Fdisk:

Kód: [Vybrat]

Disk /dev/sda: 10 GiB, 10737418240 bytes, 20971520 sectors
Disk model: QEMU HARDDISK   
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xb75887e2

Device     Boot Start      End  Sectors Size Id Type
/dev/sda1  *     2048 20969471 20967424  10G 8e Linux LVM


Disk /dev/mapper/vg0-root: 7.45 GiB, 7998537728 bytes, 15622144 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/vg0-swap: 2.55 GiB, 2734686208 bytes, 5341184 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

53

Server / Re:Pomalé předání e-mailu na Gmail.com

« kdy: 22. 03. 2023, 10:06:16 »

U mna vacsinou delay pod 1s.  Ale mam tam jednu specificku adresu, kde odchadza posta dost casto a u nej mam delay vzdy daleko vacsi, medzi 10-20s.  Vyzera to, ze google selektivne spomaluje transakcie u adries, na ktore posiela nas server vela posty.
V niektorych pripadoch to konci odmietnutim na ERROR 421 s dovodom "Our system has detected an unusual rate of  unsolicited mail originating from your IP".... To protect our users from spam, mail sent from your IP has been temporarily rate limited". Co je samozrejme horsi pripad. A to nemusi ist o spam.Toto sa stava napr. u legitimnych notifikaciach z objednavkoveho systemu.

Treba si tiez uvedomit, ze mail nie je instant messaging. Oneskorenim 4s namiesto obvyklych 0.9s by som sa netrapil.

Tak zalezi na use case, ono pro nejakou aplikaci muze byt rozdil jestli odesle 900 emailu za hodinu nebo 4000 emailu za hodinu. U reseni vyzadujicich vyssi pocty dorucovanych sprav se obvykle pouziva farma emailovych serveru kde kazdy ma samostatnou IP, zaznam, atd. A ano, google ten traffic zamerne spomaluje.

Presne takhle. Mame novou i starou farmu mailserveru, na ruznych subnetech (ruzne ASN) a obe se chovaji stejne = pomalu.
Da se s tim neco delat? Uvazolval jsem nastavit postfix nastavit na sekundarni MX fqdn, ale tam je ping odezva maximalne 2x lepsi. Druhou moznosti je zvetsit nektery z parametru postfixu pro vytvoreni vice spojeni, napr. ted mam:

Kód: [Vybrat]

smtp_destination_concurrency = 4
initial_destination_concurerency = 5

A postfix to pak interne nejak upravuje podle toho, jak rychle se dari odesilat.

54

Server / Re:Pomalé předání e-mailu na Gmail.com

« kdy: 20. 03. 2023, 14:42:01 »

Hadam, ze odpoved bude asi tady:

Kód: [Vybrat]

Pinging gmail-smtp-in.l.google.com [2404:6800:4008:c06::1a] with 32 bytes of data:
Reply from 2404:6800:4008:c06::1a: time=268ms
Reply from 2404:6800:4008:c06::1a: time=268ms
Reply from 2404:6800:4008:c06::1a: time=268ms
Reply from 2404:6800:4008:c06::1a: time=269ms

Ping statistics for 2404:6800:4008:c06::1a:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 268ms, Maximum = 269ms, Average = 268ms

ping -4 gmail-smtp-in.l.google.com

Pinging gmail-smtp-in.l.google.com [64.233.188.26] with 32 bytes of data:
Reply from 64.233.188.26: bytes=32 time=268ms TTL=102
Reply from 64.233.188.26: bytes=32 time=268ms TTL=102
Reply from 64.233.188.26: bytes=32 time=268ms TTL=102
Reply from 64.233.188.26: bytes=32 time=268ms TTL=102

Ping statistics for 64.233.188.26:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 268ms, Maximum = 268ms, Average = 268ms

S tim se tedy nic delat asi neda...

55

Server / Re:Pomale predani emailu na gmail.com

« kdy: 20. 03. 2023, 13:36:20 »

delay = 0.76:

Kód: [Vybrat]

Mar 20 10:30:57 mail postfix/smtp[1114821]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[142.250.27.26]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256)
Mar 20 10:30:57 mail postfix/smtp[1114821]: 134AC2A004E: to=<***@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.27.26]:25, delay=0.76, delays=0.09/0.02/0.3/0.35, dsn=2.0.0, status=sent (250 2.0.0 OK  1679304657 q6-20020a1709064cc600b00934a633a6c1si1855786ejt.228 - gsmtp)

ale

delay = 15:

Kód: [Vybrat]

Mar 20 12:39:59 mail postfix/smtp[1125593]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[142.250.27.27]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256
Mar 20 12:40:14 mail postfix/smtp[1125593]: E35222A00A2: to=<***@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.27.27]:25, delay=15, delays=0.38/0/0.34/14, dsn=2.0.0, status=sent (250 2.0.0 OK  1679312414 d5-20020a50fb05000000b004ad0993e54esi9779437edq.487 - gsmtp)

Třeba je to vytížením jejich serverů, čert ví. Náš server je nevytížený... Na servery Seznamu to dělá delay okolo 1.3 až 1.6. Na Gmail nejčastěji pod 1 sekundu, ale občas je tam anomálie, viz výše. Přiznám se, že mne to moc netrápí.

V obou pripadech vidim 3. polozku cca 0.3s (navazani spojeni vcetne tls). U mne to je vetsinou 2-3s. A to to bezi na G9 serverech virtualizovane...Servery jako takove taktez bez vyrazne zateze (at uz mailserver, ci hypervizor).

56

Server / Pomalé předání e-mailu na Gmail.com

« kdy: 20. 03. 2023, 12:17:44 »

Ahoj,

zhruba pred tydnem nam zakaznik oznamil, ze posilani emailu na gmail je s velkou prodlevou.

Kód: [Vybrat]

Mar 20 11:58:24 MAILSERVER postfix/smtp[1833743]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[108.177.97.26]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X
25519 server-signature ECDSA (P-256) server-digest SHA256
Mar 20 11:58:27 MAILSERVER postfix/smtp[1833743]: 4PgBYB1wBtz76: to=<SOMEUSER@gmail.com>, relay=gmail-smtp-in.l.google.com[108.177.97.26]:25, delay=4.8, delays=0.1/0/2.4/2.3, dsn=2.0.0, status=sent (2
50 2.0.0 OK  1679309906 l4-20020a056a00140400b005a8d595767asi10382056pfu.252 - gsmtp)

Z logu mam prumerne delay zhruba mezi 4-5s na gmail.com. Kolisa to nekde mezi 3. (navazani spojeni) a 4. (predani mailu) delay hodnotou. Ve chvili, kdy posleme hromadne emaily, tak se to zpozdeni sakra nascita. Ten zpomaleny stav trva doted.

Pro srovnani:

Kód: [Vybrat]

Mar 20 12:00:04 MAILSERVER postfix/smtp[1833743]: Untrusted TLS connection established to mx1.seznam.cz[2a02:598:2::1090]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-25
6) server-signature RSA-PSS (4096 bits) server-digest SHA256
Mar 20 12:00:04 MAILSERVER postfix/smtp[1833743]: 4PgBb74v0Pz76: to=<SOMEUSER@seznam.cz>, relay=mx1.seznam.cz[2a02:598:2::1090]:25, delay=1.3, delays=0.11/0/1.1/0.08, dsn=2.0.0, status=sent (250 2.0.0 message q
ueued (szn-id:4d044e47-a9b6-4975-a1bf-f1f84450a1fb))

Mar 20 11:56:32 MAILSERVER postfix/smtp[1833743]: Untrusted TLS connection established to centrum-cz-10mx2.eco-mx.cz[46.255.227.8]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Mar 20 11:56:32 MAILSERVER postfix/smtp[1833743]: 4PgBW40r3Qz76: to=<SOMEUSER@centrum.cz>, relay=centrum-cz-10mx2.eco-mx.cz[46.255.227.8]:25, delay=0.35, delays=0.1/0.01/0.06/0.18, dsn=2.0.0, status=sent (250 ok:  Message 11722009 accepted)

Netrpi nekdo stejnym zpozdenim ci nekomunikoval nekdo ohledne toho s googlem jiz? Dela nam to na ruznych konektivitach/verzich postfixu, takze serverovou stranu muzu vyloucit. A nezda se mi, ze by za to mohlo TLSv1.3.

Diky.

57

Server / PgBouncer a scram-sha-256

« kdy: 22. 02. 2023, 12:11:59 »

Ahoj,

upgradem na postgresql 15 se nam tak trochu rozpadla vazba pgbouncer/postgresql. Pgbouncer mame primo na postgresql stroji, ale i tak jsem mel nastavene prihlasovani heslem do postgresql. To v kombinaci md5/scram-sha-256 prestalo fungovat v kombinaci s auth_query. Tak jsem trochu zagoogloval a vyznelo z toho testovanim toto:

1] aby fungoval scram, je nutne, aby heslo v postgresql bylo scram jak pro uzivatele pgbouncer, tak pro samotneho zivatele
2] udajne funguje nastaveni scram retezce v userlist.txt pro pgbouncer
- mne ale funguje jen varianta s nesifrovanym heslem
- jinak chyba "cannot do SCRAM authentication: password is SCRAM secret but client authentication did not provide SCRAM keys"
 - je jedno, zda zadam scram retezec do login query psql nebo vyvolam zadani hesla napr. -W
3] nastavenim password_encryption = md5 v postgresql.conf funguje md5/scram kombinace

a] ma nekdo v provozu bod 2] s sifrovanym heslem?
b] v debianu je pgbouncer nainstalovany pod postgres uzivatelem, nelze vyuzit "peer" overeni v ramci localhostu. Je "trust" metoda v ramci localhostu povazovana za dostatecne bezpecna/blbuvzdorna? Samozrejme za predpokladu, ze prihlasit se na samotny server (ssh) muzou pouze administratori. Zde jeste povazuji za nestastne, ze dana "trust" by se musela v pg_hba.conf vlozit pred defaultni "host all all 127.0.0.1/32 scram-sha-256" (pres ansible nechavam default pg_hba a na konec pripojuji modifikace, bohuzel nestastne resene pg_hba od postgresql jede podle poradi)

Diky za nazory.

58

Sítě / Re:Monitoring sítě

« kdy: 20. 02. 2023, 08:53:30 »

Tak napriklad ja by som si "zelal":

*Prehlad co mi tecie z WANov (IP Tranzit providery) smerom k Hostom
**Ktore IPcky v ramci LAN/DMZ vyuzivaju traffic a kedy
**Ktore IPcky z Internetu najviac s nami komunikuju, kolko, kedy

*Prehlad IP Sec tunnelov (SA UP, ICMP Echo test, ...)
** Traffic ktory tade tecie z vnutra (kolko, kedy, encryption domain)

*Prehlad vytazenosti Eth portov... Cez monitor posrty napriklad?


Zakladny prehlad mam pomocou mrtg, ale len na urovni interfaceov. Chcelo by to viac.

Zkuste nejaky netflow type nastroj - ja mam nasazeny elastiflow + librenms. Ale neco jako encryption domain docela pochybuju, ze vetsina nastroju bude umet, to by to muselo tyhle veci umet vuci konkretnimu vpn koncentratoru.

59

Sítě / Re:Software pro dokumentaci síťové infrastruktury

« kdy: 02. 02. 2023, 09:23:23 »

Muzete to doplnit treba necim jako librenms ci podobnym sw, co bezi na principu snmp/autodetekce a vyuziva lldp pro propoje. Ale zadny sw nebude umet vse, bohuzel.

60

Server / Re:Automatický restart PostgreSQL

« kdy: 30. 01. 2023, 12:35:30 »

Ale zpatky k otazce - zejmena p. Stehule prosim - mate nejake informace ohledne dopadu automatickeho restartu vzhledem k tomu, co je za komentar v dane systemd service?