Dataaja95:n verkko ja virtualisointiprojektit

[dataaja95]

Terve
Luodaas vihdoinkin pääketju omille projekteille, ettei foorumi täyty turhista ketjuista ja samoista kysymyksistä eri ketjuissa.
Tarkoituksena on rakennella virtualisointiklusteri käyttäen hypervisorina proxmoxia ja levyjärjestelmänä cephiä, mutta nuo ovat vasta tulevaisuuden hankkeita ja tällähetkellä yksi hosti pyörittelee vain virtuaalikoneita btrfs levyjärjestelmällä. Verkon rakenne on seuraava
Ensin on ulkopuolinen gatewaykone kiinteällä ip-osoitteella, josta on muodostettu wireguard-vpn yhteys klienttikoneille, jossa pyörivät palvelut mitä haluan tuon kiinteän ip-osoitteen kautta käyttää. ensimmäinen pohdintani koskisikin wireguardin reititystä, nyt clientin konffiin on heitetty allowedips 0.0.0.0, joka reitittää kaiken liikenteen vpn:n kautta, ilmeisesti policyroutingilla voisin erotella esim dns:n reitityksen muuhun gatewayhyn kuin tuo vpn, mutta miten se tapahtuu, meikäläisen osaaminen loppuu tässäkohtaa
Clienttikoneen vpn ip: 10.10.10.2
gateway vpn ip: 10.10.10.1
Clienttikoneen sisäverkon ip: 192.168.3.8
clienttikoneen sisäverkon gateway: 192.168.3.1
Jos haluaisin esim reitittää clientin kaikki dns kyselyt normaalisti sisäverkon gatewayn kautta, miten se onnistuisi
ip route show näyttää clientillä näin
Huomiona tähän, että wg0 on wireguardin verkkoliitäntä ja eth0 on internetin ja sisäverkon menevä liitäntä.
default via 192.168.3.1 dev eth0 onlink 10.10.10.0/24 dev wg0 proto kernel scope link src 10.10.10.2
192.168.3.0/24 dev eth0 proto kernel scope link src 192.168.3.8
toivottavasti tästä kuvauksesta sai selvää mitä ajan takaa, voin selostaa koko sisäverkon rakenteen hieman myöhemmin, mutta jos ottaisimme yhden ongelman ja projektin kerrallaan.

 

[juuhokei]

Kannattaa tehdä ihan kuva tästä toteutuksesta, tekstinä hyvin hankala saada käsitystä.

 

[dataaja95]

Kannattaa tehdä ihan kuva tästä toteutuksesta, tekstinä hyvin hankala saada käsitystä.

Mielelläni tekisin, mutta täysin sokealle adminille tuo on aikapitkälti mahdotonta.

 

[gulassi]

Itselleni ei oikein aukea mitä tuolla Wireguardin käytöllä tavoitellaan. Jos se siis on käytössä sisäverkon puolella. Jos halutaan käyttää yhtä julkista IP:tä useammalla koneella olevien palveluiden ajamiseen niin käyttäisin joko ihan vaan NAT:ia tai jotain kuormantasaajaa, kuten HAproxy. Jos liikennettä halutaan eristää toisistaan sisäverkossa niin helpompaa olisi käyttää VLAN:ja ja useampaa IP-aliverkkoa.

 

[dataaja95]

Itselleni ei oikein aukea mitä tuolla Wireguardin käytöllä tavoitellaan. Jos se siis on käytössä sisäverkon puolella. Jos halutaan käyttää yhtä julkista IP:tä useammalla koneella olevien palveluiden ajamiseen niin käyttäisin joko ihan vaan NAT:ia tai jotain kuormantasaajaa, kuten HAproxy. Jos liikennettä halutaan eristää toisistaan sisäverkossa niin helpompaa olisi käyttää VLAN:ja ja useampaa IP-aliverkkoa.

Wireguardyhteys tulee siis ulkoverkossa olevalta palvelimelta sisäverkon palvelimelle, koneelta, jossa on kiinteä ip-osoite, tällä saadaan kaikki palvelut, niin meilit kuin muutkin jne näkymään kiinteän ip-osoitteen takaa, joka ei ole kuten kuluttajayhteyksissä dynaaminen. Tuo wireguard pyörii siis ulkoisella gatewaykoneella, jossa siis kiinteä ip- ja jonka kautta liikenne reititetään ulos verkosta.

 

[dataaja95]

Seuraava mietintöni koskisikin unboundin konffaamista, nyt on käynyt ilmi, että palvelimen ratelimit on asetettu liian alhaiseksi, jolloin unbound blokkaa joidenkin serverien dns-pyynnöt, koska niitä tulee liian monta sekunnissa, olen tuota yrittänyt asettaa korkeammaksi, mutta ainakaan /etc/unbound/unbound.conf tiedostoon asetettu ratelimit: 20 tai ratelimit-factor: 20 eivät tuota kohota, olen myös yrittänyt asettaa nuo arvot nollaan, jolloin kaikki dns pyynnöt pitäisi pudottaa, mutta mitään sen suhteen ei tapahdu. Oletuksena tuo on muistaakseni 10, joka aiheuttaa matrixserveriä eli synapsea käytettäessä dns-pyyntöjen blokkaamista.

 

[gulassi]

Wireguardyhteys tulee siis ulkoverkossa olevalta palvelimelta sisäverkon palvelimelle, koneelta, jossa on kiinteä ip-osoite, tällä saadaan kaikki palvelut, niin meilit kuin muutkin jne näkymään kiinteän ip-osoitteen takaa, joka ei ole kuten kuluttajayhteyksissä dynaaminen. Tuo wireguard pyörii siis ulkoisella gatewaykoneella, jossa siis kiinteä ip- ja jonka kautta liikenne reititetään ulos verkosta.

Onko tuo ulkoverkon palvelin siis jossain pilvessä tai konesalissa? Vähän vastaavia virityksiä olen tehnyt IPSec:llä, mutta pitäisi sen kyllä onnistua wireguardillakin. Oma wireguard osaaminen ei vielä riitä tuollaisiin jaettuihin routtauksiin, tällä hetkellä oma roadwarrior setup menee kaikki tai ei mitään tyylillä. Tarkoitus kyllä olisi säätää niin että vain sisäverkon palveluihin (sisältäen DNS) liikenne menisi tunneliin ja muuten suoraan nettiin.

Nopeasti Wireguardin saittia lukemalla, sääntöpohjainen reititys varmaan on avain onneen. Eli kaksi reititystaulua, toinen ohjaa tunneliin ja toinen tunnelin ohi, sitten vaan palomuuri- tai reitityssäännöillä ohjataan halutut paketit oikeaan reititystauluun.

 

[ztec]

Onko tuo ulkoverkon palvelin siis jossain pilvessä tai konesalissa? Vähän vastaavia virityksiä olen tehnyt IPSec:llä, mutta pitäisi sen kyllä onnistua wireguardillakin.

Generic Routing Encapsulation (GRE) toimisi ihan yhtä hyvin tuossa WG:n tilalla, jos ei salauksella ole väliä. Riippuen laitteista ja verkko-nopeuksista, salauksen vaikutus on joko täysin merkityksetön tai hyvin murskaava.

HAproxy:n kanssa voi olla ongelmia mm. IP osoitteiden kanssa, riippuu ihan mitä palveluita pyöritetään. Rikkoo hienosti erilaiset IP-pohjaiset rate-limit hommat esimerkiksi. Nää on sellaisia juttuja joissa ratkaisu pitää aina valita kokonaisuutta ajatellen. Verkossa kun on olemassa muitakin palveluita kuin webbi-sivut.

Ei WG mitään liikennettä kaappaa, siis sellaista, joka on ohjattu muualle kuin tunneliin. Eikä siihen tarvitse edes kahta reititystaulua, vaan ihan yksi normaali taulu riittää mainiosti. Eikä edes sellaisten palveluiden kanssa, missä voi määritellä osoitteet mitä käytetään, niin tarvitse edes. split-tunnelingia / policy routea. Koska liikenteen voi ohjata jo IP tasolla eri osoitteeseen, joka ei mene tunneliin.

 

[dataaja95]

Yritämpä asentaa zabbixia debian11 virtuaalikoneelle, mutta skriptiä jolla importataan database ja sen scema ei näytä asennuksessa olevan, skriptin pitäisi siaita kansiossa /usr/share/doc/zabbix-server-pgsql/, mutta kyseistä skriptiä ei tuolla kansiossa ole, näillä ohjeilla yritän saada hommaa toimimaan, mielenkiintoista, koska muutama vuosi sitten asentelin zabbixin eräälle debianvirtuaalille ja tuolloin kyseinen skripti oli olemassa

3 Server installation with PostgreSQL database

www.zabbix.com

Edittiä löytyikin tuo scemanluontityökalu kansiosta /usr/share/zabbix-sql-scripts/postgresql nimellä server.sql.gz, eli homma toimii
Kumpaa olette käyttäneet webbiserverinä nginxiä vai apachea zabbixasennuksissa.

 

[Hyrava]

Yritämpä asentaa zabbixia debian11 virtuaalikoneelle, mutta skriptiä jolla importataan database ja sen scema ei näytä asennuksessa olevan, skriptin pitäisi siaita kansiossa /usr/share/doc/zabbix-server-pgsql/, mutta kyseistä skriptiä ei tuolla kansiossa ole, näillä ohjeilla yritän saada hommaa toimimaan, mielenkiintoista, koska muutama vuosi sitten asentelin zabbixin eräälle debianvirtuaalille ja tuolloin kyseinen skripti oli olemassa

3 Server installation with PostgreSQL database

www.zabbix.com

Edittiä löytyikin tuo scemanluontityökalu kansiosta /usr/share/zabbix-sql-scripts/postgresql nimellä server.sql.gz, eli homma toimii
Kumpaa olette käyttäneet webbiserverinä nginxiä vai apachea zabbixasennuksissa.

Varmaan olisi kannattanut käyttää ajantasalla olevaa asennusohjetta: Download and install Zabbix

Itse olen sekä duunissa että kotona käyttänyt apachea zabbix-frontendille kun se oli vielä asennusvaiheessa huomattavasti tutumpi. Nykyään on tullut nginxilläkin tehtyä kaikenlaista mutta edelleenkin valitsisin varmaan apachen kun siihen ainakin saa kivasti valmiit frontendin valvontakikkareet zabbixiin, en tiedä onko vastaavia nginxille tehty.

 

[dataaja95]

Onko zabbixissa helppoa tapaa lisätä useita templateja yhteen hostgrouppiin, suoraanhan tuo onnistuu templaten asetuksista määräämällä se tiettyihin grouppeihin, mutta kun lisättävänä on useita templateja, on tuo hieman ikävää.

 

[dataaja95]

Varmaan olisi kannattanut käyttää ajantasalla olevaa asennusohjetta: Download and install Zabbix

Itse olen sekä duunissa että kotona käyttänyt apachea zabbix-frontendille kun se oli vielä asennusvaiheessa huomattavasti tutumpi. Nykyään on tullut nginxilläkin tehtyä kaikenlaista mutta edelleenkin valitsisin varmaan apachen kun siihen ainakin saa kivasti valmiit frontendin valvontakikkareet zabbixiin, en tiedä onko vastaavia nginxille tehty.

Apachella tuo myös itselläni pyörii. Tulipa tällainen templatevarasto vastaan, varmasti zabbixin tehokäyttäjille tuttu, mutta itselleni uusi tuttavuus, näyttäisi sisältävän vaikka mitä apachen templateista ja päätyen ciscon ja juniperin palomuureihin ja supermicron servereihin

GitHub - zabbix/community-templates: Zabbix Community Templates repository

Zabbix Community Templates repository. Contribute to zabbix/community-templates development by creating an account on GitHub.

github.com

 

[Hyrava]

Onko zabbixissa helppoa tapaa lisätä useita templateja yhteen hostgrouppiin, suoraanhan tuo onnistuu templaten asetuksista määräämällä se tiettyihin grouppeihin, mutta kun lisättävänä on useita templateja, on tuo hieman ikävää.

En nyt yhtäkkiä muista onko "Mass update" -toimintoa hostgroupeille mutta ainakin suoraan useammalle hostille pystyy lisäämään kerralla useita templateja.

 

[dataaja95]

Nyt taitaa apachen webbiserverin asetuksissa olla jokin virhe, zabbixin käyttöliittymän kielenä on oletuksena perus englanti, mutta heittää tällaista virhettä aina kun avaan webbiguin
Locale for language "en_US" is not found on the web server. Tried to set: en_US, en_US.utf8, en_US.UTF-8, en_US.iso885915, en_US.ISO8859-1, en_US.ISO8859-2, en_US.ISO8859-4, en_US.ISO8859-5, en_US.ISO8859-15, en_US.ISO8859-13, en_US.CP1131, en_US.CP1251, en_US.CP1251, en_US.CP949, en_US.KOI8-U, en_US.US-ASCII, en_US.eucKR, en_US.eucJP, en_US.SJIS, en_US.GB18030, en_US.GB2312, en_US.GBK, en_US.eucCN, en_US.Big5HKSCS, en_US.Big5, en_US.armscii8, en_US.cp1251, en_US.eucjp, en_US.euckr, en_US.euctw, en_US.gb18030, en_US.gbk, en_US.koi8r, en_US.tcvn. Unable to translate Zabbix interface.
Edittiä
ratkesi generoimalla localet uudelleen, otetaan toinen kuppi kahvia.

 

[dataaja95]

Mitäs ihmettä, olen lisännyt zabbixiin hosteille templaten linux by zabbix agent active, homma toimii ja hostien tiedot näytetään kauniisti, mutta jos poistan templaten hostilta ja lisään sen hostgrouppiin homma lakkaa toimimasta, hosti on tietenkin samassa hostgroupissa johon templaten lisäsin, muistaakseni jokin vastaavanlainen ongelma oli vuosia sitten, en vain muista miten tuon ratkaisin.
Edittiä
Ja odottelulla lähti toimimaan, mikäs olisi hyvä template freebsd hostien valvontaan, kannattaako käyttää tuota zabbixin perustemplatea vai pysyä siitä mahdollisimman kaukana.

 

[dataaja95]

Rupesimpa asentelemaan tässä postgresqlklusteria debianille käyttäen hyväkseni repmgr klusterointiratkaisua, mutta tökkää metadatan luontiin yritettäessä perustaa klusteria, olen siis luonut repmgr käyttäjän komennolla
createuser --superuser repmgr
Ja databasen komennolla createdb --owner=repmgr repmgr
Kun yritän rekisteröidä ensimmäistä nodea klusteriin saan seuraavan virheilmoituksen
[2023-06-01 17:24:43] [NOTICE] repmgrd (repmgrd 5.3.3) starting up
[2023-06-01 17:24:43] [INFO] connecting to database "host=192.168.3.12 user=repmgr dbname=repmgr"

[2023-06-01 17:24:43] [ERROR] no metadata record found for this node - terminating
[2023-06-01 17:24:43] [INFO] repmgrd terminating...

Komento jolla rekisteröinnin teen on
/usr/lib/postgresql/13/bin/repmgrd -f /etc/repmgr/13/repmgr.conf primary register
Jäin käsitykseen, että komennon primary register pitäisi nimenomaan luoda databaseen sopiva metadata klusterin käytettäväksi, mikäköhän tässä on vialla. Ohje jota sovellan on tehty centosille, mutta hieman tiedostopolkuja muuttamalla toimii myös debianilla. Onko kenelläkään tästä ratkaisusta kokemusta, tai olisiko suositeltavaa postgresql klusterointiratkaisua

How to Automate PostgreSQL 12 Replication and Failover with repmgr – Part 1

We will see how repmgr & it’s daemon repmgrd can automate the High Availability & failover of a three-node PostgreSQL 12 cluster.

www.2ndquadrant.com

Edittiä
ja oikea komento oli repmgrd -f /etc/repmgr/13/repmgr.conf primary create, eli homma lähti toimimaan.

 

[dataaja95]

Rupesimpa tutkiskelemaan freepbx järjestelmää, kyseeessä on siis centosin päälle rakennettun asteriskserveri joka vaikuttaa oikein käyttökelpoiselta ja mukavalta järjestelmältä, mutta miten saan määritettyä centoskoneelle kiinteän ip:n, en ole juurikaan aikaisemmin centosmailmassa säätänyt vaan debian on tutumpi järjestelmä, olen luonut kansioon /etc/sysconfig/network-scripts tiedoston ifcfg-eth0
Jossa sisältö on seuraava
TYPE="Ethernet"
PROXY_METHOD="none"
BROWSER_ONLY="no"
BOOTPROTO="static"
ipaddr=192.168.3.16
netmask=255.255.255.0
gateway=192.168.3.1
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_FAILURE_FATAL="no"
IPV6_ADDR_GEN_MODE="stable-privacy"
NAME="eth0"
UUID="fd079fd3-d08a-4a1e-8841-c1c80062056e"
DEVICE="eth0"
ONBOOT="yes"

Tällä konfiguraatiolla masiina ei saa minkäänlaista kiinteää ip-osoitetta. En ole siis centosin kanssa säätänyt aikaisemmin vaan järjestelmä on itselleni täysin vieras, alla siis centos 7.

 

[gulassi]

Centos on rhel pohjainen, joten rhel manuaalit toimii: Configuring IP Networking with ifcfg Files

nmcli komennolla voi katsella mitkä asetukset on voimassa ja myös säätää asetuksia, nmtui komennolla voi ”graafisesti” komentorivillä laittaa asetukset.

Itse ongelma johtunee siitä että nuo address jne on pienillä kirjaimilla.

 

[dataaja95]

Rupesimpa säätämään reverseproxya tietyille palveluille, mutta ongelmaksi on osoittautunut reititys. Konfiguraationi menee seuraavasti
Ensin on gatewaykone ulkoverkossa josta on vpn-yhteys tuolle reverseproxykoneelle, tämän gatewayn tarkoitus on tarjota julkinen ip domainille ja palveluille, reverseproxykoneelta ping kulkee ok, mutta esim matrixserveriltä joka on tuon reverseproxyn takana en pysty pingaamaan mitään kohdetta. Tcpdumpin logien perusteella paketit eivät löydä yksinkertaisesti perille, ilman vpn:ää taas ping kulkee ok. Matrixserverkoneen gatewayna toimii tämä reverseproxykone.
Matrixserver koneen ip on 192.168.3.8 ja reverseproxykoneen ip:nä on 192.168.3.24
matrixserverkoneen reititys on seuraava
default via 192.168.3.24 dev eth0 onlink
192.168.3.0/24 dev eth0 proto kernel scope link src 192.168.3.8
Edittiä ja tuo ratkesi sitten oikein mukavasti ajamalla reverseproxykoneella komento
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE

 

[dataaja95]

Nythän menee mielenkiintoiseksi. Yritän saada matrixpalvelinta toimimaan reverseproxyn läpi, mutta ongelmaksi näyttää muodostuneen yhdistettäessä vaikkapa alidomainiin matrix.domain.fi näytetään käyttävän domain.fi sertifikaatteja ja firefoxhan tästä tottakai valittaa. Olen pyytänyt certbotilla kummalekin domainille oman sertifikaattinsa
nginx konfiguraationi on tässä
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;

server_name domain.fi matrix.domain.fi;

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

access_log /var/log/nginx/matrix.access.log;
error_log /var/log/nginx/matrix.error.log;

client_max_body_size 50M;
}

ssl_certificate /etc/letsencrypt/live/domain.fi/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/domain.fi/privkey.pem; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

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

server_name matrix.domain.fi;

location / {
proxy_pass http://192.168.3.8:8449;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $host;

access_log /var/log/nginx/matrix.access.log;
error_log /var/log/nginx/matrix.error.log;

client_max_body_size 50M;
}
ssl_certificate /etc/letsencrypt/live/matrix.domain.fi/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/matrix.domain.fi/privkey.pem; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

server {
if ($host = domain.fi) {
return 301 https://$host$request_uri;
}

server_name domain.fi;
listen 80;
return 404;
}

server {
if ($host = matrix.domain.fi) {
return 301 https://$host$request_uri;
}

server_name matrix.domain.fi;
listen 80;
return 404;
}

 

[dome]

Konffin mukaan vain 8448 portista tarjotaan tuota alidomainin sertifikaattia. Jos 443 portista pitäisi tarjota myös alidomainille omaa serttiä niin tee sille oma server block oikeilla ssl_* määrityksillä ja ota alidomain pois tuosta ensimmäisestä server_namesta.

 

[ztec]

Sä se oot melkoinen tunkkaaja, olit näköjään tänkin SimpleX:n ehtinyt tunkkaan Matrixin lisäksi kuntoon.

Onhan se hienoa kun on oma viestintä infra ja kaikkea kommunikaatiota ei tarvitse luovuttaa noille jenkki jäteille.

 

[dataaja95]

Sä se oot melkoinen tunkkaaja, olit näköjään tänkin SimpleX:n ehtinyt tunkkaan Matrixin lisäksi kuntoon.

Onhan se hienoa kun on oma viestintä infra ja kaikkea kommunikaatiota ei tarvitse luovuttaa noille jenkki jäteille.

Todellakin, simplex vaikuttaa todella mietityltä ja hyvältä viestintäratkaisulta, otettu useita asioita huomioon, kuten metadatan vuotaminen, jota esi matrix ei pyri estämään. Toisaalta, simplexin ja matrixin lähestymistavat ovat täysin erilaiset, matrix luottaa täysin palvelimeen kun simplex taas ei, vaan kaikki liikenne pyörii clienttien välillä.

 

[dataaja95]

Olisi tarkoitus aloitella ketjun alussa mainittua proxmoxin klusterointiratkaisua ja levyjärjestelmänä toimisi tosiaan kolmen koneen cephklusteri. Onko tyypeillä kyseisestä ratkaisusta kokemusta, sudenkuoppia jota tuota asentaessa kannattaa välttää jne. Storageverkoksi ajattelin 10gbps kuituverkkoa, proxmoxin dokumemtaatioissa tuota suositellaan, varmasti 1gpbs verkollakin pärjättäisiin, mutta on tuota dataa kertynyt sen verran, että hitaus alkaisi ahdistamaan.

 

[dataaja95]

Seuraavaksi olisi operaationa postgresql klusterin konffaaminen. Ajattelin käyttää klusterijn failoveriin ja hallintaan repmgr:ää, mutta kaikki dokumentaatiot mitä löydän ovat tehty redhatille ja centosille, saan oikein mukavasti kyllä klusterin debianilla pystyyn ja solmut näkevät toisensa, mutta kun sammutan primarynoden eli siis noden1 koko klusteri kuolee, ideaalitilanteessa noden2 pitäisi huomata noden1 alasmeno ja korottaa itsensä primarynodeksi
Silloin kun kaikki toimii

postgres@postgresql02:/root$ repmgr cluster show -f /etc/repmgr/13/repmgr.conf
1 | PG-Node1 | primary | * running | | default | 100 | r
2 | PG-Node2 | standby | running | PG-Node1 | default | 60 | r
3 | PG-Node3 | standby | running | PG-Node1 | default | 40 | r
4 | PG-Node-Witness | witness | * running | PG-Node1 | default | 0 | r

Ja kun klusterin primarynode sammutetaan on tuloksena täydellinen klusterin hajoaminen

postgres@postgresql02:/root$ repmgr cluster show -f /etc/repmgr/13/repmgr.conf
1 | PG-Node1 | primary | ? unreachable | ? | default | 100 r
2 | PG-Node2 | standby | running | ? PG-Node1 | default | 60 r
3 | PG-Node3 | standby | running | ? PG-Node1 | default | 40 r
4 | PG-Node-Witness | witness | * running | ? PG-Node1 | default | 0 r

- unable to connect to node "PG-Node1" (ID: 1)
- node "PG-Node1" (ID: 1) is registered as an active primary but is unreachabe
- unable to connect to node "PG-Node2" (ID: 2)'s upstream node "PG-Node1" (ID)
- unable to determine if node "PG-Node3" (ID: 3) is attached to its upstream )
- unable to connect to node "PG-Node-Witness" (ID: 4)'s upstream node "PG-Nod)


Onko kukaan yrittänyt saada repmgr:ää toimimaan postgresql:n kanssa debianympäristössä vai mikä on suositeltu klusterinhallintaratkaisu, jota postgresql:n kanssa käytetään
Tässä vielä node2:n repmgr:n konfiguraatiotiedosto
node_id=2
node_name='PG-Node2'
conninfo='host=192.168.3.13 user=repmgr dbname=repmgr'
data_directory='/var/lib/postgresql/15/main'
failover='automatic'
promote_command='/usr/lib/postgresql/15/bin/repmgr standby promote -f /etc/repmgr/13/repmgr.conf --/var/repmgr/13/repmgr-promote.log'
follow_command='/usr/lib/postgresql/15/bin/repmgr standby follow -f /etc/repmgr/13/repmgr.conf --/var/log/repmgr-follow.log --upstream-2=%n'
priority=60
monitor_interval_secs=2
connection_check_type='ping'
reconnect_attempts=4
reconnect_interval=8
primary_visibility_consensus=true
standby_disconnect_on_failover=true
repmgrd_service_start_command='sudo /usr/bin/systemctl start repmgrd.service'
repmgrd_service_stop_command='sudo /usr/bin/systemctl stop repmgrd.service'
service_start_command='sudo /usr/bin/systemctl start postgresql.service'
service_stop_command='sudo /usr/bin/systemctl stop postgresql.service'
service_restart_command='sudo /usr/bin/systemctl restart postgresql.service'
service_reload_command='sudo /usr/bin/systemctl reload postgresql.service'
monitoring_history=yes
log_status_interval=60
primary_visibility_consensus=true
standby_disconnect_on_failover=true
Näillä ohjeilla yritän repmgr:ää konffailla.

How to Automate PostgreSQL 12 Replication and Failover with repmgr – Part 1

We will see how repmgr & it’s daemon repmgrd can automate the High Availability & failover of a three-node PostgreSQL 12 cluster.

www.2ndquadrant.com

How to Automate PostgreSQL 12 Replication and Failover with repmgr – Part 2

This is the second installment of a two-part series on 2ndQuadrant’s repmgr, an open-source high-availability tool for PostgreSQL. In the first part, we set up a three-node PostgreSQL 12 cluster along with a “witness” node. The cluster consisted of a primary node and two standby nodes. The...

www.2ndquadrant.com

 

[dome]

Kyllä tuo debianilla toimii ok ilman kummempaa säätöä kun konffit on kondiksessa. Onhan sulla repmgrd ajossa kaikilla nodeilla mikä hanskaa juurikin tuon automaattisen failoverin? Muistaakseni pitää vielä erikseen enabloida /etc/defaults/repmgrd konffista. Ootko koittanut käsin repmgr:llä ajaa promotea jollekin toiselle nodelle, että se toimii ok?

 

[dataaja95]

Kyllä tuo debianilla toimii ok ilman kummempaa säätöä kun konffit on kondiksessa. Onhan sulla repmgrd ajossa kaikilla nodeilla mikä hanskaa juurikin tuon automaattisen failoverin? Muistaakseni pitää vielä erikseen enabloida /etc/defaults/repmgrd konffista. Ootko koittanut käsin repmgr:llä ajaa promotea jollekin toiselle nodelle, että se toimii ok?

Komennolla repmgr -f /etc/repmgr/13/repmgr.conf standby promote saan nostettua esim kakkosnoden primaryksi oikein hienosti, mutta automaattisesti tuo ei toimi. Olen enabloinut repmgr:n tiedostosta /etc/default/repmgrd, sisältönä on kaikilla nodeilla seuraava. Ilmeisesti heittämäni repmgr. conf on oikein ja postgresql:n käynnistyskomennot sun muut ok.

# default settings for repmgrd. This file is source by /bin/sh from
# /etc/init.d/repmgrd

# disable repmgrd by default so it won't get started upon installation
# valid values: yes/no
REPMGRD_ENABLED=yes

# configuration file (required)
REPMGRD_CONF="/etc/13/repmgr/repmgr.conf"

# additional options
#REPMGRD_OPTS=""

# user to run repmgrd as
REPMGRD_USER=postgres

# repmgrd binary
REPMGRD_BIN=/usr/bin/repmgrd

# pid file
REPMGRD_PIDFILE=/var/run/repmgrd.pid
promote

 

[Hyrava]

Komennolla repmgr -f /etc/repmgr/13/repmgr.conf standby promote saan nostettua esim kakkosnoden primaryksi oikein hienosti, mutta automaattisesti tuo ei toimi. Olen enabloinut repmgr:n tiedostosta /etc/default/repmgrd, sisältönä on kaikilla nodeilla seuraava. Ilmeisesti heittämäni repmgr. conf on oikein ja postgresql:n käynnistyskomennot sun muut ok.

# default settings for repmgrd. This file is source by /bin/sh from
# /etc/init.d/repmgrd

# disable repmgrd by default so it won't get started upon installation
# valid values: yes/no
REPMGRD_ENABLED=yes

# configuration file (required)
REPMGRD_CONF="/etc/13/repmgr/repmgr.conf"

# additional options
#REPMGRD_OPTS=""

# user to run repmgrd as
REPMGRD_USER=postgres

# repmgrd binary
REPMGRD_BIN=/usr/bin/repmgrd

# pid file
REPMGRD_PIDFILE=/var/run/repmgrd.pid
promote

Onko tuo boldattu polku oikein? Varmaan pitäisi olla repmgr/13 eikä 13/repmgr ?

 

[dome]

Ok, eli repmgr:n konffi vaikuttaa oikealta siinä tapauksessa. Debianilla pitäisi generoitua systemd service tuolle repmgrd:lle /etc/init.d/repmgrd:stä. Onko service tulilla ja repmgrd prosessi oikeasti käynnissä? Alla oleva parametri ei näytä oikealta /etc/defaults/repmgrd tiedostossa. Polku pitäisi oletettavasti olla /etc/repmgr/13/repmgr.conf

# configuration file (required)
REPMGRD_CONF="/etc/13/repmgr/repmgr.conf"

repmgr.confiin kannattaa lisätä:
log_level = 'INFO'
log_facility = 'STDERR'
log_file = '/var/log/postgresql/repmgr.log'

repmgrd:n pitäisi logitella tasaisin väliajoin ko. noden tilaa jos/kun se on toiminnassa.

 

[dataaja95]

Ok, eli repmgr:n konffi vaikuttaa oikealta siinä tapauksessa. Debianilla pitäisi generoitua systemd service tuolle repmgrd:lle /etc/init.d/repmgrd:stä. Onko service tulilla ja repmgrd prosessi oikeasti käynnissä? Alla oleva parametri ei näytä oikealta /etc/defaults/repmgrd tiedostossa. Polku pitäisi oletettavasti olla /etc/repmgr/13/repmgr.conf

# configuration file (required)
REPMGRD_CONF="/etc/13/repmgr/repmgr.conf"

repmgr.confiin kannattaa lisätä:
log_file = '/var/log/postgresql/repmgr.log'

repmgrd:n pitäisi logitella tasaisin väliajoin ko. noden tilaa jos/kun se on toiminnassa.

Nyt tiedoston polku vaihdettu oikeaksi eli REPMGRD_CONF="/etc/repmgr/13/repmgr.conf"
repmgrd palvelu näyttäisi olevan käynnissä, nyt säätöjen jälkeen meikäläisellä näyttäisi olevan node2 myös primaryna, miten saan pudotettua tuon takaisin standbyksi.

 

[dome]

Nyt tiedoston polku vaihdettu oikeaksi eli REPMGRD_CONF="/etc/repmgr/13/repmgr.conf"
repmgrd palvelu näyttäisi olevan käynnissä, nyt säätöjen jälkeen meikäläisellä näyttäisi olevan node2 myös primaryna, miten saan pudotettua tuon takaisin standbyksi.

Sanoit sille promote, eli sen kuuluukin olla primary. node3 olisi vain pitänyt kääntää myös seuraamaan uutta primaryä (repmgr standby follow) promoten jälkeen minkä repmgrd olisi tehnytkin jos se olisi toiminut oikein. Oikeassa elämässä se alhaalla käynyt node1 olisi nyt väärässä tilassa ja sen tuominen ylös primarynä voisi pahimmillaan aiheuttaa split brain tilanteen jos clientit jatkaisi kirjoittamista sille. repmgrd ei tiputa vanhaa primaryä mukaan klusteriin standbynä automaattisesti sen noustessa ylös vaan se pitää hoitaa manuaalisesti. Turvallisin tapa olisi alustaa se pgbasebackup:lla (repmgr standby clone) nykyisestä primarystä, jos ei voi olla varma mihin tilaan se jäi mennessään alas. Toki testaillessa ei ole niin justiinsa. Jos node3 replikoi edelleen node1:ltä, niin node2:n muuttaminen takaisin standbyksi pitäisi onnistua:

repmgr node rejoin 'host=<node1 ip> user=repmgr dbname=repmgr'

ja postgresql pitää olla sammutettuna kun tuon ajelee.

 

[dataaja95]

Sanoit sille promote, eli sen kuuluukin olla primary. node3 olisi vain pitänyt kääntää myös seuraamaan uutta primaryä (repmgr standby follow) promoten jälkeen minkä repmgrd olisi tehnytkin jos se olisi toiminut oikein. Oikeassa elämässä se alhaalla käynyt node1 olisi nyt väärässä tilassa ja sen tuominen ylös primarynä voisi pahimmillaan aiheuttaa split brain tilanteen jos clientit jatkaisi kirjoittamista sille. repmgrd ei tiputa vanhaa primaryä mukaan klusteriin standbynä automaattisesti sen noustessa ylös vaan se pitää hoitaa manuaalisesti. Turvallisin tapa olisi alustaa se pgbasebackup:lla (repmgr standby clone) nykyisestä primarystä, jos ei voi olla varma mihin tilaan se jäi mennessään alas. Toki testaillessa ei ole niin justiinsa. Jos node3 replikoi edelleen node1:ltä, niin node2:n muuttaminen takaisin standbyksi pitäisi onnistua:

repmgr node rejoin 'host=<node1 ip> user=repmgr dbname=repmgr'

ja postgres pitää olla sammutettuna kun tuon ajelee.

Tällaista heittää kun ajan tuon komennon
NOTICE: rejoin target is node "PG-Node1" (ID: 1)
NOTICE: pg_rewind execution required for this node to attach to rejoin target node 1
HINT: provide --force-rewind

ja komennolla
repmgr node rejoin -h node1ip -U repmgr -d repmgr --force-rewind -f /etc/repmgr/13/repmgr.conf

antaa tällaista
ERROR: --force-rewind specified but pg_rewind cannot be used
DETAIL: "wal_log_hints" is set to "off" and data checksums are disabled

Olisiko tässä nyt käynyt kuuluisa splitbrain ilmiö, Eikö tuon repmgr.confin pitäisi oikein toimiessaan automatisoida failoverprosessi.

 

[dome]

Tällaista heittää kun ajan tuon komennon
NOTICE: rejoin target is node "PG-Node1" (ID: 1)
NOTICE: pg_rewind execution required for this node to attach to rejoin target node 1
HINT: provide --force-rewind

ja komennolla
repmgr node rejoin -h node1ip -U repmgr -d repmgr --force-rewind -f /etc/repmgr/13/repmgr.conf

antaa tällaista
ERROR: --force-rewind specified but pg_rewind cannot be used
DETAIL: "wal_log_hints" is set to "off" and data checksums are disabled

Olisiko tässä nyt käynyt kuuluisa splitbrain ilmiö, Eikö tuon repmgr.confin pitäisi oikein toimiessaan automatisoida failoverprosessi.

Jeps eli wal_log_hints ei ole postgresql:n konffissa tulilla. Repmgr dokumentaatiossa lisää rejoinista ja pg_rewind vaatimuksista: https://www.repmgr.org/docs/4.3/repmgr-node-rejoin.html. Joudut siis alustamaan tuon node2:n, käytännössä postgresql sammuksiin, postgresql:n datahakemisto tyhjäksi ja repmgr clone node1:ltä + register (forcella) kuten varmaan klusteria pystytellessä jo teitkin pariin otteeseen.

Repmgr automatisoi hallitun switchoverin, eli primary roolin siirtämisen nodelta toiselle (--siblings-follow vivulla myös standbyt vaihtaa oikeaan primaryyn) ja automaattisen failoverin repmgrd:n avustuksella. Vanhaa failannutta primaryä se ei muuta automaattisesti standbyksi. On ylläpitäjän vastuulla selvittää ko. noden tila ja yrittää sen rejoinia standbynä, tai alustaa se kokonaan tarpeen mukaan.

 

[dataaja95]

Jeps eli wal_log_hints ei ole postgresql:n konffissa tulilla. Repmgr dokumentaatiossa lisää rejoinista ja pg_rewind vaatimuksista: https://www.repmgr.org/docs/4.3/repmgr-node-rejoin.html. Joudut siis alustamaan tuon node2:n, käytännössä postgresql sammuksiin, postgresql:n datahakemisto tyhjäksi ja repmgr clone node1:ltä + register (forcella) kuten varmaan klusteria pystytellessä jo teitkin pariin otteeseen.

Repmgr automatisoi hallitun switchoverin, eli primary roolin siirtämisen nodelta toiselle (--siblings-follow vivulla myös standbyt vaihtaa oikeaan primaryyn) ja automaattisen failoverin repmgrd:n avustuksella. Vanhaa failannutta primaryä se ei muuta automaattisesti standbyksi. On ylläpitäjän vastuulla selvittää ko. noden tila ja yrittää sen rejoinia standbynä, tai alustaa se kokonaan tarpeen mukaan.

Noniin ja sehän lähti toimimaan ja node2 näkyy nyt standbyna, edelleenkään failover ei toimi automaattisesti, kovasti repmgr:n logissa node2:lla näkyy että node 1:een ei saada yhteyttä, mutta ei edes yritä lähteä nostamaan node2 automaattisesti primaryksi.

 

[dome]

Noniin ja sehän lähti toimimaan ja node2 näkyy nyt standbyna, edelleenkään failover ei toimi automaattisesti, kovasti repmgr:n logissa node2:lla näkyy että node 1:een ei saada yhteyttä, mutta ei edes yritä lähteä nostamaan node2 automaattisesti primaryksi.

Koita tappaa pois ne kaikki mahdollisesti ajossa olevat repmgrd prosessit kaikilta nodeilta ja laita /etc/defaults/repmgrd tiedostoon:

REPMGRD_OPTS="--daemonize=false"

Ja sen jälkeen starttaa repmgrd kaikilla systemctl start repmgrd. Systemd:n kanssa parempi ajaa foregroundissa ko. prosessia ellei sille tee oma service konfiguraatiota missä oletetaan pääprosessin forkkaavan, mutta parempi mennä sillä mitä paketti tarjoaa. Kovasti siis vaikuttaa siltä, ettei se repmgrd ole ajossa oikein tai ajossa on joku setupin yhteydessä käsin startattu daemon mikä käyttää edelleen virheellistä konffia.

 

[dataaja95]

Koita tappaa pois ne kaikki mahdollisesti ajossa olevat repmgrd prosessit kaikilta nodeilta ja laita /etc/defaults/repmgrd tiedostoon:

REPMGRD_OPTS="--daemonize=false"

Ja sen jälkeen starttaa repmgrd kaikilla systemctl start repmgrd. Systemd:n kanssa parempi ajaa foregroundissa ko. prosessia ellei sille tee oma service konfiguraatiota missä oletetaan pääprosessin forkkaavan, mutta parempi mennä sillä mitä paketti tarjoaa. Kovasti siis vaikuttaa siltä, ettei se repmgrd ole ajossa oikein tai ajossa on joku setupin yhteydessä käsin startattu daemon mikä käyttää edelleen virheellistä konffia.

Edelleen sama ongelma, eli node 2 ei nouse primarynodeksi. Voisiko ongelma olla node2:n repmgr.confissa
Kyseinen konffi on tässä
node_id=2
node_name='PG-Node2'
conninfo='host=192.168.3.13 user=repmgr dbname=repmgr'
data_directory='/var/lib/postgresql/15/main'
failover='automatic'
log_level = 'INFO'
log_facility = 'STDERR'
log_file = '/var/log/postgresql/repmgr.log'

promote_command='/usr/lib/postgresql/15/bin/repmgr standby promote -f /etc/repmgr/13/repmgr.conf --/var/repmgr/13/repmgr-promote.log'
follow_command='/usr/lib/postgresql/15/bin/repmgr standby follow -f /etc/repmgr/13/repmgr.conf --/var/log/repmgr-follow.log --upstream-2=%n'
priority=60
monitor_interval_secs=2
connection_check_type='ping'
reconnect_attempts=4
reconnect_interval=8
primary_visibility_consensus=true
standby_disconnect_on_failover=true
repmgrd_service_start_command='sudo /usr/bin/systemctl start repmgrd.service'
repmgrd_service_stop_command='sudo /usr/bin/systemctl stop repmgrd.service'
service_start_command='sudo /usr/bin/systemctl start postgresql.service'
service_stop_command='sudo /usr/bin/systemctl stop postgresql.service'
service_restart_command='sudo /usr/bin/systemctl restart postgresql.service'
service_reload_command='sudo /usr/bin/systemctl reload postgresql.service'
monitoring_history=yes
log_status_interval=60
primary_visibility_consensus=true
standby_disconnect_on_failover=true

Heitetään vielä node1:n konffi, vaikka suhteellisen vastaava kuin node2:lla

node_id=1
node_name='PG-Node1'
conninfo='host=192.168.3.12 user=repmgr dbname=repmgr'
data_directory='/var/lib/postgresql/15/data'
node_id=2
node_name='PG-Node2'
conninfo='host=192.168.3.13 user=repmgr dbname=repmgr'
data_directory='/var/lib/postgresql/15/main'
failover='automatic'
log_level = 'INFO'
log_facility = 'STDERR'
log_file = '/var/log/postgresql/repmgr.log'
promote_command='/usr/lib/postgresql/15/bin/repmgr standby promote -f /etc/repmgr/13/repmgr.conf --/var/repmgr/13/repmgr-promote.log'
follow_command='/usr/lib/postgresql/15/bin/repmgr standby follow -f /etc/repmgr/13/repmgr.conf --/var/log/repmgr-follow.log --upstream-1=%n'
priority=60
monitor_interval_secs=2
connection_check_type='ping'
reconnect_attempts=4
reconnect_interval=8
primary_visibility_consensus=true
standby_disconnect_on_failover=true
repmgrd_service_start_command='sudo /usr/bin/systemctl start repmgrd.service'
repmgrd_service_stop_command='sudo /usr/bin/systemctl stop repmgrd.service'
service_start_command='sudo /usr/bin/systemctl start postgresql.service'
service_stop_command='sudo /usr/bin/systemctl stop postgresql.service'
service_restart_command='sudo /usr/bin/systemctl restart postgresql.service'
service_reload_command='sudo /usr/bin/systemctl reload postgresql.service'
monitoring_history=yes
log_status_interval=60
primary_visibility_consensus=true
standby_disconnect_on_failover=true
failover='automatic'
promote_command='/usr/lib/postgresql/15/bin/repmgr standby promote -f /etc/repmgr/13/repmgr.conf --/var/repmgr/13/repmgr-promote.log'
monitor_interval_secs=2
primary_visibility_consensus=true
standby_disconnect_on_failover=true
repmgrd_service_start_command='sudo /usr/bin/systemctl start repmgrd.service'
repmgrd_service_stop_command='sudo /usr/bin/systemctl stop repmgrd.service'
service_restart_command='sudo /usr/bin/systemctl restart postgresql.service'
service_reload_command='sudo /usr/bin/systemctl reload postgresql.service'
monitoring_history=yes
log_status_interval=60

 

[dataaja95]

Tällaista näyttää node1:n repmgr logi, ei edes yritä vaihtaa primaryksi automaattisesti kakkosnodea, vaan ykkösnode pysyy primaryna kunnes sen vaihtaa käsin
[2023-07-19 13:35:53] [INFO] attempting to reconnect to node "PG-Node1" (ID: 1)
[2023-07-19 13:35:53] [ERROR] connection to database failed
[2023-07-19 13:35:53] [DETAIL]
connection to server at "192.168.3.12", port 5432 failed: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.

[2023-07-19 13:35:53] [DETAIL] attempted to connect using:
user=repmgr dbname=repmgr host=192.168.3.12 connect_timeout=2 fallback_application_name=repmgr options=-csearch_path=
[2023-07-19 13:35:53] [WARNING] reconnection to node "PG-Node1" (ID: 1) failed
[2023-07-19 13:35:53] [WARNING] unable to connect to local node
[2023-07-19 13:35:53] [INFO] checking state of node 1, 1 of 6 attempts
[2023-07-19 13:35:53] [WARNING] unable to ping "user=repmgr dbname=repmgr host=192.168.3.12 connect_timeout=2 fallback_application_name=repmgr"
[2023-07-19 13:35:53] [DETAIL] PQping() returned "PQPING_NO_RESPONSE"
[2023-07-19 13:35:53] [INFO] sleeping 10 seconds until next reconnection attempt
[2023-07-19 13:36:03] [INFO] checking state of node 1, 2 of 6 attempts
[2023-07-19 13:36:03] [WARNING] unable to ping "user=repmgr dbname=repmgr host=192.168.3.12 connect_timeout=2 fallback_application_name=repmgr"
[2023-07-19 13:36:03] [DETAIL] PQping() returned "PQPING_NO_RESPONSE"
[2023-07-19 13:36:03] [INFO] sleeping 10 seconds until next reconnection attempt
[2023-07-19 13:36:13] [INFO] checking state of node 1, 3 of 6 attempts
[2023-07-19 13:36:13] [WARNING] unable to ping "user=repmgr dbname=repmgr host=192.168.3.12 connect_timeout=2 fallback_application_name=repmgr"
[2023-07-19 13:36:13] [DETAIL] PQping() returned "PQPING_NO_RESPONSE"
[2023-07-19 13:36:13] [INFO] sleeping 10 seconds until next reconnection attempt

 

[dome]

Mitä se logi sanoo kun 6 yritystä on takana? Oletuksenahan tuo siis odottelee minuutin (6x10sec), että kipannut primary tulisi takaisin ennen kuin failover tehdään.

 

[dataaja95]

Mitä se logi sanoo kun 6 yritystä on takana? Oletuksenahan tuo siis odottelee minuutin (6x10sec), että kipannut primary tulisi takaisin ennen kuin failover tehdään.

Eivätpä rivit tuosta muutu, ikään kuin node1 ei tajuaisi että olemassa on failover konffi jota pitää käyttää vaikka /etc/repmgrd tiedostossa on selkeästi määritelty conffiksi /etc/repmgr/13/repmgr.conf josta nuo asetukset löytyvät, myös palvelu repmgrd on käynnissä
Tässä kuitenkin vielä pätkä logia
2023-07-19 14:32:50] [DETAIL] attempted to connect using:
user=repmgr dbname=repmgr host=192.168.3.12 connect_timeout=2 fallback_application_name=repmgr options=-csearch_path=
[2023-07-19 14:32:50] [WARNING] reconnection to node "PG-Node1" (ID: 1) failed
[2023-07-19 14:32:50] [WARNING] unable to ping "host=192.168.3.12 user=repmgr dbname=repmgr"
[2023-07-19 14:32:50] [DETAIL] PQping() returned "PQPING_NO_RESPONSE"
[2023-07-19 14:32:50] [ERROR] unable to determine if server is in recovery
[2023-07-19 14:32:50] [DETAIL] query text is:
SELECT pg_catalog.pg_is_in_recovery()
[2023-07-19 14:32:50] [WARNING] unable to determine node recovery status

 

[dataaja95]

Tarkoituksena olisi luoda useampi domain eräälle postfixserverille. Ilmeisesti en pysty käyttämään eri ssl sertejä useammalla domainilla vaan postfix käyttää oletuksena sitä joka on määritetty viimeiseksi main.cf tiedostoon. Mikäli olen oikein ymmärtänyt useamman domainin postfixserverillä ainut ratkaisu on käyttää subject alternative sertiä johon määritetään kaikki domainit.

 

[dome]

Tarkoituksena olisi luoda useampi domain eräälle postfixserverille. Ilmeisesti en pysty käyttämään eri ssl sertejä useammalla domainilla vaan postfix käyttää oletuksena sitä joka on määritetty viimeiseksi main.cf tiedostoon. Mikäli olen oikein ymmärtänyt useamman domainin postfixserverillä ainut ratkaisu on käyttää subject alternative sertiä johon määritetään kaikki domainit.

Riittävän uusi postfix (>3.4) tukee SNI:tä ja sitä kautta nimikohtaisia sertifikaatteja. Postfix Configuration Parameters

Todennäköisesti kuitenkin helpompi tehdä yhdellä sertifikaatilla missä useampi nimi jos käytät esimerkiksi Let’s Encryptiä.

 

[ztec]

Riittävän uusi postfix (>3.4) tukee SNI:tä ja sitä kautta nimikohtaisia sertifikaatteja.

Jos serveri tukee SNI:tä, niin sitten vielä clienttien pitäisi. Eli voi olla aika syvä suo tuo.

 

[dome]

Jos serveri tukee SNI:tä, niin sitten vielä clienttien pitäisi. Eli voi olla aika syvä suo tuo.

Jep, siksi tuumasinkin että yksi sertti todennäköisesti helpoin (ja toimivin) vaihtoehto.

 

[dataaja95]

Tarkoituksena olisi hommata ebaysta neliporttinen intelin 1gbps verkkokortti muutamaan serveriin, mutta malleja näyttäisi olevan melko pirusti, olisiko guruilla hyviä ehdotuksia toimivista ratkaisuista linuxympäristössä.

 

[dataaja95]

Ja virtualisointiklusteria pitää ruveta rakentamaan tässä ensiviikon aikanaa, nyt pääpalvelin alhaalla teknisten syiden takia ja koska klusterointia ei vielä ole, kaikki palvelut ovat alhaalla, no tulipa opittua kantapään kautta että failover tulille ja välittömästi. pistän kohta mikrotikin kytkimiä tilaukseen.
Klusteri ja virtuaalikoneiden verkolle tällainen, vastaava kytkin jo meikäläiseltä löytyy, eli toinen samanlainen tulossa.

CRS326-24G-2S+RM | MikroTik

24 Gigabit port switch with 2 x SFP+ cages in 1U rackmount case, Dual boot (RouterOS or SwitchOS)

mikrotik.com

Storageverkolle eli cephille pelkästään ajattelin tällaista

CRS317-1G-16S+RM | MikroTik

Smart Switch, 1 x Gigabit LAN, 16 x SFP+ cages, Dual Core 800MHz CPU, 1GB RAM, 1U rackmount passive cooling case, Dual Power Supplies

mikrotik.com

 

[Hyrava]

Tarkoituksena olisi hommata ebaysta neliporttinen intelin 1gbps verkkokortti muutamaan serveriin, mutta malleja näyttäisi olevan melko pirusti, olisiko guruilla hyviä ehdotuksia toimivista ratkaisuista linuxympäristössä.

Ei ole mitään suositusta mutta tähän mennessä kaikki 1/2/4-porttiset intelin verkkokortit ovat kyllä uponneet linux-koneisiin käytännössä itsestään, tietty teaming-asetukset sun muut on saanut sitten luonnollisesti tapauskohtaisesti konffata jos moisia on tarvinnut. Mutta itsessään kaikki intelin kortit mitä itse olen käyttänyt ovat toimineet ihan heittämällä. Tietty nuo mitä olen testannut ovat olleet markkinoilla vähintään puolisen vuotta eli ihan uusimmille, juuri julkaistuille ei uskalla samaa käyttökokemusta. Ylipäätään intelin verkkokortit (ja muutkin intelin laitteet) ovat varsin hyvin tuettuna linuxeissa.

Ylipäätään varmaan yli 90% kaikista mitä ihmeellisimmistäkin verkkokorteista on toiminut heittämällä linuxissa vaikka mihinkään moderniin windowsiin niitä ei ole saanut enää toimiman. Varmaan ainoa verkkokortti mitä en linuxissa(kaan) ole saanut toimimaan on joku ihan kivikautinen Gatewayn valmistama 10Mbps kortti jossa oli vielä ohutethernet (BNC) ja AUI (D15) -liittimet RJ45:n lisäksi.

 

[dataaja95]

Mielenkiintoista, asentelen tässä erääseen serveriin proxmoxia ja installeri ei näytä tunnistavan emolevyn integroituja verkkokortteja, biosin mukaan kortit ovat intel W82574L mallia ja eikä myöskään debianin standardi-installeri tunnista verkkointerfaceja, ovatko nämä taas luokkaa ei toimi linuxissa ja helpommalla selviää hankkimalla intelin kunnon verkkokortin, vai puuttuuko nyt meikäläiseltä vain jokin firmware.

 

[Hyrava]

Mielenkiintoista, asentelen tässä erääseen serveriin proxmoxia ja installeri ei näytä tunnistavan emolevyn integroituja verkkokortteja, biosin mukaan kortit ovat intel W82574L mallia ja eikä myöskään debianin standardi-installeri tunnista verkkointerfaceja, ovatko nämä taas luokkaa ei toimi linuxissa ja helpommalla selviää hankkimalla intelin kunnon verkkokortin, vai puuttuuko nyt meikäläiseltä vain jokin firmware.

Heh, tuo näyttäisi pikaisen googlettelun perusteella olla joku ongelmallinen verkkoadapteri, sinänsä harvinaista inteliltä. Googlella löytyy paljon lisätietoja kuinka tuon saa toimimaan mutta muunmuassa ohjeistetaan päivittämään BIOS ja/tai asentamaan intelin joku ajuripaketti.

 

[dataaja95]

Heh, tuo näyttäisi pikaisen googlettelun perusteella olla joku ongelmallinen verkkoadapteri, sinänsä harvinaista inteliltä. Googlella löytyy paljon lisätietoja kuinka tuon saa toimimaan mutta muunmuassa ohjeistetaan päivittämään BIOS ja/tai asentamaan intelin joku ajuripaketti.

Joo, eli helpompaa on tilata esimerkiksi tällainen, kuin aloittaa tuon kanssa tappelua, meinasin pyhittää emolevyn interfacet hallintaliikenteelle, mutta onnistuuhan se toki erillisellä kortilla, ensimmäinen intel meikäläiselle jonka linuxyhteensopivuus on näin surkea.

Dell Intel I350-T2 V5XVT Dual Port Server Adapter PCIe Netzwerkkarte Voll. P # | eBay

Model I350-T2 / V5XVT / H81149-003. Netzwerkkarte Dual Port Server Adapter Voll Profile. Er ist voll funktionsfähig und wurde von einem verifizierten Verkäufer geprüft, gereinigt und getestet. und verstanden zu haben.

www.ebay.com

Noita intelin verkkokortteja tuntuu olevan eri valmistajien versioina, samasta verkkokortista tuntuu olevan niin dellin, lenovon kuin muidenkin valmistajien versioita, ilmeisesti toimivat kuitenkin muissakin kokoonpanoissa kuin valmistajien omissa palvelimissa, eli jos ostan esim dellin kortin, se ei ala valittamaan yhteensopimattomasta serveristä.

 

[dataaja95]

RUpesimpa konffaamaan mikrotikin crs326 kytkimeen lisää vlaneja mutta tuohonkin näyttäisi olevan useampi tapa. Peruskonffi näyttäisi menevän /interface/bridge/vlan alta, mutta vaihtoehtoisesti voisi käyttää myös /interface/vlan alavalikkoa, kumpi on oikea tapa tehdä vlanin konffaukset mikrotikkiin. Ilmeisesti kytkinmoodissa vlanien konffaus menee /interface/bridge/vlan alta., mutta mikä tuo /interface/vlan oikein on.