search for: systutorials

Hi all, I love this project, Gluster and Ganesha are amazing. Thank you for this great work! The only thing that I miss is IPv6 support. I know that there are some challenges and that?s OK. For me it?s not important whether Gluster servers use IPv4 or IPv6 to speak each other and replicate data. The only thing that I?d like to have is a floating IPv6 for clients when I use Ganesha (just IPv6,

.../ Corosync and replace IPv4 by IPv6? > >> > > > > At-least from [1] looks like it is supported. Do you see any > > errors/warnings in the log files? (/var/log/messages, > > /var/log/pacemaker.log, /var/log/corosync.log) > > > > > > [1] https://www.systutorials.com/docs/linux/man/7-ocf_heartbeat_IPaddr2/ > > > > /usr/lib/ocf/resource.d/heartbeat/IPaddr2 does support IPv6: > > ... > <shortdesc lang="en">Manages virtual IPv4 and IPv6 addresses (Linux > specific version)</shortdesc> > > <parameters...

Hello dear tinc users, I've been looking for a while now for a solution in the mailing list and maybe I'm guiltily too lazy to learn all that there is to know about Linux routing and that's why I'm still stuck. To get right to it: I have 2 hosts connected with tinc - one of them is a VPS with a public address and static IP address and the other is my desktop machine, both run

...; (one per cluster) and still be operational. If you lose 2 nodes of a > four node cluster, you're offline. > > This is true with default configuration, but you can configure Auto Tie Breaker (ATB) as you can see with "man votequorum", or an example web page here: https://www.systutorials.com/docs/linux/man/5-votequorum/ I just tested and verified it on my virtual 4-nodes based on CentOS 7.4, where I have: - modified corosync.conf on all nodes - pcs cluster stop --all - pcs cluster start --all - wait a few minutes for resources to start - shutdown cl3 and cl4 and this is the situ...

Hello, I'm planning migration of current two clusters based on CentOS 6.x with Cman/Rgmanager going to CentOS 7.x and Corosync/Pacemaker. As the clusters and their services are on the same subnet, and there no particular security concerns differentiating them, I'm also evaluating the option to transform the two clusters into a unique 4-node one during the upgrade. Currently I'm