<div dir="auto">Can we just patch the OS_DEFAULTS in the configurator until an OS override can be added upstream?<div dir="auto"><br></div><div dir="auto">Jason</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Jan 18, 2018 3:40 PM, "Francois Gingras" <<a href="mailto:francois.gingras@gmail.com">francois.gingras@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 18, 2018 at 2:51 PM, Eric Pratt <span dir="ltr"><<a href="mailto:eric.b.pratt@gmail.com" target="_blank">eric.b.pratt@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class="m_5363540516576741966gmail-"><div style="font-family:tahoma,sans-serif"><span style="font-family:arial,sans-serif">On Thu, Jan 18, 2018 at 5:50 AM, Willy Sudiarto Raharjo </span><span dir="ltr" style="font-family:arial,sans-serif"><<a href="mailto:willysr@slackbuilds.org" target="_blank">willysr@slackbuilds.org</a>></span><span style="font-family:arial,sans-serif"> wrote:</span><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi<br>
<br>
If anyone wondered why there aren't any update to letsencrypt even<br>
though new version gets released already, the answer is because there<br>
has been a change upstream so it broke letsencrypt when deployed in<br>
Slackware since 0.20.0 (<a href="https://github.com/certbot/certbot/issues/5332" rel="noreferrer" target="_blank">https://github.com/certbot/ce<wbr>rtbot/issues/5332</a>).<br>
<br>
in short, they are checking for apache2ctl command instead of apachectl<br>
which is by default used in Slackware. While they provided override<br>
classes for other distributions, none for Slackware at this moment.<br>
<br>
there are some solutions:<br>
- ask for Patrick to add symlink in -stable (and -current)<br>
- wait for upstream to fix the issue<br>
- add the symlink manually<br>
- someone make override class for Slackware and send PR to upstream<br><br></blockquote></div><br></div></span><div class="gmail_extra"><div style="font-family:tahoma,sans-serif">I think the correct solution is for Patrick to add a symlink in the distro. Since apachectl is the default, I don't know why we would want that changed in slackware. Making apache2ctl a symlink to apachectl would seem to be the right solution. However, I don't really think it matters which one is the symlink.</div><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">I suspect it was called apache2ctl originally so you could have apache 1.x and 2.x installed side-by-side on the same box. The only real problem this would create would be a conflict if someone is actually still running apache 1.x on modern Slackware distros. I doubt that's the case, but it's not beyond the realm of possibility. In that case, I would rather see the apachectl for apache 1.x be renamed to apache1ctl or something like that than to see the one from apache 2.x renamed.</div><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">Although, I think the best solution would be a combination of 1 and 4. We should try to get the override class in place, but we should also try to stick with the apache default as much as possible even if letsencrypt weren't an issue here.</div><br></div></div>
<br>______________________________<wbr>_________________<br>
SlackBuilds-users mailing list<br>
<a href="mailto:SlackBuilds-users@slackbuilds.org" target="_blank">SlackBuilds-users@slackbuilds.<wbr>org</a><br>
<a href="https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" rel="noreferrer" target="_blank">https://lists.slackbuilds.org/<wbr>mailman/listinfo/slackbuilds-u<wbr>sers</a><br>
Archives - <a href="https://lists.slackbuilds.org/pipermail/slackbuilds-users/" rel="noreferrer" target="_blank">https://lists.slackbuilds.org/<wbr>pipermail/slackbuilds-users/</a><br>
FAQ - <a href="https://slackbuilds.org/faq/" rel="noreferrer" target="_blank">https://slackbuilds.org/faq/</a><br>
<br>
<br></blockquote></div><br></div><div class="gmail_extra">I'm -1 on renaming the apachectl script - the script is called as such upstream, and I can't see a single valid reason to rename it.<div><br></div><div>Just because other debian-based distros did that doesn't mean it's the sane approach.</div><div><br></div><div>Now, I do realize that we do have to "play ball" with other distro's quirks, unfortunately. As such, creating a symlink from apache2ctl -> apachectl is probably the least disruptive approach.</div></div></div>
<br>______________________________<wbr>_________________<br>
SlackBuilds-users mailing list<br>
<a href="mailto:SlackBuilds-users@slackbuilds.org">SlackBuilds-users@slackbuilds.<wbr>org</a><br>
<a href="https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" rel="noreferrer" target="_blank">https://lists.slackbuilds.org/<wbr>mailman/listinfo/slackbuilds-<wbr>users</a><br>
Archives - <a href="https://lists.slackbuilds.org/pipermail/slackbuilds-users/" rel="noreferrer" target="_blank">https://lists.slackbuilds.org/<wbr>pipermail/slackbuilds-users/</a><br>
FAQ - <a href="https://slackbuilds.org/faq/" rel="noreferrer" target="_blank">https://slackbuilds.org/faq/</a><br>
<br>
<br></blockquote></div></div>