Re: [ClusterLabs] Apache doesn't start under corosync with systemd
With respect, I've given up on the ocf:heartbeat:apache module. I've set up my Apache resource with: # systemctl disable apache2 # crm configure primitive ncoa_apache systemd:apache2 # crm configure modgroup grp_ncoa add ncoa_apache # crm configure show ncoa_apache primitive ncoa_apache systemd:apache2 # Apache doesn't start until the cluster is up.When the cluster starts, Apache starts up on the active node. The webserver migrates with the cluster when I move it from one node to another. That's really all I want. Tell me why this is a bad idea. What options or other configurations should I add to the primitive? Please give the command syntax. John Reynolds ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] Apache doesn't start under corosync with systemd
On Wed, 2019-10-16 at 13:33 +, Reynolds, John F - San Mateo, CA - Contractor wrote: > > mailto:kgail...@redhat.com] > > Sent: Monday, October 14, 2019 12:02 PM > > > > If you have SELinux enabled, check for denials. The cluster > > processes have a different SELinux context than systemd, so > > policies might not be set up correctly. > > -- > > Ken Gaillot > > Alas, SELinux is not in use. > > > I am thinking that the apache OCF module is not starting up apache > with the modules that it needs. > > Again, startup with 'systemctl start apache' brings up the http > daemons, so we know that the Apache configuration is clean. > > But if I enable trace and run the ocf script by hand: > > export OCF_TRACE_RA=1 > /usr/lib/ocf/resource.d/heartbeat/apache start ; echo $? > > Part of the output is Apache syntax errors that aren't flagged in the > regular startup: > > + 14:57:10: ocf_run:443: ocf_log err 'AH00526: Syntax error on line > 22 of /etc/apache2/vhosts.d/aqvslookup.conf: Invalid command > '\''Order'\'', perhaps misspelled or defined by a module not included > in the server configuration ' > > The 'Allow' and ' AuthLDAPURL' commands are also flagged as invalid. > > The /etc/sysconfig/apache2 module parameter includes the relevant > modules: > > APACHE_MODULES="actions alias auth_basic authn_file authz_host > authz_groupfile authz_core authz_user autoindex cgi dir env expires > include log_config mime negotiation setenvif ssl socache_shmcb > userdir reqtimeout authn_core php5 rewrite ldap authnz_ldap status > access_compat" > > > Why are they invoked properly from systemctl but not from ocf? > > John Reynolds OCF doesn't know anything about /etc/sysconfig; anything there will have to specified in the actual apache configuration. Alternatively, pacemaker can manage apache via systemd (using "systemd:httpd" as the agent instead of "ocf:heartbeat:apache"). But in that case the monitor will just check whether the process is running rather than check the status URL. -- Ken Gaillot ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] Apache doesn't start under corosync with systemd
>mailto:kgail...@redhat.com] >Sent: Monday, October 14, 2019 12:02 PM > >If you have SELinux enabled, check for denials. The cluster processes have a >different SELinux context than systemd, so policies might not be set up >correctly. >-- >Ken Gaillot Alas, SELinux is not in use. I am thinking that the apache OCF module is not starting up apache with the modules that it needs. Again, startup with 'systemctl start apache' brings up the http daemons, so we know that the Apache configuration is clean. But if I enable trace and run the ocf script by hand: export OCF_TRACE_RA=1 /usr/lib/ocf/resource.d/heartbeat/apache start ; echo $? Part of the output is Apache syntax errors that aren't flagged in the regular startup: + 14:57:10: ocf_run:443: ocf_log err 'AH00526: Syntax error on line 22 of /etc/apache2/vhosts.d/aqvslookup.conf: Invalid command '\''Order'\'', perhaps misspelled or defined by a module not included in the server configuration ' The 'Allow' and ' AuthLDAPURL' commands are also flagged as invalid. The /etc/sysconfig/apache2 module parameter includes the relevant modules: APACHE_MODULES="actions alias auth_basic authn_file authz_host authz_groupfile authz_core authz_user autoindex cgi dir env expires include log_config mime negotiation setenvif ssl socache_shmcb userdir reqtimeout authn_core php5 rewrite ldap authnz_ldap status access_compat" Why are they invoked properly from systemctl but not from ocf? John Reynolds ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] Apache doesn't start under corosync with systemd
On Fri, 2019-10-11 at 17:15 +, Reynolds, John F - San Mateo, CA - Contractor wrote: > > If pacemaker is managing a resource, the service should not be > > enabled to start on boot (regardless of init or systemd). Pacemaker > > will start and stop the service as needed according to the cluster > > configuration. > > Apache startup is disabled in systemctl, and there is no apache > script in /etc/init.d > > > Additionally, your pacemaker configuration is using the apache OCF > > script, so the cluster won't use /etc/init.d/apache2 at all (it > > invokes the httpd binary directly). > > > > Keep in mind that the httpd monitor action requires the status > > module to be enabled -- I assume that's already in place. > > Yes, that is enabled, according to apache2ctl -M. > > > The resource configuration is > > Primitive ncoa_apache apache \ > Params configfile="/etc/apache2/httpd.conf"\ > Op monitor internval=40s timeout=60s\ > Meta target-role=Started > > When I start the resource, crm status shows it in 'starting' mode, > but never gets to 'Started'. > > There is one process running "/bin/sh > /usr/lib/ocf/resources.d/heartbeat/apache start" but the httpd > processes never come up. What's worse, with that process running, > the cluster resource can't migrate; I have to kill it before the > cluster will finish cleanup and start on the new node. 'crm > resource cleanup ncoa_apache' hangs, as well. > > Apache starts up just fine from the systemctl command, so it's not > the Apache config that's broken. > > Suggestions? > > John Reynolds SMUnix If you have SELinux enabled, check for denials. The cluster processes have a different SELinux context than systemd, so policies might not be set up correctly. -- Ken Gaillot ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] Apache doesn't start under corosync with systemd
> If pacemaker is managing a resource, the service should not be enabled to > start on boot (regardless of init or systemd). Pacemaker will start and stop > the service as needed according to the cluster configuration. Apache startup is disabled in systemctl, and there is no apache script in /etc/init.d >Additionally, your pacemaker configuration is using the apache OCF script, so >the cluster won't use /etc/init.d/apache2 at all (it invokes the httpd binary >directly). > >Keep in mind that the httpd monitor action requires the status module to be >enabled -- I assume that's already in place. Yes, that is enabled, according to apache2ctl -M. The resource configuration is Primitive ncoa_apache apache \ Params configfile="/etc/apache2/httpd.conf"\ Op monitor internval=40s timeout=60s\ Meta target-role=Started When I start the resource, crm status shows it in 'starting' mode, but never gets to 'Started'. There is one process running "/bin/sh /usr/lib/ocf/resources.d/heartbeat/apache start" but the httpd processes never come up. What's worse, with that process running, the cluster resource can't migrate; I have to kill it before the cluster will finish cleanup and start on the new node. 'crm resource cleanup ncoa_apache' hangs, as well. Apache starts up just fine from the systemctl command, so it's not the Apache config that's broken. Suggestions? John Reynolds SMUnix ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] Apache doesn't start under corosync with systemd
On 07/10/19 10:27 -0500, Ken Gaillot wrote: > Additionally, your pacemaker configuration is using the apache OCF > script, so the cluster won't use /etc/init.d/apache2 at all (it invokes > the httpd binary directly). See my parallel response. > Keep in mind that the httpd monitor action requires the status > module to be enabled -- I assume that's already in place. (For SUSE, it looks like it used to be injected.) On-topic, spotted a small discrepancy around that part: https://github.com/ClusterLabs/resource-agents/pull/1414 -- Poki pgpiMoju8oq6D.pgp Description: PGP signature ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] Apache doesn't start under corosync with systemd
On Fri, 2019-10-04 at 14:10 +, Reynolds, John F - San Mateo, CA - Contractor wrote: > Good morning. > > I’ve just upgraded a two-node active-passive cluster from SLES11 to > SLES12. This means that I’ve gone from /etc/init.d scripts to > systemd services. > > On the SLES11 server, this worked: > > type="apache"> > > id="ncoa_apache-instance_attributes-configfile"/> > > > id="ncoa_apache-monitor-40s"/> > > > > I had to tweak /etc/init.d/apache2 to make sure it only started on > the active node, but that’s OK. If pacemaker is managing a resource, the service should not be enabled to start on boot (regardless of init or systemd). Pacemaker will start and stop the service as needed according to the cluster configuration. Additionally, your pacemaker configuration is using the apache OCF script, so the cluster won't use /etc/init.d/apache2 at all (it invokes the httpd binary directly). Keep in mind that the httpd monitor action requires the status module to be enabled -- I assume that's already in place. > > On the SLES12 server, the resource is the same: > > type="apache"> > > id="ncoa_apache-instance_attributes-configfile"/> > > > id="ncoa_apache-monitor-40s"/> > > > > and the cluster believes the resource is started: > > > eagnmnmep19c1:/var/lib/pacemaker/cib # crm status > Stack: corosync > Current DC: eagnmnmep19c0 (version 1.1.16-4.8-77ea74d) - partition > with quorum > Last updated: Fri Oct 4 09:02:52 2019 > Last change: Thu Oct 3 10:55:03 2019 by root via crm_resource on > eagnmnmep19c0 > > 2 nodes configured > 16 resources configured > > Online: [ eagnmnmep19c0 eagnmnmep19c1 ] > > Full list of resources: > > Resource Group: grp_ncoa > (edited out for brevity) > ncoa_a05shared (ocf::heartbeat:Filesystem):Started > eagnmnmep19c1 > IP_56.201.217.146 (ocf::heartbeat:IPaddr2): Started > eagnmnmep19c1 > ncoa_apache(ocf::heartbeat:apache):Started > eagnmnmep19c1 > > eagnmnmep19c1:/var/lib/pacemaker/cib # > > > But the httpd daemons aren’t started. I can start them by hand, but > that’s not what I need. > > I have gone through the ClusterLabs and SLES docs for setting up > apache resources, and through this list’s archive; haven’t found my > answer. I’m missing something in corosync, apache, or systemd. > Please advise. > > > John Reynolds, Contractor > San Mateo Unix > > ___ > Manage your subscription: > https://lists.clusterlabs.org/mailman/listinfo/users > > ClusterLabs home: https://www.clusterlabs.org/ -- Ken Gaillot ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] Apache doesn't start under corosync with systemd
On 04/10/19 14:10 +, Reynolds, John F - San Mateo, CA - Contractor wrote: > I've just upgraded a two-node active-passive cluster from SLES11 to > SLES12. This means that I've gone from /etc/init.d scripts to > systemd services. > > On the SLES11 server, this worked: > > type="apache"> > > id="ncoa_apache-instance_attributes-configfile"/> > > > id="ncoa_apache-monitor-40s"/> > > > > I had to tweak /etc/init.d/apache2 to make sure it only started on the active > node, but that's OK. > > On the SLES12 server, the resource is the same: > > type="apache"> > > id="ncoa_apache-instance_attributes-configfile"/> > > > id="ncoa_apache-monitor-40s"/> > > > > and the cluster believes the resource is started: > > > eagnmnmep19c1:/var/lib/pacemaker/cib # crm status > Stack: corosync > Current DC: eagnmnmep19c0 (version 1.1.16-4.8-77ea74d) - partition with quorum > Last updated: Fri Oct 4 09:02:52 2019 > Last change: Thu Oct 3 10:55:03 2019 by root via crm_resource on > eagnmnmep19c0 > > 2 nodes configured > 16 resources configured > > Online: [ eagnmnmep19c0 eagnmnmep19c1 ] > > Full list of resources: > > Resource Group: grp_ncoa > (edited out for brevity) > ncoa_a05shared (ocf::heartbeat:Filesystem):Started eagnmnmep19c1 > IP_56.201.217.146 (ocf::heartbeat:IPaddr2): Started eagnmnmep19c1 > ncoa_apache(ocf::heartbeat:apache):Started eagnmnmep19c1 > > eagnmnmep19c1:/var/lib/pacemaker/cib # > > > But the httpd daemons aren't started. I can start them by hand, but > that's not what I need. > > I have gone through the ClusterLabs and SLES docs for setting up > apache resources, and through this list's archive; haven't found my > answer. I'm missing something in corosync, apache, or systemd. > Please advise. I think you've accidentally arranged a trap for yourself to fall in. What makes be believe so is that you've explicitly mentioned you've modified /etc/init.d/apache2 explicitly. In RPM driven ecosystem (incl. SUSE), it means that on removal/upgrade of the respective package, that file won't get removed. This is what likely happened on your major system upgrade. Then, you can follow the logic in the agent itself, see in particular: https://github.com/ClusterLabs/resource-agents/blob/v4.3.0/heartbeat/apache#L187-L188 It makes the agent assume it is not in systemd realms and switches to use that provided initscript instead. Apparently, that is _not_ supposed to necessarily work, since at that point, you have the differing versions of httpd executables vs. the initscript (the former is presumably newer than the latter), so any evolutionary differences are not accounted for in the initscript itself (it's stale at that point). To resolve this, try simply renaming /etc/init.d/apache2 to something else (or moving it somewhere else, simply to retain a backup of your modifications), unmanage and manage the resource again, hopefully systemd route to get httpd running will turn out well then. -- Poki pgpYg3yvHJaBE.pgp Description: PGP signature ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
[ClusterLabs] Apache doesn't start under corosync with systemd
Good morning. I've just upgraded a two-node active-passive cluster from SLES11 to SLES12. This means that I've gone from /etc/init.d scripts to systemd services. On the SLES11 server, this worked: I had to tweak /etc/init.d/apache2 to make sure it only started on the active node, but that's OK. On the SLES12 server, the resource is the same: and the cluster believes the resource is started: eagnmnmep19c1:/var/lib/pacemaker/cib # crm status Stack: corosync Current DC: eagnmnmep19c0 (version 1.1.16-4.8-77ea74d) - partition with quorum Last updated: Fri Oct 4 09:02:52 2019 Last change: Thu Oct 3 10:55:03 2019 by root via crm_resource on eagnmnmep19c0 2 nodes configured 16 resources configured Online: [ eagnmnmep19c0 eagnmnmep19c1 ] Full list of resources: Resource Group: grp_ncoa (edited out for brevity) ncoa_a05shared (ocf::heartbeat:Filesystem):Started eagnmnmep19c1 IP_56.201.217.146 (ocf::heartbeat:IPaddr2): Started eagnmnmep19c1 ncoa_apache(ocf::heartbeat:apache):Started eagnmnmep19c1 eagnmnmep19c1:/var/lib/pacemaker/cib # But the httpd daemons aren't started. I can start them by hand, but that's not what I need. I have gone through the ClusterLabs and SLES docs for setting up apache resources, and through this list's archive; haven't found my answer. I'm missing something in corosync, apache, or systemd. Please advise. John Reynolds, Contractor San Mateo Unix ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
