Pacemaker ne fonctionne pas

Adrien.D Membre non connecté
-
- Voir le profil du membre Adrien.D
- Inscrit le : 30/05/2011
- Site internet
- Groupes :
Sous Mageia2, pour faire du clustering, il n'existe plus Heartbeat (facile à configurer).
Voici mes deux serveurs:
192.168.56.201 nommé srv01
192.168.56.202 nommé srv02
Voici comment j'ai procédé:
Code BASH :
urpmi pacemaker urpmi corosync corosync-keygen scp /etc/corosync/authkey adrien@srv02:
sur srv02, j'ai remis les droits root sur le fichier authkey, en permission 400 et replacé le fichier au bon endroit.
Code BASH :
cp /etc/corosync/corosync.conf.example /etc/corosync/corosync.conf
Contenu de /etc/corosync/corosync.conf
Caché :
# Please read the corosync.conf.5 manual page
totem {
version: 2
crypto_cipher: none
crypto_hash: none
interface {
ringnumber: 0
bindnetaddr: 192.168.56.0
mcastaddr: 239.255.1.1
mcastport: 5405
ttl: 1
}
}
logging {
fileline: off
to_stderr: no
to_logfile: yes
logfile: /var/log/cluster/corosync.log
to_syslog: yes
debug: off
timestamp: on
logger_subsys {
subsys: QUORUM
debug: off
}
}
quorum {
}
service{
ver: 0
name: pacemaker
}
totem {
version: 2
crypto_cipher: none
crypto_hash: none
interface {
ringnumber: 0
bindnetaddr: 192.168.56.0
mcastaddr: 239.255.1.1
mcastport: 5405
ttl: 1
}
}
logging {
fileline: off
to_stderr: no
to_logfile: yes
logfile: /var/log/cluster/corosync.log
to_syslog: yes
debug: off
timestamp: on
logger_subsys {
subsys: QUORUM
debug: off
}
}
quorum {
}
service{
ver: 0
name: pacemaker
}
Les fichiers sont identiques sur les deux serveurs.
Code RUBY :
/etc/init.d/pacemaker start [root@srv01 adrien]# crm_verify -L error: unpack_resources: Resource start-up disabled since no STONITH resources have been defined error: unpack_resources: Either configure some or disable STONITH with the stonith-enabled option error: unpack_resources: NOTE: Clusters with shared data need STONITH to ensure data integrity Errors found during check: config not valid -V may provide more details [root@srv01 adrien]# crm_mon --one-shot ============ Last updated: Thu Jun 28 19:18:46 2012 Last change: Thu Jun 28 19:04:15 2012 Current DC: NONE 0 Nodes configured, unknown expected votes 0 Resources configured. ============
Et voila. Ce qui m'étonne c'est qu'on ne configure aucune IP Virtuelle...
J'ai suivi http://zeldor.biz/2010/12/activepassive-cluster-with-pacemaker-corosync/
/var/log/corosync/corosync.log => n'existe pas
crm configure property stonith-enabled=false ne fonctionne pas!
Help !
Y a que Mageia2 qui n'a pas heartbeat dans les dépots !!!
Édité par Adrien.D Le 28/06/2012 à 19h31
Config : PC Fixe : X470 GAMING PRO- AMD Ryzen 5 2600X - 16Go RAM - Radeon RX 560 (Pilote libre) - Gentoo Linux - GNOME Desktop - Kernel 5.10 LTS
Ancien Webmaster de MageiaLinuxOnline. Les remplaçants assurent !
Ancien Webmaster de MageiaLinuxOnline. Les remplaçants assurent !


Adrien.D Membre non connecté
-
- Voir le profil du membre Adrien.D
- Inscrit le : 30/05/2011
- Site internet
- Groupes :
j'ai essayé avec un autre tuto mais ça marche pas mieux.
J'ai demandé de l'aide sur le forum anglais: https://forums.mageia.org/en/viewtopic.php?f=8&t=2920&p=21972#p21972
On va attendre
Config : PC Fixe : X470 GAMING PRO- AMD Ryzen 5 2600X - 16Go RAM - Radeon RX 560 (Pilote libre) - Gentoo Linux - GNOME Desktop - Kernel 5.10 LTS
Ancien Webmaster de MageiaLinuxOnline. Les remplaçants assurent !
Ancien Webmaster de MageiaLinuxOnline. Les remplaçants assurent !


itilo Membre non connecté
-
- Voir le profil du membre itilo
- Inscrit le : 03/06/2011
Oui, je crois que peu de gens sur ce forum, ont ta problématique. Mais si tu connais bien heartbeat, pourquoi ne pas le mettre en œuvre: ça n'est pas une question de packages, mageia est du linux, et c'est ça qui compte (et par ailleurs je crois connaître des gens qui envisagent de d'utiliser mageia en tant que "serveur" opérationnel).
Je n'ai pas retrouvé le lien, mais j'avais lu, quelque part dans les 6 derniers mois que heartbeat était en fin de vie et remplacé par ???? je ne sais plus quoi.
Bon courage

Adrien.D Membre non connecté
-
- Voir le profil du membre Adrien.D
- Inscrit le : 30/05/2011
- Site internet
- Groupes :

Heartbeat n'existe pas sur la version 2 de Mageia. J'ai donc "laissé tombé" puisque la compilation n'arrive pas à se faire (avec l'aide de #mageia-fr)
Config : PC Fixe : X470 GAMING PRO- AMD Ryzen 5 2600X - 16Go RAM - Radeon RX 560 (Pilote libre) - Gentoo Linux - GNOME Desktop - Kernel 5.10 LTS
Ancien Webmaster de MageiaLinuxOnline. Les remplaçants assurent !
Ancien Webmaster de MageiaLinuxOnline. Les remplaçants assurent !


itilo Membre non connecté
-
- Voir le profil du membre itilo
- Inscrit le : 03/06/2011

Je n'ai pas le besoin, mais compte moi parmi tes supporters


Adrien.D Membre non connecté
-
- Voir le profil du membre Adrien.D
- Inscrit le : 30/05/2011
- Site internet
- Groupes :
ça marche pas. Pas mal de tutos indiquent qu'il faut aussi installer le paquet heartbeat.
Je reformate tout, et je réessaie. Peut être le kernel-desktop qui m'empêche de bien fonctionner ?
Config : PC Fixe : X470 GAMING PRO- AMD Ryzen 5 2600X - 16Go RAM - Radeon RX 560 (Pilote libre) - Gentoo Linux - GNOME Desktop - Kernel 5.10 LTS
Ancien Webmaster de MageiaLinuxOnline. Les remplaçants assurent !
Ancien Webmaster de MageiaLinuxOnline. Les remplaçants assurent !


ennael Membre non connecté
-
- Voir le profil du membre ennael
- Inscrit le : 03/04/2011
- Groupes :
-
Équipe Mageia
Pour heartbeat normal, c'est "deprecated". heartbeat est maintenant contenu dans les projets corosync et pacemaker.
Une doc plutôt bien faite à mon avis : http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Clusters_from_Scratch/
Attention à ton fichier de conf corosync. seul pacemaker v1 est supporté. Donc mets à jour ton fichier. Autre chose, au boot de la machine, corosync et pacemaker doivent être démarrés. Corosync prend en charge tous les services sauf pacemaker
Les dysfonctionnements observés sont liés au fait que crmd se crashe au bout de qques secondes. Je parierais sur un pb de définition de quorum , dans corosync.conf :
quorum {
provider: corosync_votequorum
expected_votes: 2
}
redémarrer corosync et pacemaker puis relancer la commande de desactivation de stonith
Enfin crm_verify -L ne devrait plus retourner d'erreur
Édité par ennael Le 04/07/2012 à 14h11

ennael Membre non connecté
-
- Voir le profil du membre ennael
- Inscrit le : 03/04/2011
- Groupes :
-
Équipe Mageia
ennael :
quorum {
provider: corosync_votequorum
expected_votes: 2
}
quorum {
provider: corosync_votequorum
expected_votes: 2
}
Rectification avec 2 noeuds le quorum n'est pas applicable donc
crm configure property no-quorum-policy=ignore

Adrien.D Membre non connecté
-
- Voir le profil du membre Adrien.D
- Inscrit le : 30/05/2011
- Site internet
- Groupes :
je n'ai pas eu le temps de tester.
Donc je laisse vide cette section?
Config : PC Fixe : X470 GAMING PRO- AMD Ryzen 5 2600X - 16Go RAM - Radeon RX 560 (Pilote libre) - Gentoo Linux - GNOME Desktop - Kernel 5.10 LTS
Ancien Webmaster de MageiaLinuxOnline. Les remplaçants assurent !
Ancien Webmaster de MageiaLinuxOnline. Les remplaçants assurent !


ennael Membre non connecté
-
- Voir le profil du membre ennael
- Inscrit le : 03/04/2011
- Groupes :
-
Équipe Mageia
Adrien.D :
Salut,
je n'ai pas eu le temps de tester.
Donc je laisse vide cette section?
je n'ai pas eu le temps de tester.
Donc je laisse vide cette section?
non seulement il faut la laisser vide mais exécuter le crm configure

Adrien.D Membre non connecté
-
- Voir le profil du membre Adrien.D
- Inscrit le : 30/05/2011
- Site internet
- Groupes :
OK, je réessaierai, je ne suis pas sur place.
En fait, lorsque j'en suis à
Citation :
crm configure property stonith-enabled=false
Cette commande me retourne une erreur.
Je dois donc exécuter quelle commande avant ?
Celle ci:
Citation :
crm configure primitive FAILOVER-ADDR ocf:heartbeat:IPaddr2 params ip="192.168.56.200" nic="eth0" op monitor interval="10s" meta is-managed="true"
??
Merci
Config : PC Fixe : X470 GAMING PRO- AMD Ryzen 5 2600X - 16Go RAM - Radeon RX 560 (Pilote libre) - Gentoo Linux - GNOME Desktop - Kernel 5.10 LTS
Ancien Webmaster de MageiaLinuxOnline. Les remplaçants assurent !
Ancien Webmaster de MageiaLinuxOnline. Les remplaçants assurent !


Adrien.D Membre non connecté
-
- Voir le profil du membre Adrien.D
- Inscrit le : 30/05/2011
- Site internet
- Groupes :
J'ai créé deux machines virtuelles en mode pont sur ma machine physique:
192.168.1.201 => info01
192.168.1.202 => info02
pings OK
firewall désactivé
hists configuré.
Citation :
[root@info01 adrien]# rpm -qa | grep corosync; rpm -qa | grep pacemaker
corosync-2.0.0-3.mga2
lib64corosync4-2.0.0-3.mga2
pacemaker-1.1.7-2.mga2
corosync-2.0.0-3.mga2
lib64corosync4-2.0.0-3.mga2
pacemaker-1.1.7-2.mga2
/etc/corosync/corosync.conf :
[root@info01 adrien]# cat /etc/corosync/corosync.conf
# Please read the corosync.conf.5 manual page
aisexec {
user: root
group: root
}
totem {
version: 2
# cypto_cipher and crypto_hash: Used for mutual node authentication.
# If you choose to enable this, then do remember to create a shared
# secret with "corosync-keygen".
crypto_cipher: none
crypto_hash: none
# interface: define at least one interface to communicate
# over. If you define more than one interface stanza, you must
# also set rrp_mode.
interface {
# Rings must be consecutively numbered, starting at 0.
ringnumber: 0
# This is normally the *network* address of the
# interface to bind to. This ensures that you can use
# identical instances of this configuration file
# across all your cluster nodes, without having to
# modify this option.
bindnetaddr: 192.168.1.0
# However, if you have multiple physical network
# interfaces configured for the same subnet, then the
# network address alone is not sufficient to identify
# the interface Corosync should bind to. In that case,
# configure the *host* address of the interface
# instead:
bindnetaddr: 192.168.1.0
# When selecting a multicast address, consider RFC
# 2365 (which, among other things, specifies that
# 239.255.x.x addresses are left to the discretion of
# the network administrator). Do not reuse multicast
# addresses across multiple Corosync clusters sharing
# the same network.
mcastaddr: 226.94.1.1
# Corosync uses the port you specify here for UDP
# messaging, and also the immediately preceding
# port. Thus if you set this to 5405, Corosync sends
# messages over UDP ports 5405 and 5404.
mcastport: 4000
# Time-to-live for cluster communication packets. The
# number of hops (routers) that this ring will allow
# itself to pass. Note that multicast routing must be
# specifically enabled on most network routers.
ttl: 1
}
}
logging {
# Log the source file and line where messages are being
# generated. When in doubt, leave off. Potentially useful for
# debugging.
fileline: off
# Log to standard error. When in doubt, set to no. Useful when
# running in the foreground (when invoking "corosync -f")
to_stderr: no
# Log to a log file. When set to "no", the "logfile" option
# must not be set.
to_logfile: yes
logfile: /var/log/cluster/corosync.log
# Log to the system log daemon. When in doubt, set to yes.
to_syslog: yes
# Log debug messages (very verbose). When in doubt, leave off.
debug: off
# Log messages with time stamps. When in doubt, set to on
# (unless you are only logging to syslog, where double
# timestamps can be annoying).
timestamp: on
logger_subsys {
subsys: QUORUM
debug: off
}
}
quorum {
# Enable and configure quorum subsystem (default: off)
# see also corosync.conf.5 and votequorum.5
#provider: corosync_votequorum
}
# Please read the corosync.conf.5 manual page
aisexec {
user: root
group: root
}
totem {
version: 2
# cypto_cipher and crypto_hash: Used for mutual node authentication.
# If you choose to enable this, then do remember to create a shared
# secret with "corosync-keygen".
crypto_cipher: none
crypto_hash: none
# interface: define at least one interface to communicate
# over. If you define more than one interface stanza, you must
# also set rrp_mode.
interface {
# Rings must be consecutively numbered, starting at 0.
ringnumber: 0
# This is normally the *network* address of the
# interface to bind to. This ensures that you can use
# identical instances of this configuration file
# across all your cluster nodes, without having to
# modify this option.
bindnetaddr: 192.168.1.0
# However, if you have multiple physical network
# interfaces configured for the same subnet, then the
# network address alone is not sufficient to identify
# the interface Corosync should bind to. In that case,
# configure the *host* address of the interface
# instead:
bindnetaddr: 192.168.1.0
# When selecting a multicast address, consider RFC
# 2365 (which, among other things, specifies that
# 239.255.x.x addresses are left to the discretion of
# the network administrator). Do not reuse multicast
# addresses across multiple Corosync clusters sharing
# the same network.
mcastaddr: 226.94.1.1
# Corosync uses the port you specify here for UDP
# messaging, and also the immediately preceding
# port. Thus if you set this to 5405, Corosync sends
# messages over UDP ports 5405 and 5404.
mcastport: 4000
# Time-to-live for cluster communication packets. The
# number of hops (routers) that this ring will allow
# itself to pass. Note that multicast routing must be
# specifically enabled on most network routers.
ttl: 1
}
}
logging {
# Log the source file and line where messages are being
# generated. When in doubt, leave off. Potentially useful for
# debugging.
fileline: off
# Log to standard error. When in doubt, set to no. Useful when
# running in the foreground (when invoking "corosync -f")
to_stderr: no
# Log to a log file. When set to "no", the "logfile" option
# must not be set.
to_logfile: yes
logfile: /var/log/cluster/corosync.log
# Log to the system log daemon. When in doubt, set to yes.
to_syslog: yes
# Log debug messages (very verbose). When in doubt, leave off.
debug: off
# Log messages with time stamps. When in doubt, set to on
# (unless you are only logging to syslog, where double
# timestamps can be annoying).
timestamp: on
logger_subsys {
subsys: QUORUM
debug: off
}
}
quorum {
# Enable and configure quorum subsystem (default: off)
# see also corosync.conf.5 and votequorum.5
#provider: corosync_votequorum
}
J'en suis a l'épape 3.2:
Le Tuto :
# crm_mon
============
Last updated: Thu Aug 27 16:54:55 2009Stack: openais
Current DC: pcmk-1 - partition with quorum
Version: 1.1.5-bdd89e69ba545404d02445be1f3d72e6a203ba2f
2 Nodes configured, 2 expected votes
0 Resources configured.
============
Online: [ pcmk-1 pcmk-2 ]
============
Last updated: Thu Aug 27 16:54:55 2009Stack: openais
Current DC: pcmk-1 - partition with quorum
Version: 1.1.5-bdd89e69ba545404d02445be1f3d72e6a203ba2f
2 Nodes configured, 2 expected votes
0 Resources configured.
============
Online: [ pcmk-1 pcmk-2 ]
Mais ...
Ma Mageia :
[root@info01 service.d]# crm_mon
============
Last updated: Wed Jul 4 23:05:56 2012
Last change:
Current DC: NONE
0 Nodes configured, unknown expected votes
0 Resources configured.
============
[root@info01 service.d]# crm_mon
============
Last updated: Wed Jul 4 23:05:56 2012
Last change:
Current DC: NONE
0 Nodes configured, unknown expected votes
0 Resources configured.
============
Pourtant, quand je lance pacemaker sur info01, le /var/log/messages de info02 dit:
Citation :
Jul 4 23:50:09 info02 rsyslogd-2177: imuxsock lost 120 messages from pid 2245 due to rate-limiting
Jul 4 23:50:09 info02 pacemakerd[2245]: notice: update_node_processes: 0x2441330 Node 3372329152 now known as info01, was:
Jul 4 23:50:09 info02 cib[2251]: info: crm_new_peer: Node info01 now has id: 3372329152
Jul 4 23:50:09 info02 cib[2251]: info: crm_new_peer: Node 3372329152 is now known as info01
Jul 4 23:50:09 info02 stonith-ng[2252]: info: crm_new_peer: Node info01 now has id: 3372329152
Jul 4 23:50:09 info02 stonith-ng[2252]: info: crm_new_peer: Node 3372329152 is now known as info01
Jul 4 23:50:09 info02 rsyslogd-2177: imuxsock lost 120 messages from pid 2245 due to rate-limiting
Jul 4 23:50:09 info02 pacemakerd[2245]: notice: update_node_processes: 0x2441330 Node 3372329152 now known as info01, was:
Jul 4 23:50:09 info02 cib[2251]: info: crm_new_peer: Node info01 now has id: 3372329152
Jul 4 23:50:09 info02 cib[2251]: info: crm_new_peer: Node 3372329152 is now known as info01
Jul 4 23:50:09 info02 stonith-ng[2252]: info: crm_new_peer: Node info01 now has id: 3372329152
Jul 4 23:50:09 info02 stonith-ng[2252]: info: crm_new_peer: Node 3372329152 is now known as info01
Mais si je lance les services sur info02, voici ce que dit le /var/log/messages:
http://pastebin.com/A54WNsUk
Ce qui m'énerve c'est que j'ai testé la même procédure sur une CentOS et ça marche, mais moi, je veux faire ça sur Mageia !
Édité par Adrien.D Le 05/07/2012 à 00h16
Config : PC Fixe : X470 GAMING PRO- AMD Ryzen 5 2600X - 16Go RAM - Radeon RX 560 (Pilote libre) - Gentoo Linux - GNOME Desktop - Kernel 5.10 LTS
Ancien Webmaster de MageiaLinuxOnline. Les remplaçants assurent !
Ancien Webmaster de MageiaLinuxOnline. Les remplaçants assurent !


Adrien.D Membre non connecté
-
- Voir le profil du membre Adrien.D
- Inscrit le : 30/05/2011
- Site internet
- Groupes :
J'ai tenté pas mal de trucs ces temps ci et j'ai trouvé un comportement bizzarre.
crm_mon me dit toujours que j'ai 0 nodes configurés.
Sur l'une et l'autre machine, les interfaces s'appellent eth0 et eth1 (c'est pas les mêmes noms c'est étrange, j'ai fait les mêmes manips.
J'ai sur les deux machines déclaré des sous-interfaces (ifconfig eth1:9 192.168.1.200 et ifconfig eth0:9 192.168.1.200 ) ce qui me donne:
Code TEXT :
[root@info01 adrien]# ifconfig eth0:9 192.168.1.200 [root@info01 adrien]# ifconfig eth0 Link encap:Ethernet HWaddr 08:00:27:0C:B2:B6 inet adr:192.168.1.201 Bcast:192.168.1.255 Masque:255.255.255.0 adr inet6: fe80::a00:27ff:fe0c:b2b6/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:40627 errors:0 dropped:0 overruns:0 frame:0 TX packets:43806 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 RX bytes:5643737 (5.3 MiB) TX bytes:5756987 (5.4 MiB) eth0:9 Link encap:Ethernet HWaddr 08:00:27:0C:B2:B6 inet adr:192.168.1.200 Bcast:192.168.1.255 Masque:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 lo Link encap:Boucle locale inet adr:127.0.0.1 Masque:255.0.0.0 adr inet6: ::1/128 Scope:Hôte UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:5682 errors:0 dropped:0 overruns:0 frame:0 TX packets:5682 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:0 RX bytes:705281 (688.7 KiB) TX bytes:705281 (688.7 KiB)
Code TEXT :
[root@info02 adrien]# ifconfig eth1:9 192.168.1.200 [root@info02 adrien]# ifconfig eth1 Link encap:Ethernet HWaddr 08:00:27:8E:82:55 inet adr:192.168.1.202 Bcast:192.168.1.255 Masque:255.255.255.0 adr inet6: fe80::a00:27ff:fe8e:8255/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:8566 errors:0 dropped:0 overruns:0 frame:0 TX packets:7536 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 RX bytes:1035298 (1011.0 KiB) TX bytes:1111208 (1.0 MiB) eth1:9 Link encap:Ethernet HWaddr 08:00:27:8E:82:55 inet adr:192.168.1.200 Bcast:192.168.1.255 Masque:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 lo Link encap:Boucle locale inet adr:127.0.0.1 Masque:255.0.0.0 adr inet6: ::1/128 Scope:Hôte UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:1291 errors:0 dropped:0 overruns:0 frame:0 TX packets:1291 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:0 RX bytes:222297 (217.0 KiB) TX bytes:222297 (217.0 KiB)
Et là, si je coupe une machine, l'autre prend le relais (testé avec un serveur web avec 2 index.php différents)
Citation :
Réponse de 192.168.1.200 : octets=32 temps<1ms TTL=64
Réponse de 192.168.1.200 : octets=32 temps<1ms TTL=64
Réponse de 192.168.1.200 : octets=32 temps<1ms TTL=64
Réponse de 192.168.1.200 : octets=32 temps<1ms TTL=64
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Réponse de 192.168.1.200 : octets=32 temps<1ms TTL=64
Réponse de 192.168.1.200 : octets=32 temps<1ms TTL=64
Réponse de 192.168.1.200 : octets=32 temps<1ms TTL=64
Réponse de 192.168.1.200 : octets=32 temps<1ms TTL=64
Réponse de 192.168.1.200 : octets=32 temps<1ms TTL=64
Réponse de 192.168.1.200 : octets=32 temps<1ms TTL=64
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Réponse de 192.168.1.200 : octets=32 temps<1ms TTL=64
Réponse de 192.168.1.200 : octets=32 temps<1ms TTL=64
Réponse de 192.168.1.200 : octets=32 temps<1ms TTL=64
Je pensais que j'avais fait n'importe quoi et j'ai tenté de désactiver corosync et pacemaker (arrêt des services) et le relai ne marche plus.
On dirait comme si c'était bien les services qui fonctionnaient ....
Une idée sur la gestion des sous interfaces dans Linux ?
Édité par Adrien.D Le 05/07/2012 à 19h06
Config : PC Fixe : X470 GAMING PRO- AMD Ryzen 5 2600X - 16Go RAM - Radeon RX 560 (Pilote libre) - Gentoo Linux - GNOME Desktop - Kernel 5.10 LTS
Ancien Webmaster de MageiaLinuxOnline. Les remplaçants assurent !
Ancien Webmaster de MageiaLinuxOnline. Les remplaçants assurent !


ennael Membre non connecté
-
- Voir le profil du membre ennael
- Inscrit le : 03/04/2011
- Groupes :
-
Équipe Mageia
quorum {
provider: corosync_votequorum
expected_votes: 2
}
dans /etc/corosync/corosync.conf
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie