Re: [ClusterLabs] [Question] About log collection of crm_report.
Hi Ken,
Thank you for comment.
For example, our user does not use pacemaker.log and corosync.log.
Via a syslog, the user makes setting to output all log to /var/log/ha-log.
-
(/etc/corosycn/corosync.conf)
logging {
syslog_facility: local1
debug: off
}
(/etc/sysconfig/pacemaker)
PCMK_logfile=none
PCMK_logfacility=local1
PCMK_logpriority=info
PCMK_fail_fast=yes
(/etc/rsyslog.conf)
# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none;local1.none
/var/log/messages
(snip)
# Save boot messages also to boot.log
local7.* /var/log/boot.log
local1.info /var/log/ha-log
-
In present crm_report, in the case of the user who output log in a different
file, the log is not collected in sosreport.
Is this not a problem?
Possibly is all /var/log going to collect it in future in sosreport?
Of course I know that "/var/log/ha-log" is collected definitely when I carry
out crm_report alone.
I want to know why collection of log of this crm_report was stopped in
sosreport.
For REDHAT, will it be to be enough for collection of sosreport contents?
If it is such a thing, we can understand.
- And I test crm_report at the present, but seem to have some problems.
- I intend to report the problem by Bugzilla again.
Best Regards,
Hideo Yamauchi.
- Original Message -
> From: Ken Gaillot
> To: users@clusterlabs.org
> Cc:
> Date: 2017/1/24, Tue 08:15
> Subject: Re: [ClusterLabs] [Question] About log collection of crm_report.
>
> On 01/23/2017 04:17 PM, renayama19661...@ybb.ne.jp wrote:
>> Hi All,
>>
>> When I carry out Pacemaker1.1.15 and Pacemaker1.1.16 in RHEL7.3, log in
> conjunction with pacemaker is not collected in the file which I collected in
> sosreport.
>>
>>
>> This seems to be caused by the next correction and pacemaker.py script of
> RHEL7.3.
>>
>> -
> https://github.com/ClusterLabs/pacemaker/commit/1bcad6a1eced1a3b6c314b05ac1d353adda260f6
>> -
> https://github.com/ClusterLabs/pacemaker/commit/582e886dd8475f701746999c0093cd9735aca1ed#diff-284d516fab648676f5d93bc5ce8b0fbf
>>
>>
>> ---
>> (/usr/lib/python2.7/site-packages/sos/plugins/pacemaker.py)
>> (snip)
>> if not self.get_option("crm_scrub"):
>> crm_scrub = ""
>> self._log_warn("scrubbing of crm passwords has been
> disabled:")
>> self._log_warn("data collected by crm_report may
> contain"
>> " sensitive values.")
>> self.add_cmd_output('crm_report --sos-mode %s -S -d '
>> ' --dest %s --from "%s"' %
>> (crm_scrub, crm_dest, crm_from),
>> chroot=self.tmp_in_sysroot())
>> (snip)
>> ---
>>
>>
>> When a user carries out crm_report in sosreport, what is the reason that
> set search_logs to 0?
>>
>> We think that the one where search_logs works with 1 in sosreport is right.
>>
>>
>> Best Regards,
>> Hideo Yamauchi.
>
> Hi Hideo,
>
> The --sos-mode option is intended for RHEL integration, so it is only
> guaranteed to work with the combination of pacemaker and sosreport
> packages delivered with a particular version of RHEL (and its derivatives).
>
> That allows us to make assumptions about what sosreport features are
> available. It might be better to detect those features, but we haven't
> seen enough usage of sosreport + pacemaker outside RHEL to make that
> worth the effort.
>
> In this case, the version of sosreport that will be in RHEL 7.4 will
> collect pacemaker.log and corosync.log on its own, so the crm_report in
> pacemaker 1.1.16 doesn't need to collect the logs itself.
>
> It might work if you build the latest sosreport:
> https://github.com/sosreport/sos
>
> ___
> Users mailing list: Users@clusterlabs.org
> http://lists.clusterlabs.org/mailman/listinfo/users
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
>
___
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users
Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org
[ClusterLabs] How to Fence Virtualbox VM with Windows 10 as host.
This is my first attempt at clustering, just so you know the level required to convey ideas. I have Windows 10 running Virtualbox with 2 VMs running Fedora 25. I have followed 'Pacemaker 1.1 Clusters from Scratch' 9th edition up through chapter 7. It works. I am uncertain as how to fence the VMs with Windows 10 as host. The output from 'pcs stonith describe fence_vbox' is below. I have Cygwin installed with sshd configured and running. I can remotely ssh into the Windows 10 machine. I can add the keys from the machines into Windows authorized_keys so no user/password is required. I however do not know which of the options are *required*. Nor do I know what the options should be set to. Some of the options *are* obvious. If I use *only* required ones, ipaddr is obvious, login is obvious, but not sure what port is. Would it be the name of the VM as Virtualbox knows it? ipaddr (required): IP address or hostname of fencing device login (required): Login name port (required): Physical plug number on device, UUID or identification of machine Does the host require anything running on it to support the fence? Do I require any other options in addition to 'required'? How do I test it from a nodes commandline? Thank you, Durwin fc25> pcs stonith describe fence_vbox fence_vbox - Fence agent for VirtualBox fence_vbox is an I/O Fencing agent which can be used with the virtual machines managed by VirtualBox. It logs via ssh to a dom0 where it runs VBoxManage to do all of the work. .P By default, vbox needs to log in as a user that is a member of the vboxusers group. Also, you must allow ssh login in your sshd_config. Resource options: action: Fencing action WARNING: specifying 'action' is deprecated and not necessary with current Pacemaker versions cmd_prompt: Force Python regex for command prompt identity_file: Identity file (private key) for SSH inet4_only: Forces agent to use IPv4 addresses only inet6_only: Forces agent to use IPv6 addresses only ipaddr (required): IP address or hostname of fencing device ipport: TCP/UDP port to use for connection with device login (required): Login name passwd: Login password or passphrase passwd_script: Script to run to retrieve password port (required): Physical plug number on device, UUID or identification of machine secure: Use SSH connection ssh_options: SSH options to use separator: Separator for CSV created by 'list' operation delay: Wait X seconds before fencing is started login_timeout: Wait X seconds for cmd prompt after login missing_as_off: Missing port returns OFF instead of failure power_timeout: Test X seconds for status change after ON/OFF power_wait: Wait X seconds after issuing ON/OFF shell_timeout: Wait X seconds for cmd prompt after issuing command retry_on: Count of attempts to retry power on sudo: Use sudo (without password) when calling 3rd party software ssh_path: Path to ssh binary sudo_path: Path to sudo binary priority: The priority of the stonith resource. Devices are tried in order of highest priority to lowest. pcmk_host_map: A mapping of host names to ports numbers for devices that do not support host names. Eg. node1:1;node2:2,3 would tell the cluster to use port 1 for node1 and ports 2 and 3 for node2 pcmk_host_list: A list of machines controlled by this device (Optional unless pcmk_host_check=static-list). pcmk_host_check: How to determine which machines are controlled by the device. Allowed values: dynamic-list (query the device), static-list (check the pcmk_host_list attribute), none (assume every device can fence every machine) pcmk_delay_max: Enable random delay for stonith actions and specify the maximum of random delay This prevents double fencing when using slow devices such as sbd. Use this to enable random delay for stonith actions and specify the maximum of random delay. pcmk_action_limit: The maximum number of actions can be performed in parallel on this device Pengine property concurrent-fencing=true needs to be configured first. Then use this to specify the maximum number of actions can be performed in parallel on this device. -1 is unlimited. Durwin F. De La Rue Management Sciences, Inc. 6022 Constitution Ave. NE Albuquerque, NM 87110 Phone (505) 255-8611 This email message and any attachments are for the sole use of the intended recipient(s) and may contain proprietary and/or confidential information which may be privileged or otherwise protected from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient(s), please contact the sender by reply email and destroy the original message and any copies of the message as well as any attachments to the original message.___ Users mailing list: Users@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/users Project Home:
