Need help finding instructions that don't use SUDO

Thanks RichardP and cpu. You both answered while I was off writing my book on the entire process from beginning to end.
I thought that I had redone the command with --force, but maybe not. I’ll try again.

I’ll let you know if it works.
Thanks
CJ

It didn’t work. Here’s what I get:

  acme.sh --issue --webroot ~/public_html/web/pagodawriters -d pagodawriters.com -d www.pagodawriters.com --staging
    [Tue Jul 23 08:21:16 MST 2019] Using stage ACME_DIRECTORY: https://acme-staging-v02.api.letsencrypt.org/directory
    [Tue Jul 23 08:21:17 MST 2019] Domains not changed.
    [Tue Jul 23 08:21:17 MST 2019] Skip, Next renewal time is: Sat Sep 21 03:07:27 UTC 2019
    [Tue Jul 23 08:21:17 MST 2019] Add '--force' to force to renew.
    taiji2014@p3plcpnl0401 [~]$ acme.sh --issue --webroot /home/taiji2014/pubiic_html/web/pagodawriters -d pagodawriters.com -d www.pagodawriters.com --force
    [Tue Jul 23 08:21:31 MST 2019] Multi domain='DNS:pagodawriters.com,DNS:www.pagodawriters.com'
    [Tue Jul 23 08:21:31 MST 2019] Getting domain auth token for each domain
    [Tue Jul 23 08:21:32 MST 2019] Getting webroot for domain='pagodawriters.com'
    [Tue Jul 23 08:21:32 MST 2019] Getting webroot for domain='www.pagodawriters.com'
    [Tue Jul 23 08:21:32 MST 2019] Verifying: pagodawriters.com
    [Tue Jul 23 08:21:35 MST 2019] pagodawriters.com:Verify error:Invalid response from http://pagodawriters.com/.well-known/acme-challenge/zE8omyLOdAYQbGepBZOnGi6I-qhvw_jqWZd1Tk_BBPE [23.229.140.154]:
    [Tue Jul 23 08:21:35 MST 2019] Please add '--debug' or '--log' to check more details.
    [Tue Jul 23 08:21:35 MST 2019] See: https://github.com/Neilpang/acme.sh/wiki/How-to-debug-acme.sh

I tried it with debug, and then tried to deploy again, and this is what I got:

[2019-07-23 08:27:23 -0700] warn [uapi] Cpanel::Wrap::send_cpwrapd_request adminbin Cpanel/ssl/ADD: exit 5: namespace=[Cpanel] module=[ssl] function=[ADD]: raw_response=[{"statusmsg":"adminbin Cpanel/ssl/ADD: exit 5","error":1,"exit_code":1280,"mode":"full","status":1,"data":{"message":"Certificate verification failed! The system did not find the Certificate Authority Bundle that matches this certificate. Contact “Fake LE Intermediate X1” to obtain the Certificate Authority Bundle.","statusmsg":"Certificate verification failed! The system did not find the Certificate Authority Bundle that matches this certificate. Contact “Fake LE Intermediate X1” to obtain the Certificate Authority Bundle.","html":"Certificate verification failed! The system did not find the Certificate Authority Bundle that matches this certificate. Contact “Fake LE Intermediate X1” to obtain the Certificate Authority Bundle.","action":"install","status":0},"timeout":0,"action":"fetch","version":"2.4"}] at /usr/local/cpanel/Cpanel/Wrap.pm line 123, <$socket> line 1.
        Cpanel::Wrap::send_cpwrapd_request("action", "fetch", "env", HASH(0x2f13fe0), "namespace", "Cpanel", "module", "ssl", ...) called at /usr/local/cpanel/Cpanel/Wrap.pm line 64
        Cpanel::Wrap::send_cpwrapd_request_no_cperror("namespace", "Cpanel", "module", "ssl", "function", "ADD", "data", HASH(0x28a9f98), ...) called at /usr/local/cpanel/Cpanel/AdminBin.pm line 296
        Cpanel::AdminBin::_adminfetch("module", "ssl", "function", "ADD", "format", "storable", "cache_check_files", "", ...) called at /usr/local/cpanel/Cpanel/AdminBin.pm line 176
        Cpanel::AdminBin::fetch_adminbin_nocache_with_status("ssl", undef, "ADD", "storable", HASH(0x28a9f98)) called at /usr/local/cpanel/Cpanel/API/SSL.pm line 1946
        Cpanel::API::SSL::_install("pagodawriters.com", "pagodawriters_com_bf58d_d240d_1571623635_08e773b172db367c72de"..., "bf58d_d240d_1429758bfff7c15b5e935dbf3071b9c1", undef, Cpanel::Result=HASH(0x278c600)) called at /usr/local/cpanel/Cpanel/API/SSL.pm line 1318
        Cpanel::API::SSL::install_ssl(Cpanel::Args=HASH(0x278cee0), Cpanel::Result=HASH(0x278c600)) called at /usr/local/cpanel/Cpanel/API.pm line 302
        Cpanel::API::__ANON__() called at /usr/local/cpanel/Cpanel/API.pm line 373
        eval {...} called at /usr/local/cpanel/Cpanel/API.pm line 373
        Cpanel::API::_eval_guard(Cpanel::Result=HASH(0x278c600), CODE(0x28b9690)) called at /usr/local/cpanel/Cpanel/API.pm line 302
        Cpanel::API::_run_module_function(Cpanel::Args=HASH(0x278cee0), Cpanel::Result=HASH(0x278c600), "SSL", "install_ssl") called at /usr/local/cpanel/Cpanel/API.pm line 164
        Cpanel::API::execute("SSL", "install_ssl", HASH(0x278c618)) called at /usr/local/cpanel/Cpanel/API.pm line 584
        Cpanel::API::run_api_mode(HASH(0x278c618)) called at uapi.pl line 308
        main::script() called at uapi.pl line 139
[2019-07-23 08:27:23 -0700] warn [uapi] Cpanel::Wrap::send_cpwrapd_request error: namespace=[Cpanel] module=[ssl] function=[ADD]: statusmsg=[adminbin Cpanel/ssl/ADD: exit 5] at /usr/local/cpanel/Cpanel/Wrap.pm line 132, <$socket> line 1.
        Cpanel::Wrap::send_cpwrapd_request("action", "fetch", "env", HASH(0x2f13fe0), "namespace", "Cpanel", "module", "ssl", ...) called at /usr/local/cpanel/Cpanel/Wrap.pm line 64
        Cpanel::Wrap::send_cpwrapd_request_no_cperror("namespace", "Cpanel", "module", "ssl", "function", "ADD", "data", HASH(0x28a9f98), ...) called at /usr/local/cpanel/Cpanel/AdminBin.pm line 296
        Cpanel::AdminBin::_adminfetch("module", "ssl", "function", "ADD", "format", "storable", "cache_check_files", "", ...) called at /usr/local/cpanel/Cpanel/AdminBin.pm line 176
        Cpanel::AdminBin::fetch_adminbin_nocache_with_status("ssl", undef, "ADD", "storable", HASH(0x28a9f98)) called at /usr/local/cpanel/Cpanel/API/SSL.pm line 1946
        Cpanel::API::SSL::_install("pagodawriters.com", "pagodawriters_com_bf58d_d240d_1571623635_08e773b172db367c72de"..., "bf58d_d240d_1429758bfff7c15b5e935dbf3071b9c1", undef, Cpanel::Result=HASH(0x278c600)) called at /usr/local/cpanel/Cpanel/API/SSL.pm line 1318
        Cpanel::API::SSL::install_ssl(Cpanel::Args=HASH(0x278cee0), Cpanel::Result=HASH(0x278c600)) called at /usr/local/cpanel/Cpanel/API.pm line 302
        Cpanel::API::__ANON__() called at /usr/local/cpanel/Cpanel/API.pm line 373
        eval {...} called at /usr/local/cpanel/Cpanel/API.pm line 373
        Cpanel::API::_eval_guard(Cpanel::Result=HASH(0x278c600), CODE(0x28b9690)) called at /usr/local/cpanel/Cpanel/API.pm line 302
        Cpanel::API::_run_module_function(Cpanel::Args=HASH(0x278cee0), Cpanel::Result=HASH(0x278c600), "SSL", "install_ssl") called at /usr/local/cpanel/Cpanel/API.pm line 164
        Cpanel::API::execute("SSL", "install_ssl", HASH(0x278c618)) called at /usr/local/cpanel/Cpanel/API.pm line 584
        Cpanel::API::run_api_mode(HASH(0x278c618)) called at uapi.pl line 308
        main::script() called at uapi.pl line 139
[Tue Jul 23 08:27:23 MST 2019] Error in deploying certificate:
[Tue Jul 23 08:27:23 MST 2019] ---
apiversion: 3
func: install_ssl
module: SSL
result:
  data:
    cert_id: pagodawriters_com_bf58d_d240d_1571623635_08e773b172db367c72de04fa3ea399c9
    key_id: bf58d_d240d_1429758bfff7c15b5e935dbf3071b9c1
  errors:
    - The certificate could not be installed on the domain “pagodawriters.com”.
    - Certificate verification failed! The system did not find the Certificate Authority Bundle that matches this certificate. Contact “Fake LE Intermediate X1” to obtain the Certificate Authority Bundle.
  messages: ~
  metadata: {}

Here I think the problem is the typo "pubiic_html" for "public_html".

3 Likes

Here I think the problem is the typo “pubiic_html” for “public_html”.

Whoa - good catch! I'll fix and try it again.

1 Like

Whoo - hoo!!!

Success.

els and eyes are so difficult to tell apart in certain fonts - I never even saw that typo.

Thanks so much, Schoen.

2 Likes

A lot of people who spend a lot of time in the terminal favor fonts that deliberately emphasize the distinctions between liI1| and o0O. A few nice new fonts have been created lately specifically for terminal and code-editing work. If you’re going to do this work in the future, you might be able to set up your PuTTY to use a nice terminal font, and it may help to accentuate these differences.

2 Likes

Thanks! I’ll do that.
Peace
CJ

Excellent advice from Schoen. I’d go a stage further and make a more determined effort to get my hosting away from Godaddy.

Perhaps you could recruit a volunteer sympathetic with your objectives who is capable of selecting a hosting service and configuring a server from the initial installation of the operating system upwards?

That way you could dispense with Cpanel and all the other gizmos that allow hosts to “monetise” what ought to be free.

Note that the most common cPanel configuration today supports free certificates for all panel users. Hosting providers that offer cPanel but not free certificates are usually taking a deliberate action to disable this option for their customers.

1 Like

Okay, I can see that I will have to explain my decisioning. Technologist friends have been telling me for years to get away from GoDaddy. It is true that they try to monetize things that other hosters give away for free, and that their configurations are non-standard which drive techies and administrators crazy. I understand that.

When GoDaddy charged me over $800 for the SSL for my 14 domains I realized I couldn’t afford it and got a refund and decided to leave. I spent a good long time investigating other hosting services. I chose what was supposed to be one of the best, paid them a lot of money for five years of hosting (but I was getting the SSL for free, right?) and commenced to move my sites.

One problem is that I’ve been on Godaddy since 2003. More than 15 years. That’s a long time, and lot of configurations that were done for websites I wrote years and years ago. And none of it is simple because of Addon domains. Godaddy lets you buy ONE hosting service and put as many add-on domains as you like. (Other hosting services charge for each addon domain, or insist that you pay for hosting for each one). And though Godaddy configurations may be non-standard for other hosting sites, I know their configurations very well. I know just which menu to go to in order to accomplish what I need to do, and that includes a lot of stuff including PHP, mySQL, etc.

When I called this new hosting service to find out exactly what I had to do in order to replicate what I had on GoDaddy, they would not go over it with me. Instead they said they would do it for me - and promised that it would be a smooth transition. At first I thought it was heaven - getting someone else to do the several days worth of work to migrate. Until they (first) wouldn’t coordinate an exact time for me so that I could test the domains when I was free and then (second) when they did migrate it, they did not do it correctly. And then it turns out they needed me to go in and enter the new DNSs for all the domains anyway - something I thought they would do. They hadn’t paid attention to any of the notes I left for them, and instead just moved everything. But the new hoster wasn’t configured the same, and many things didn’t work. I called, and chatted, and called, and chatted - but I could never get an answer except they were working on it and would let me know. As we got closer and closer to the cutoff point (the point when my godaddy account would expire), I still didn’t have any working sites on their end. The DNS was not correctly set up, and they would not explain to me what I needed to do to fix it. They just kept telling me to trust them. With 24 hours before D-Day left, and my sites having been down for a full week without any real conversations with anyone who knew WTF was going on, I pulled the plug. Moved all my DNSs back to GoDaddy.

GoDaddy’s secret is that they answer the phone. Day or Night, they answer the phone. And though you often have to deal with people who don’t know what they are doing, eventually you get to talk to someone who knows the score. And most times, they are patient and kind and will walk me through everything myself so that I don’t have to call them on the same issue again. Even when they screw up my sites (which they HAVE done - like the day all my sites disappeared before my eyes because they had turned on some extra-heavy protection that judged every file on my site a security risk), they at least keep working the issue, with me on the phone, until it is resolved. None of this “we can’t let you talk to the technology people” crap.

And if you avoid all the extra services, GoDaddy is dirt cheap. No one provides all the services they provide cheaper. As a non-profit, I need cheap. Technology people think nothing of paying $50 a month for hosting services for a dedicated server. The last time I talked to a hoster and told them what I was paying for a year of hosting, for the space I get, the bandwidth, the databases, etc. - they admitted that they couldn’t get close to the price.

And remember, it was GoDaddy who told me it was possible to do this on my own. They just weren’t going to take me step by step through the lessons. But they were nice about it when I told them I was going to figure it out, and gave me what help they could. They were the ones who pointed me to the original youtube video that I used to set up the SSL three months ago.

So I may leave GoDaddy if I can find a hoster who answers the phone and lets me talk to the technology people 24 hours a day 7 days a week, doesn’t charge for services GoDaddy gives away for free, and doesn’t cost more than GoDaddy for hosting. But I haven’t found one yet.

So you may not understand, but for the moment I’m sticking with my decision.

Nonetheless, I greatly appreciate your thinking about me and giving me advise. I especially appreciate all the help I got from this community. It is much more active than many communities I try to get help from.

Peace
CJ Rhoads

Came back after a night of great sleep to find the problem wasn’t really a problem, just a typo. Congratualations - sounds like you have it nutted out.

The problem that schoen picked up on was something I would not have - I find myself glazing over when faced with a sea of text. I would have picked the problem, though - the difference with me is simply from experience (and you will get there as well, even if it doesn’t feel like it right now), I would have used the errors and warnings to figure out the problem. Play to your strengths.

The problem, really, is that humans don’t do that kind of work well, and one other thing that may help as you deploy to the rest of your sites is creating a few scripts. acme.sh is a script - and you can create ones yourself that take away the need to put in all the same commands for each of your sites.

I’m guessing that even as I type this, you’ve probably got all the other sites running, so I’m not really talking about this instance. What you will find, though, is that system admin is fairly repetitive, and scripts help with that.

I won’t bother telling you how to create them, as it’s more than a can be covered here, but given what you have successfully done and that you persevered, I’ve no doubt that you will manage this as well. Just a couple of words of warning that won’t be in the content that Google will lead you to:

1 - Scripts will save you time and ease your tasks, but take a lot of time and effort to create and set up. When you write a script, you are actually programming. Whether you write a script or not depends on how often you have to do something. With fourteen sites to manage, I think scripts will be a big part of your life.

2 - As with anything in life, what eases your life comes at a cost, and you need to be aware of those costs. The biggest problem with scripts is that they embed a lot of your knowledge in them. This makes them a huge security problem if you are careless. When you create a script, do it outside the public directories of the web servers. Ensure a script always acts on the web-server from outside, never from within. So you script may reference “public_html” as an example, but never be tempted to create a script within the public_html directory. Keep the scripts in your own home, with file permissions that allow only you see them and execute them.

3 A month after you’ve finished creating a script, you’ve forgotten the little things that were in the forefront of your mind while you were creating them. Document all your scripts in two ways: as comments within your scripts that explain what each section does and why it exists, and in a seperate file which documents what each script does, how each script interacts with the others, and how each script fits into your life as a sysadmin.

Finally, since cost and price are important to you, I’d suggest you repeat the exercise to move away from Godaddy. Godaddy is great: they fill a definite space, and to a point, they deliver what they promise. Support is great, but it does come at a price. What you experienced with the other crowd is typical - they cater for customers who are more technically knowledgeable. They will provide support when their hardware or software is the problem, but their capabilities stop there. The way you want to approach it is to register a new, dummy domain as a test site (or use a sub-domain as a test, such as https://test.syihtq.org/ - however, a mistake can affect your live site). What you do now is to get this site running on the new provider in several stages:

1 - Just get it running, creating and testing scripts at each stage. Keep the same directory structure as one of your live sites.

2 - Migrate the live site to the new test site. Just migrate the site, not the domain name. During this stage, you should be able to see identical copies of the live site, while the rest of the world will still be going to Godaddy. Evolve and test your scripts so that you can completely automate the migration of the site.

3 - Evolve your scripts so that you can automate the migration of all of your sites to the new hosting platform. As an intermediate step, also add functionality to the scripts so that at any time, the scripts can be used to migrate the content of your live site to your own machine. Why? Because it is SO much easier and more comfortable making changes to the content on your own machine that on a hosting platform.

4 - Once all the sites are migrated, use your own local “hosts” file so that you can switch between Godaddy and the new host. Test everything. Make sure the two hosts show exactly the same. There are free tools you can download to help with this. Remember, while you are doing all this, the world is still going to Godaddy, unaware that identical copies of the site exist elsewhere.

5 - When you are satisfied that your scripts produce identical copies of the Godaddy sites on the new host, you can then change your DNS entries. Always one at a time, waiting for the change to take effect before you do another. Keep the Godaddy host alive and paid for, for several months yet, until you are sure the new provider is reliable. During this phase, switching back to Godaddy is just a matter of changing your DNS.

6 - Once you are sure the new provider meets muster, you can cancel the Godaddy hosting. Again, only one at a time, to see if anything breaks because you’ve not taken something into account. After this stage, your scripts can be re-purposed to make up-to-date copies of the live sites locally, so that at any time you have current copies that can be migrated to a new host if something happens to your current one.

1 Like

Good advice, all. Thanks.

I do create scripts all the time - DOS batch files that run on my PC (yes, I’m that old) for repetitive stuff like backups and resetting my webdav and Windows menus (because something keeps wreaking havoc with them). I’m simply not a linux/systems admin guru (although I’m feeling more and more like one every time I tackle one of these projects!) (In 1987 I actually taught a class in Unix - but just the basics like ls and vi - the whole field has gone far beyond the basics).

In a way, however, I did use scripts to do the other sites - I used Notepad to copy the commands, adjusted them for each domain, and then pasted each one into Putty. It went very quickly once I got the hang of it and I did all the rest in less than an hour. While I’m sure there must be a way to run a script inside Putty, it probably wasn’t worth my time to do it. Especially since I had to see the results of each line before I went to the next line.

In any case, you’ve been terrific. Thanks.

Peace
CJ

1 Like

Take a look at the official GoDaddy instructions for LersEncrypt and Cpanel:
https://www.godaddy.com/help/install-a-lets-encrypt-certificate-on-your-cpanel-hosting-account-28023

Hi, Highermath.
Was there something specific about the link that you posted? I think it pretty much supports what I said. GoDaddy doesn’t prevent you from using free letsencript certificates, but you can’t use certbot, they don’t provide a cpanel autorenewal, you have to manually install each certificate (unless, of course, you go through all the trouble that I did to find out how to install and use acme.sh), and they won’t help you through it [much].
If I’m missing something, let me know.
Peace
CJ

1 Like

Hi @cjrhoads

Now that you have SSL installed on your websites - there seems to still be more work to be done. :frowning:

I viewed 3 of your sites and see that they are not auto redirecting to https. This is something that GoDaddy should be doing for you - actually cPanel. I cranked up cPanel and took a look at what needs to be done. I am looking at version 80 so it is a bit newer version than the one that GoDaddy supports, so things may be a slight bit different. In cPanel under the Domains section there is a Domains button, once there, you will find an option to “Force HTTPS Redirect On” at the top of the page. You will want to insure that this is enabled for all of your domains which have SSL enabled.

AS

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.