Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - k.pavel

Stran: [1]
1
Server / Re:Postfix+Dovecot a složka "Odeslaná pošta"
« kdy: 30. 07. 2021, 08:36:04 »
To bude možné řešení, tady je to také zmíněné - https://serverfault.com/questions/884969/postfix-swallows-bcc-header
zretezit dva postfixy a tomu prvnimu upravit message_drop_headers - aby nemazal BCC ? :-)
Děkujeme za nápady, o parameru message_drop_headers víme, ale ten neřeší situaci, kdy např. Thunderbird anonymizaci provede sám.

2
Server / Re:Postfix+Dovecot a složka "Odeslaná pošta"
« kdy: 28. 07. 2021, 16:01:24 »
Citace
Duvod? Nejaky klient maze odesilane zpravy?

No offence, zajimam se o tu motivaci z ceho ten napad vzniknul.
Důvod je prostý, potřebujeme, aby kdokoliv kdo odešle zprávu (webová stránka, aplikace), se tato zpráva uložila do složky Odeslaná pošta. To aby uživatel, který danou schránku spravuje měl vše, co bylo odesláno, v odeslané poště. Tímto řešením je možné použít pouze SMTP protokol a nemusí se používat IMAP pro přesun odeslané zprávy do příslušné složky.

3
Server / Postfix+Dovecot a složka "Odeslaná pošta"
« kdy: 28. 07. 2021, 15:18:42 »
Pro odesílání e-mailu využíváme vlastní mailserver Postfix+Dovecot. Využíváme parametr Postfixu sender_bcc_maps, který zajišťuje, že odesílaná zpráva se pomocí blind carbon copy (BCC) posílá také odesílateli na adresu odesílatel+sent@email.domena. Tím se zpráva uloží do IMAP složky s odeslanými zprávami. Nespoléháme se tak, na ukládání zpráv do složky s odeslanými zprávami pomocí poštovního klienta.

Máme ale problém se zprávami, které byly odeslány skrytým příjemcům (BCC). Informace o skrytých příjemcích není u zprávy ve složce s odeslanou poštou vidět. Hlavička BCC v těchto zprávách zcela chybí. Důvod je nám jasný. E-mailový klient při předávání zprávy mailserveru tuto hlavičku odstraní. A zprávu do složky s odeslanou poštou v našem případě ukládá mailserver, takže uloží zprávu, která hlavičku s Bcc již neobsahuje.

Víme, že pro každého příjemce uvedeného v BCC, e-mailový klient v SMTP dialogu uvede každého BCC příjemce jako "rcpt to:". Pokud je příjemců v BCC 10, klient odešle v SMTP dialogu 10x rcpt to. Na straně serveru tak nejsme jednoduše schopni identifikovat BCC příjemce a hlavičku Bcc zrekonstruovat, abychom ji mohli do zprávy v odeslané poště vložit.

Vidíme, že při odesílání pošty přes mailservery Google se v odeslané poště hlavička Bcc zachová a do odeslané pošty je zpráva uložena pomocí poštovních mailserverů Google a ne pomocí našeho poštovního klienta. Jak to ten Google asi dělá?

Předem děkujeme za jakékoliv nápady, jak tuto funkčnost aplikovat i na naše prostředí.

4
Server / Re:NFSv4 na CentOS 7.9 Pacemaker Clusteru
« kdy: 28. 04. 2021, 13:35:18 »
crm configure show:
Kód: [Vybrat]
primitive nfs-kernel-server systemd:nfs-server \
        meta target-role=Started
Chtěl bych Vám poděkovat za poslání konfigurace. Zkoušel jsem svůj cluster postavit nad touto resource, ale výsledek je pořád ten samý. Po prvním mountu klienta je přepnutí do 20s, ale další přepnutí nodů trvá 3,5min. Místo /var/lib/nfs jsem vyrobil symlink, který směřoval do adresáře ve svazku postaveném na iSCSI, který je dostupný z obou nodů. Zkoušel jsem také NFS klienta provozovaném na Debianu 10.9 tam byla první odezva po mountu také 20s, ale další timeouty byly pouze 1,5min což je lepší, ale pořád se mi to nelíbí. Stejně tak se to chovalo i nad CentOS 8.

Mohl bych Vás ještě poprosit o informaci, zda Váš cluster běží ve virtuálním prostředí a jakém? A nebo zda běží na fyzickém železe?
Předem děkuji za odpověď.

5
Server / Re:NFSv4 na CentOS 7.9 Pacemaker Clusteru
« kdy: 26. 04. 2021, 11:24:40 »

Mam /var/lib/nfs jako symlink odkazujici na exportovany drbd disk, takze po prehozeni disku pacemakerem jiz startujici nfs vidi obsah toho adresare na novem masteru tak, jak ho videl puvodni master. Navic nfs4 pouziva urcitou logiku pro locky (viz grace-time v uvodnim prispevku), takze se locky poresi.

Transparentni failover jsem schopen provest s minimalni dobou vypadku 10s + delta, kde delta zavisi na dobe preklopeni drbd/nfs atd.

Mohl bych Vás poprosit o uveřejnění Vašich použitých resource a jejich konfiguraci? Pravě jsem otestoval odstranění parametru nfs_shared_infodir=/mnt/data/nfsconf (kde /mnt/data je sdílený LVM svazek umístěný na iSCSI mezi oběma nody). Ten jsem nahradil symlinkem /var/lib/nfs který směřuje do /mnt/data/nfsconf. Při této konfiguraci, se mi ovšem nespustí resource ocf:heartbeat:nfsserver. Zkoušel jsem také spustit samostatně službu NFS serveru a ta se mi spustila, takže to vypadá, že parametr nfs_shared_infodir je zřejmě povinný pro spuštění této resource. Spuštění resource v této konfiguraci, končí hlášením "unknown error".

Jinak co se týká přepnutí IP tak tam zřejmě chyba nebude, protože jak jsem psal virtuální router pošle broadcastový packet s informací o změně MAC a packety se začnou směrovat na nově zaktivovaný node.

6
Server / Re:NFSv4 na CentOS 7.9 Pacemaker Clusteru
« kdy: 23. 04. 2021, 16:10:22 »

Nemyslim si (navic nfs3 mam sice zapnute z urcitych duvodu, ale vsichni klienti mountuji nfs4 only)

Protoze kazde spojeni se navazuje na kombinaci ip/mac. Takze pokud je to klient, tak v pripade zmeny mac na to musi neco zareagovat a tedy se tu zmenu musi dozvedet ze site.
Existuje resource ocf:heartbeat:nfsnotify - sm-notify reboot notifications
s timto popisem:
This agent sends NFSv3 reboot notifications to clients which informs clients to reclaim locks.
Ten ale podle mě na NFS4 nebude mít žádný vliv. Tato resource komunikuje skrz RPC službu pomocí UDP. V mém případě je veškerá UDP komunikace u NFS4 vypnuta.

Ten klient navazuje s spojeni s virtual switchem nebo s nfs serverem?
Klient se připojuje přímo k virtuální IP serveru v článku to je IP 10.0.0.100

7
Server / Re:NFSv4 na CentOS 7.9 Pacemaker Clusteru
« kdy: 23. 04. 2021, 15:30:16 »
@czechsys:
Zřejmě se jedná o konfiguraci NFS3, kde existuje notifikace klientu, že je nějaká změna, ale u NFS4 to není.

@Jose D:
Z dokumentace ocf:heartbeat:nfsserver není zřejmé, že by sdílení stavů NFS bylo omezováno verzí NFS. V každém případě nemůžu potvrdit, že se aplikační stavy přenáší. Faktem ovšem je, že vytvořené soubory v tomto sdíleném adresáři mají aktuální datum a čas.

8
Server / NFSv4 na CentOS 7.9 Pacemaker Clusteru
« kdy: 23. 04. 2021, 13:15:23 »
Vážení kolegové a nadšenci.

Postavil jsem dvou nodový Pacemaker cluster na OS CentOS 7.9, na kterém testuji vysokou dostupnost služby NFS 4.2. Služba NFS4 již plně pracuje na TCP. Do nižší verze než je verze 4.0 nemůžeme jít, protože nepodporuje námi požadované ACL. Při této příležitosti jsem narazil na zajímavý problém s rychlostí obnovení navázané komunikace mezi serverem a klientem, při přepnutí virtuální IP adresy z jedno nodu na druhý.
Nody mají připojený iSCSI disk s LVM, tento disk se exportuje pro NFS sdílení. Celé to zastřešuje virtuální IP adresa. Je také použit parametr pro sdílení stavových informací pro NFS, je umístěn na iSCSI svazku, který je připojen na obou nodech.
Konfigurace clusteru je následující (jedná se o skupinu):

Kód: [Vybrat]
  Resource: lvm (class=ocf provider=heartbeat type=LVM)
   Attributes: exclusive=true volgrpname=data

  Resource: iscsidrive (class=ocf provider=heartbeat type=Filesystem)
   Attributes: device=/dev/mapper/data directory=/mnt/data fstype=xfs

  Resource: nfs-daemon (class=ocf provider=heartbeat type=nfsserver)
   Attributes: nfs_no_notify=true nfs_shared_infodir=/mnt/data/nfsconf nfsd_args="-N2 -N3 -V4 --grace-time 10"

  Resource: nfs-share (class=ocf provider=heartbeat type=exportfs)
   Attributes: clientspec=10.0.0.0/255.0.0.0 directory=/mnt/data/data/ fsid=1 options=rw,sync,no_root_squash

  Resource: nfs_ip (class=ocf provider=heartbeat type=IPaddr2)
   Attributes: cidr_netmask=24 ip=10.0.0.100

/etc/nfs.conf

Kód: [Vybrat]
[nfsd]
vers4=y
vers4.2=y

konfigurace v /etc/sysconfig/nfs je dynamicky upravovaná pomocí resource ocf:heartbeat:nfsserver pacemakerem (viz. parametr nfsd_args a nfs_no_notify)

použité balíčky na nodech:

Kód: [Vybrat]
libnfsidmap-0.25-19.el7.x86_64
corosync-2.4.5-7.el7_9.1.x86_64
nfs-utils-1.3.0-0.68.el7.x86_64
corosync-qdevice-2.4.5-7.el7_9.1.x86_64
corosynclib-2.4.5-7.el7_9.1.x86_64
resource-agents-4.1.1-61.el7_9.8.x86_64
kernel: Linux node 3.10.0-1160.21.1.el7.x86_64 #1 SMP Tue Mar 16 18:28:22 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

použité balíčky na nfs klientovi:

Kód: [Vybrat]
libnfsidmap-0.25-19.el7.x86_64
nfs-utils-1.3.0-0.68.el7.x86_64
Linux nfs-client 3.10.0-1160.21.1.el7.x86_64 #1 SMP Tue Mar 16 18:28:22 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Nebudu se rozepisovat o stonith, protože ten funguje v rámci možností našeho virtuálního prostředí poskytovatele.

Nyní k problému. Dobu výpadku jsem testoval tak, že jsem si napsal skript, který na NFS klientovi otevřel soubor pro zápis a každou sekundu zapisoval do tohoto souboru datum s časem, aniž by se soubor uzavřel. Zároveň jsem z tohoto souboru četl pomocí tail -f. Při odstavení jednoho nodu clusteru pomocí pcs standby node1 se prvně zastaví služby na stroji node1 a následně se nastartují služby na stroji node2. Celá tato akce časově zabere max. 15s. Při prvním výpadku od připojení sdíleného svazku, trvá na klientovi přerušení zápisu cca. 20s. Při dalším obnovení node1 pcs unstandby node1 a následném shozením služeb na stroji node2 již tento výpadek není 20s, ale zhruba 3,5min. Tato doba se dalšími shozeními již nemění. Až do doby, kdy provedu umount sdílené složky a nový mount. Vždy po prvním shození aktivního nodu se reset spojení a obnovení komunikace mezi klientem a serverem provede do 20s.
Protože potřebuji tuto službu pokud možná s co nejkratším výpadkem a 3,5min je opravdu dost dlouho, začal jsem zjištovat co se děje po dobu výpadku.

Z tcpdumpu jsem zjistil, že virtuální switch správně identifikuje, že se změnila MAC adresa virtuální ipadresy 10.0.0.100 a packety se začnou směřovat na správný stroj. Je zřejmé, že nový stroj neví co má s TCP stackem, který byl určen pro původní stroj dělat a tak na něj nereaguje. A tak čeká na reset spojení. Ten ovšem přijde vždy až po 8. retransmissi packetu což odpovídá cca 3,5min. RTO, které je dané normou RFC793, není dost možné změnit, protože je dynamicky ovlivněné stavem linky a doba do retransmisse se každou další retransmissí dvojnásobí. Počet retransmissí, které je možné do jisté míry ovlivnit, se mi nijak nepodařilo u NFS změnit. I přes nastavené parametry mountu klienta timeo=3 a retrans=1 a sysctl nastavení net.ipv4.tcp_retries2=3 se změna počtu retransmissí nijak nezměnila. Testoval jsem zda změna hodnoty net.ipv4.tcp_retries2 opravdu funguje a např. u SSH se opravdu spojení zresetovalo po 3. retransmissi packetu, ale NFS tuto volbu ignoruje. Toto ovšem neplatí při první odstávce jednoho z aktivních nodů, po novém mountu sdílené složky. Zde je pouze 5 retransmissí, po kterých se spojení resetuje. Stejně tak se to chová i po delší přestávce testování (když se např. 1 den nody nevypínají a nezapínají).

Také jsem zkoušel sychronizaci tcp stavů pomocí resource ocf:heartbeat:conntrackd. Pomocí služby conntrackd a jejích informací je vidět, že se stavy korektně předávají na druhý server, ale aplikace stejně čeká na reset tcp spojení.

Proto prosím o radu co jsem v konfiguraci přehlédl a nebo spatně nastavil, že se mi cluster takto podivně chová.

Předem děkuji za názory a nápady.

Stran: [1]