All BASIC

Message Boards => Open Forum => Topic started by: John on November 05, 2018, 04:13:59 PM

Title: All BASIC Sandbox
Post by: John on November 05, 2018, 04:13:59 PM
I have the All BASIC GitLab CE Sandbox (https://sandbox.allbasic.info) available for establish members. If you're a contributor on the forum, this feature is for you. Public and private repositories. PM me for more details or an account for the sandbox.

GitLab Features  (All BASIC Sandbox)

Quote
If you only want to download open source software Community Edition is the best choice. This distribution does not contain proprietary code. Functionally it will behave the same as Enterprise Edition without a license.

(https://allbasic.info/picture_library/gitlab_features.png)

Title: All BASIC Sandbox - Script BASIC Development
Post by: John on November 08, 2018, 03:20:28 PM
The Script BASIC Development (https://sandbox.allbasic.info/scriptbasic/development) repository is now active in the All BASIC Sandbox. This repository was initially created by AIR cleaning up the distribution and adding WEEKNUM to the FORMATDATE core SB interpreter. I plan to add the extension modules I have built over the years to be improved on as well.

All BASIC Public Sandbox Repositories (https://sandbox.allbasic.info/explore/projects)


Title: Re: All BASIC Sandbox
Post by: John on November 13, 2018, 12:21:48 AM
I ran into a project that sounds interesting called Gitbase (https://opensource.com/article/18/11/gitbase). Do you view this tool as beneficial?
Title: Re: All BASIC Sandbox
Post by: John on November 14, 2018, 07:42:20 PM
The GitLab Web IDE is a great editor that integrates with your project repository seamlessly.

Intro Video (https://youtu.be/Y2SsnCHJd2w)
Title: Re: All BASIC Sandbox
Post by: John on November 16, 2018, 04:09:05 PM
AIR,

Could you post a dependency list and the links to the libraries for download for the SB iOS build? I'm currently doing the same for the Linux version.

Thanks!
Title: Re: All BASIC Sandbox
Post by: John on November 18, 2018, 11:07:00 AM
Git Extensions (https://sourceforge.net/projects/gitextensions/)

A toolkit to make working with Git more intuitive.
Title: Re: All BASIC Sandbox - Git Kracken
Post by: John on November 25, 2018, 06:42:53 PM
Git Kracken (https://www.gitkraken.com/)

Quote
Easily initialize a brand new project and use the built-in code editor to start working on that project. Add new files and folders, and edit them directly in GitKraken. Save your files, stage and commit your changes. No more context switching!
Title: Re: All BASIC Sandbox
Post by: John on December 05, 2018, 05:09:20 PM
There seems to be a problem with the Let's Encryp SSL certificate preventing the sandbox from access. I have escalated the issue with Plesk.
Title: Re: All BASIC Sandbox
Post by: John on December 06, 2018, 09:15:45 PM
I have a temporary workaround that only seems to work with Chrome. Firefox will not allow to ignore the invalid certificate problem. You have to proceed ignoring the security warning.

https://sandbox.allbasic.info:8181

Unfortunately until this is resolvesd, command line git fails to connect due to the security issue. Web browser access to the sandbox is it at the moment.

The problem is GitLab creates it's own Let's Encrypt certs and there is a flaw in the renewal process which exceeds the max count on the Let's Encrypt site.
Title: Re: All BASIC Sandbox
Post by: AIR on December 06, 2018, 10:09:02 PM
Couldn't you simply disable the Let's Encrypt integration in GitLab and add the sandbox to the allbasic.info site ssl certificate, since it's also using Let's Encrypt?
Title: Re: All BASIC Sandbox
Post by: John on December 06, 2018, 11:20:24 PM
GitLab creates and renews its certs and it's not a function of the Plesk Let's Encrypt extension. The faulty renewal is using up the 5o certs in a week limit trying to renew itself.  Plesk put a couple hours into trying to resolve it before giving up and saying it's a GitLab issue that needs to be resolved. Normally GitLab CE is run in a container which is what Plesk recommends.

I will look into your idea if it's possible to use the Plesk generated Let's Encrypt extension.

https://docs.gitlab.com/omnibus/settings/ssl.html

https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3252

https://www.digitalocean.com/community/tutorials/how-to-secure-gitlab-with-let-s-encrypt-on-ubuntu-16-04

https://stackoverflow.com/questions/34189199/how-do-i-use-let-s-encrypt-with-gitlab


Title: Re: All BASIC Sandbox
Post by: John on December 07, 2018, 11:07:23 AM
This looks interesting.

https://www.jonasjuffinger.com/2017/03/26/gitlab-with-plesk-and-lets-encrypt
Title: Re: All BASIC Sandbox
Post by: AIR on December 07, 2018, 12:55:31 PM
It's always better to learn how to do it manually before relying on front ends like Plesk.

Before you made the changes, when the problem first began, the sandbox was trying to use the cert for the main allbasic.info domain (I checked the cert).  That's why I suggested adding the sandbox subdomain to the primary cert.
Title: Re: All BASIC Sandbox
Post by: John on December 07, 2018, 01:39:22 PM
I'm working in that direction based on your advice. Plesk is unable to help.
Title: Re: All BASIC Sandbox
Post by: John on December 07, 2018, 07:49:15 PM
I seem to have made some progress following your path AIR. I disabled Let's Encrypt in GitLab and the green HTPPS lock reappeared. The sub-domain seems to using the main domain allbasic.info certificate.

If you use the :8181 option and accept the security warning in chrome look at the certificate. If I could replace the expire one on Nov. 5th, with a the valid allbasic.info certificate, it may work. I still can't generate any certificates due to over limit.

Title: Re: All BASIC Sandbox
Post by: AIR on December 07, 2018, 10:19:03 PM
That certificate looks like it is still self-signed and expired.

sandbox.allbasic.info:8181 uses an invalid security certificate. The certificate is not trusted because it is self-signed. The certificate expired on December 5, 2018, 6:07:17 PM GMT-5. The current time is December 8, 2018, 1:16 AM.

Title: Re: All BASIC Sandbox
Post by: John on December 07, 2018, 10:42:18 PM
The solution may be to reference the Plesk generated certs that don't have a problem renewing. Maybe a symbolic link to where Gitlab is looking for its certificate to where Plesk is storing its allbasic.info cert would solve the handshake issue?
Title: Re: All BASIC Sandbox
Post by: John on December 07, 2018, 10:56:21 PM
I think the root of the problem was Let's Encrypt was unable to validate through the proxy and kept on trying until it exhausted cert limits.
Title: Re: All BASIC Sandbox
Post by: AIR on December 07, 2018, 11:00:52 PM
The solution may be to reference the Plesk generated certs that don't have a problem renewing. Maybe a symbolic link to where Gitlab is looking for its certificate to where Plesk is storing its allbasic.info cert would solve the handshake issue?

No, that wouldn't work because the cert would have no info about the sandbox.

What you need to do is add the sandbox.allbasic.info subdomain to the cert.  https://www.plesk.com/blog/product-technology/lets-encrypt-plesk/
Title: Re: All BASIC Sandbox
Post by: AIR on December 07, 2018, 11:04:37 PM
I think the root of the problem was Let's Encrypt was unable to validate through the proxy and kept on trying until it exhausted cert limits.

Then you might want to look at your proxy setup, because I have an NGINX proxy for my GOGS (git) host on my VPS and have never had issues.

Are you using a subdomain for the sandbox, or an alias?  If the latter, I'm not sure if LE will work with that.
Title: Re: All BASIC Sandbox
Post by: John on December 07, 2018, 11:10:31 PM
Now that GitLab isn't flooding Let's Encrypt for certs, I will be able again to use Plesk to create a cert for sandbox.allbasic.info. I might just have to wait it out.

The sandbox is a true sub-domain.

I'm doing a proxy with Apache settings not nginx.

The reverse proxy settings have one function. To eliminate having to use :8181 in the url.

Quote
A reverse proxy server is a type of proxy server that typically sits behind the firewall in a private network and directs client requests to the appropriate backend server. A reverse proxy provides an additional level of abstraction and control to ensure the smooth flow of network traffic between clients and servers.

I also wonder why GitLab is still looking at its expired cert if Let's Encrypt is disabled? What if I rename the cert?

Only allbasic.info am I not able to create Let's Encrypt certificates for.

Title: Re: All BASIC Sandbox
Post by: John on December 08, 2018, 11:58:01 AM
The solution may be to focus on getting GitLab's Let's Encrypt to validate through the proxy. HTTPS dosn't like talking on :8181 to validate its certs.
Title: Re: All BASIC Sandbox
Post by: AIR on December 08, 2018, 12:49:06 PM

I also wonder why GitLab is still looking at its expired cert if Let's Encrypt is disabled? What if I rename the cert?

Only allbasic.info am I not able to create Let's Encrypt certificates for.

I've attached httpd.conf, nginx.conf and gitlab.rb files for sandbox.allbasic.info.

Your httpd.conf has this for the sandbox vhost:
      SSLEngine on
      SSLVerifyClient none
      SSLCertificateFile /usr/local/psa/var/certificates/cert09PuPLH


AIR.
Title: Re: All BASIC Sandbox
Post by: AIR on December 08, 2018, 12:51:22 PM
What does the LE log show?
Title: Re: All BASIC Sandbox
Post by: John on December 08, 2018, 12:55:48 PM
Should those entries be delete now there is no Plesk generated LE  cert for sandbox.allbasic.info only allbasic.info?

Where do I find the LE log?
Title: Re: All BASIC Sandbox
Post by: AIR on December 08, 2018, 05:05:23 PM
Quote
/var/www/vhosts/default/htdocs/.well-known/acme-challenge/

Does that path exist?
Title: Re: All BASIC Sandbox
Post by: John on December 08, 2018, 06:15:27 PM
The question I have is if GitLab was able to validate its initial cert, what did the Plesk interface do to break GitLab from renewing the cert?
Title: Re: All BASIC Sandbox
Post by: AIR on December 08, 2018, 07:04:43 PM
The question I have is if GitLab was able to validate its initial cert, what did the Plesk interface do to break GitLab from renewing the cert?

Is it possible that it altered the .htaccess file?  The only time I've had an issue with LE is when I configured a restriction on a folder (was testing video conferencing) to require direct authentication.  The LE service couldn't access the .well-known folder structure because public access to the parent folder was blocked.
Title: Re: All BASIC Sandbox
Post by: John on December 08, 2018, 07:12:27 PM
The only thing added to this was the proxy reverse to eliminate :8181 from the URL. It worked fine before and after this httpd.conf addition.

Maybe if I disable the proxy reverse and enable LE in GitLab, maybe it will renew when the limit expires?
 
Title: Re: All BASIC Sandbox
Post by: AIR on December 08, 2018, 07:44:48 PM
The only thing added to this was the proxy reverse to eliminate :8181 from the URL. It worked fine before and after this httpd.conf addition.

Maybe if I disable the proxy reverse and enable LE in GitLab, maybe it will renew when the limit expires?

Maybe, but might be best to renew manually to avoid any issues with flooding the LE system and locking yourself out indefinitely...if you use certbot and the renew option, it will only request a renewal if it is needed, otherwise it will inform you that it isn't needed and won't submit an actual request.

On my server, I did it like that the first few times, and then put the command in a script and created a cron job for it.

The script is simple:

Code: Bash
  1. #!/bin/bash
  2.  
  3. sudo certbot renew
  4.  

And the crontab file for ROOT contains:

Code: Text
  1. @monthly /home/riveraa/bin/renew
  2.  

Which as you can guess, runs the "renew" script once a month.

AIR.
Title: Re: All BASIC Sandbox
Post by: John on December 08, 2018, 07:54:06 PM
[centos@ip-172-30-0-53 ~]$ sudo certbot renew
sudo: certbot: command not found
[centos@ip-172-30-0-53 ~]$

This was suppose to renew the cert.

sudo gitlab-ctl hup nginx

as well as this.

[centos@ip-172-30-0-53 ~]$ sudo gitlab-ctl renew-le-certs
Starting Chef Client, version 13.6.4
resolving cookbooks for run list: ["gitlab::letsencrypt_renew"]
Synchronizing Cookbooks:
  - gitlab (0.0.1)
  - package (0.1.0)
  - postgresql (0.1.0)
  - redis (0.1.0)
  - registry (0.1.0)
  - mattermost (0.1.0)
  - consul (0.0.0)
  - gitaly (0.1.0)
  - letsencrypt (0.1.0)
  - nginx (0.1.0)
  - runit (0.14.2)
  - acme (3.1.0)
  - crond (0.1.0)
  - compat_resource (12.19.0)
Installing Cookbook Gems:
Compiling Cookbooks...
Converging 0 resources

Running handlers:
Running handlers complete
Chef Client finished, 0/0 resources updated in 06 seconds
[centos@ip-172-30-0-53 ~]$

Update

I sent the GilLab configuration infor to you in a PM. There was info in there that shouldn't be made public.
Title: Re: All BASIC Sandbox
Post by: AIR on December 08, 2018, 08:29:17 PM
Damn, this thing uses Go, Rails, and Vue.js? Then shells out to run other stuff?

Anyway, I'm thinking that since Plesk doesn't seem to really know about other LE update processes, and Gitlab doesn't know about Plesk's, you may have had a bit of a 'race' condition, where each was trying to update the cert.  But since neither recognized what the other may have already pulled, they each in fact requested a NEW cert causing the sandbox to hit the LE limit.

It's the only thing that makes sense to me.  So if you insist on using Plesk to manage, then disable any other system that might duplicate that management functionality.

BTW, answer a question:  Are you using Apache or Nginx?  Because GL seems to have an Nginx module that it uses.

Personally, projects like Gitlab are too heavy for me to use.  For git repositories I run, I use either Gogs or Gitea, which are both written in Go and perform much better without all the bells and whistles.  They provide Git, and a Wiki, and both have the added bonus of being able to import repositories from github/bitbucket/etc, AND keep them synchronized with the original....Gitlab appears to allow imports, but doesn't keep the imported repository synced with the original.

AIR.

Title: Re: All BASIC Sandbox
Post by: John on December 08, 2018, 08:36:09 PM
I don't understand why I can't use the cert Plesk created for allbasic.info with GitLab running on the same domain?
Title: Re: All BASIC Sandbox
Post by: AIR on December 08, 2018, 08:50:21 PM
You have to add the sandbox subdomain to the cert, and then tell gitlab to use it.
Title: Re: All BASIC Sandbox
Post by: John on December 08, 2018, 08:53:19 PM
I think we are wasting our time until LE let's us renew certs for the sandbox.

We are in LE purgatory.

I wonder if the GitLab cert would also work for the main domain cert?

I might try running the sandbox under HTTP until the LE cert issue is resolved.
Title: Re: All BASIC Sandbox
Post by: John on December 09, 2018, 12:49:07 PM
I tried running the sandbox under HTTP and was unsuccessful. We are just going to have to wait until Let's Encrypt allows generating certificates for sandbox.allbasic.info again.

Maybe I should have considered the container direction to save me a lot of grief.
Title: Re: All BASIC Sandbox
Post by: John on December 09, 2018, 02:18:43 PM
Quote
This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox may only connect to it securely. As a result, it is not possible to add an exception for this certificate.

Would you know how I can make Firefox allow me to accept the certificate problem and connect to the sandbox like Chrome?

I might try to get ssh working with the sandbox for console git comands.
Title: Re: All BASIC Sandbox
Post by: AIR on December 09, 2018, 05:33:11 PM
Quote
This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox may only connect to it securely. As a result, it is not possible to add an exception for this certificate.

Would you know how I can make Firefox allow me to accept the certificate problem and connect to the sandbox like Chrome?

I might try to get ssh working with the sandbox for console git comands.

Go into "History", select "Show All History", find the link to the sandbox, right-click, and select "Forget About This site"

Then try connecting.

AIR.
Title: Re: All BASIC Sandbox
Post by: AIR on December 09, 2018, 05:58:19 PM
I might try to get ssh working with the sandbox for console git comands.

In the .git folder in the source tree, edit the config file so that the the port is specified:

[remote "origin"]
   url = https://sandbox.allbasic.info:8181/AIR/sb-dev.git


And add the following at the end of the file:

[http]
   sslVerify = false


This will enable https connections with a self-signed cert.  For ssh you're on your own.

You'll need to re-authenticate the first time after you make the changes, because the url has changed.


AIR.
Title: Re: All BASIC Sandbox
Post by: John on December 09, 2018, 06:55:30 PM
Thanks a bunch!

This at least makes the sandbox usable again.

Chrome on my phone wouldn't access the sandbox but Firefox allowed the acception.

$ git config --list is a handy command.

I found the History trick and that worked great as well.

Thanks again for your outstanding support for the forum and the Script BASIC project.
Title: Re: All BASIC Sandbox
Post by: John on December 10, 2018, 12:52:39 AM
I didn't realize FORMAT supported multiple variables in its definition. This news and combining it with the curses extension module could produce some fancy FORMAT functions.

Code: Script BASIC
  1. PRINT FORMAT("send=%s\nhost=%s\nrecv=%s\nmsg=%s\n",_send,_host,_recv,_msg)
  2.  
Title: Re: All BASIC Sandbox
Post by: John on December 10, 2018, 12:58:19 PM
I updated the SB-Dev project sandbox with your ingredients from the SB kitchen. It built clean on my Ubuntu 18.10 dev laptop. I plan to do the same for CentOS using the server OS. How are things going with the Mac SB version? Any luck finding a GUI library you like that would work as an extension module?
Title: Re: All BASIC Sandbox
Post by: AIR on December 10, 2018, 07:41:41 PM
How are things going with the Mac SB version? Any luck finding a GUI library you like that would work as an extension module?

Have not done anything, working on MBC lately...
Title: Re: All BASIC Sandbox
Post by: John on December 10, 2018, 08:34:09 PM
Great to see you pick MBC back up. Will you be creating a sandbox project for it?
Title: Re: All BASIC Sandbox
Post by: AIR on December 11, 2018, 03:28:47 PM
I have my own repositories for this...
Title: Re: All BASIC Sandbox
Post by: John on December 11, 2018, 08:45:12 PM
I have my own repositories for this...

 :-[  :-X

Oh.

Is this something you might sell like the PurliBASIC translator?
Title: Re: All BASIC Sandbox
Post by: John on December 11, 2018, 10:53:51 PM
I think I found the web browser that works best for me on my Samsung S8+. The Samsung browser that came with phone. More intuitive and feature rich than Chrome or Firefox. The first phone browser with a forward and back button.

I still prefer Firefox on my laptop.
Title: Re: All BASIC Sandbox
Post by: AIR on December 12, 2018, 04:33:07 PM
Is this something you might sell like the PurliBASIC translator?

No, mbc has always been free (as far as gpl-2 and the BCX Exception are anyway).

MBC git repository (https://git.binarymagic.net/AIR/mbc)

AIR.
Title: Re: All BASIC Sandbox
Post by: John on December 12, 2018, 05:47:41 PM
Cool!

Thanks for sharing. Does MBC still run on Linux?
Title: Re: All BASIC Sandbox
Post by: AIR on December 12, 2018, 09:06:00 PM
Ubuntu 18.10 YES.   

Raspbian 9.6 (Debian Stretch armhf) YES.

Ubuntu 16.04 throws an error when building the translator with the translator.

The bulk of my development is done on macOS, so I'm not testing other Linux distributions/versions.

AIR.
Title: Re: All BASIC Sandbox
Post by: John on December 12, 2018, 09:24:28 PM
Would you mind if I get a Linux MBC project going in the sandbox?
Title: Re: All BASIC Sandbox
Post by: AIR on December 12, 2018, 09:25:24 PM
Go ahead....
Title: Re: All BASIC Sandbox
Post by: John on December 12, 2018, 10:26:50 PM
Is there an IUP example with the MBC distribution?

Google is doing a great job of indexing the forum. Your MBC thread has already been indexed.
Title: Re: All BASIC Sandbox
Post by: AIR on December 13, 2018, 08:18:45 AM
Is there an IUP example with the MBC distribution?

No, IUP doesn't have native interface on macOS so....
Title: Re: All BASIC Sandbox
Post by: John on December 13, 2018, 10:38:06 AM
I still think MBC has a purpose on Linux.
Title: Re: All BASIC Sandbox
Post by: AIR on December 13, 2018, 02:11:54 PM
Early Holiday, John.....see attached.

You may need to edit some of this, but the hard work is done....
Title: Re: All BASIC Sandbox
Post by: John on December 13, 2018, 10:56:48 PM
AIR,

Let's Encrypt is allowing sandbox.allbasic.info certificates to be created again. I create one under Plesk for the sub-domain which didn't get HTTPS working with Gitlab. I then tried to enable LE in the gitlab.rb file and get this error and the reconfigure fails.

Quote
There was an error running gitlab-ctl reconfigure:

letsencrypt_certificate[sandbox.allbasic.info] (letsencrypt::http_authorization line 3) had an error: RuntimeError: acme_certificate[staging] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/letsencrypt/resources/certificate.rb line 20) had an error: RuntimeError: [sandbox.allbasic.info] Validation failed for domain sandbox.allbasic.info

Title: Re: All BASIC Sandbox
Post by: John on December 13, 2018, 11:04:27 PM
Early Holiday, John.....see attached.

You may need to edit some of this, but the hard work is done....

Thanks Santa!

I didn't see this until now. It's been pushed to the scriptbasic/sb-dev sandbox project.

Title: Re: All BASIC Sandbox
Post by: John on December 15, 2018, 11:34:53 AM
AIR,

Any suggestions how I might get Gitlab to generate and validate a Let's Encrypt certificate?

Title: Re: All BASIC Sandbox
Post by: AIR on December 15, 2018, 07:46:44 PM
Personally, I would not use Gitlab's LE support, since it messed up before.

You can try the steps in this guide instead: https://www.digitalocean.com/community/tutorials/how-to-secure-gitlab-with-let-s-encrypt-on-ubuntu-16-04
Title: Re: All BASIC Sandbox
Post by: John on December 15, 2018, 09:59:08 PM
Thanks for the link.

Quote
Prepare for the Let's Encrypt Web Root Domain Verification

In order to receive an SSL certificate from the Let's Encrypt certificate authority, we must prove that we own the domain that the certificate will be provided for. There are multiple methods of proving domain ownership, each of which require root or administrator access to the server.

GitLab contains an internally managed Nginx web server for serving the application itself. This makes the installation rather self-contained, but it does add an additional layer of complexity when attempting to modify the web server itself.

Since the embedded Nginx is currently being utilized to serve GitLab itself, the best domain validation method is the web root method. Certbot will use the existing web server to serve a known file from the server on port 80. This proves to the certificate authority that the person requesting the certificate has administrative control over the web server, which effectively proves ownership over the server and domain.

To set up web root domain validation for GitLab, our first step will be to create a dummy document root:

    sudo mkdir -p /var/www/letsencrypt

This will be unused by normal Nginx operations, but will be used by Certbot for domain verification.

Next, we need to adjust GitLab's Nginx configuration to use this directory. Open up the main GitLab configuration file by typing:

    sudo nano /etc/gitlab/gitlab.rb

Inside, we need to add a line that will inject a custom directive into GitLab's Nginx configuration file. It's probably best to scroll down to the GitLab Nginx section of the file, but the line can be placed anywhere.

Paste in the following line:
/etc/gitlab/gitlab.rb

. . .
nginx['custom_gitlab_server_config'] = "location ^~ /.well-known { root /var/www/letsencrypt; }"
. . .

The Let's Encrypt web root verification method places a file within a .well-known directory in a document root so that the certificate authority can validate it. This line tells Nginx to serve requests for /.well-known from the web root we created a moment ago.

When you are finished, save and close the file.

Next, apply the changes to GitLab's Nginx configuration by reconfiguring the application again:

    sudo gitlab-ctl reconfigure

The server should now be set up to successfully validate your domain.

Since I already have an installed LE cert for sandbox.allbasic.info via the Plesk extension, shouldn't I be able to point nginx to the Plesk generated cert? This way Plesk auto renews the cert (like all the other sites I host) and this problem goes away forever.

My curiosity still haunts me how Gitlab created its initial cert?
Title: Re: All BASIC Sandbox
Post by: John on December 16, 2018, 05:13:35 PM
This is where Plesk stores the well-known hash for sandbox.allbasic.info.

Should I be able to point the Gitlab nginx well-know to this path?

[root@ip-172-30-0-53 acme-challenge]# ls -l
total 4
-rw-r--r--. 1 allbasic psacln 87 Dec  8 00:19 61Zs0ZbyRgTanhyS9WLODW36i5zsEOHjQbE9YGBQUMk
[root@ip-172-30-0-53 acme-challenge]# pwd
var/www/vhosts/allbasic.info/sandbox.allbasic.info/.well-known/acme-challenge
[root@ip-172-30-0-53 acme-challenge]#
Title: Re: All BASIC Sandbox
Post by: John on December 16, 2018, 05:39:28 PM
I added the following to the /etc/gitlab/gitlab.rb file.

nginx['custom_gitlab_server_config'] = "location ^~ /.well-known { root /var/www/vhosts/allbasic.info/sandbox.allbasic.info/.well-known/acme-challenge; }"

I then reconfigured Gitlab. No change if I eliminate the :8181 port reference and let the proxy reverse handle the redirect.

I then enabled Let's Encrypt in the gitlab.rb file and got the following error on reconfigure.


Running handlers:
There was an error running gitlab-ctl reconfigure:

letsencrypt_certificate[sandbox.allbasic.info] (letsencrypt::http_authorization line 3) had an error: RuntimeError: acme_certificate[staging] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/letsencrypt/resources/certificate.rb line 20) had an error: RuntimeError: [sandbox.allbasic.info] Validation failed for domain sandbox.allbasic.info


Here is the gitlab.rb Template (https://gitlab.com/gitlab-org/omnibus-gitlab/raw/master/files/gitlab-config-template/gitlab.rb.template) file fo reference.

Docs on Gitlab - Let's Encrypt Auto-Renewal (https://docs.gitlab.com/omnibus/settings/ssl.html#automatic-renewal).

Here is the certificate.rb file.
Code: Ruby
  1. property :cn, String, name_property: true
  2. property :fullchain, String, required: true
  3. property :key, String, required: true
  4. property :owner, [String, nil], default: lazy { node['letsencrypt']['owner'] }
  5. property :chain, [String, nil], default: lazy { node['letsencrypt']['chain'] }
  6. property :wwwroot, String, default: lazy { node['letsencrypt']['wwwroot'] }
  7. property :alt_names, Array, default: lazy { node['letsencrypt']['alt_names'] }
  8. property :key_size, [Integer, nil], default: lazy { node['letsencrypt']['key_size'] }
  9. property :crt, [String, nil], default: lazy { node['letsencrypt']['crt'] }
  10. property :group, [String, nil], default: lazy { node['letsencrypt']['group'] }
  11.  
  12. action :create do
  13.   # Attempt to fetch a certificate from Let's Encrypt staging instance
  14.   # If that succeeds, then fetch a certificate from production
  15.   # This helps protect users from hitting Let's Encrypt rate limits if
  16.   # they provide invalid data
  17.   helper = LetsEncryptHelper.new(node)
  18.   contact_info = helper.contact
  19.  
  20.   acme_certificate 'staging' do
  21.     alt_names new_resource.alt_names unless new_resource.alt_names.empty?
  22.     key_size new_resource.key_size unless new_resource.key_size.nil?
  23.     group new_resource.group unless new_resource.group.nil?
  24.     owner new_resource.owner unless new_resource.owner.nil?
  25.     chain "#{new_resource.chain}-staging" unless new_resource.chain.nil?
  26.     crt "#{new_resource.crt}-staging" unless new_resource.crt.nil?
  27.     contact contact_info
  28.     fullchain "#{new_resource.fullchain}-staging"
  29.     cn new_resource.cn
  30.     key "#{new_resource.key}-staging"
  31.     endpoint 'https://acme-staging.api.letsencrypt.org/'
  32.     wwwroot new_resource.wwwroot
  33.     sensitive true
  34.   end
  35.  
  36.   ruby_block 'reset private key' do
  37.     block do
  38.       node.normal['acme']['private_key'] = nil
  39.     end
  40.   end
  41.  
  42.   acme_certificate 'production' do
  43.     alt_names new_resource.alt_names unless new_resource.alt_names.empty?
  44.     key_size new_resource.key_size unless new_resource.key_size.nil?
  45.     group new_resource.group unless new_resource.group.nil?
  46.     owner new_resource.owner unless new_resource.owner.nil?
  47.     chain new_resource.chain unless new_resource.chain.nil?
  48.     crt new_resource.crt unless new_resource.crt.nil?
  49.     contact contact_info
  50.     fullchain new_resource.fullchain
  51.     cn new_resource.cn
  52.     key new_resource.key
  53.     wwwroot new_resource.wwwroot
  54.     notifies :run, 'execute[reload nginx]'
  55.     sensitive true
  56.   end
  57. end
  58.  


[root@ip-172-30-0-53 resources]# find / -name *.crt
/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
/etc/pki/ca-trust/source/ca-bundle.legacy.crt
/etc/pki/tls/certs/ca-bundle.crt
/etc/pki/tls/certs/ca-bundle.trust.crt
/etc/pki/tls/certs/localhost.crt
/etc/gitlab/ssl/sandbox.allbasic.info.crt
/root/gitlab-cleanse-2018-09-29T19:18/ssl/oxygenbasic.org.crt
/root/gitlab-cleanse-2018-09-29T19:42/ssl/oxygenbasic.org.crt
/var/opt/gitlab/postgresql/data/server.crt
/var/www/vhosts/northwestliving.info/httpdocs/blog/wp-includes/certificates/ca-bundle.crt
/var/www/vhosts/clouds-r.us/httpdocs/home/wp-includes/certificates/ca-bundle.crt
/usr/share/pki/ca-trust-legacy/ca-bundle.legacy.default.crt
/usr/share/pki/ca-trust-legacy/ca-bundle.legacy.disable.crt
/usr/local/psa/var/apspackages/adilUsnhf.zipcddac49b-7807-d14e-9058/cache/htdocs/wp-includes/certificates/ca-bundle.crt
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/chef-13.6.4/spec/data/trusted_certs/example.crt
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/chef-13.6.4/spec/data/trusted_certs/example_no_cn.crt
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/eventmachine-1.0.9.1/tests/client.crt
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/excon-0.62.0/tests/data/127.0.0.1.cert.crt
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/excon-0.62.0/tests/data/excon.cert.crt
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/httparty-0.13.7/spec/fixtures/ssl/generated/bogushost.crt
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/httparty-0.13.7/spec/fixtures/ssl/generated/ca.crt
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/httparty-0.13.7/spec/fixtures/ssl/generated/selfsigned.crt
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/httparty-0.13.7/spec/fixtures/ssl/generated/server.crt
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/redis-3.3.5/test/support/ssl/trusted-ca.crt
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/redis-3.3.5/test/support/ssl/trusted-cert.crt
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/redis-3.3.5/test/support/ssl/untrusted-ca.crt
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/redis-3.3.5/test/support/ssl/untrusted-cert.crt
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/rest-client-2.0.2/spec/integration/capath_digicert/digicert.crt
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/rest-client-2.0.2/spec/integration/capath_verisign/verisign.crt
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/rest-client-2.0.2/spec/integration/certs/digicert.crt
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/rest-client-2.0.2/spec/integration/certs/verisign.crt
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/ruby-saml-1.7.2/test/certificates/ruby-saml-2.crt
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/ruby-saml-1.7.2/test/certificates/ruby-saml.crt
[root@ip-172-30-0-53 resources]#

[root@ip-172-30-0-53 resources]# find / -name *.key
find: /proc/21624: No such file or directory
/etc/pki/tls/private/localhost.key
/etc/named.iscdlv.key
/etc/named.root.key
/etc/trusted-key.key
/etc/gitlab/ssl/sandbox.allbasic.info.key
/root/gitlab-cleanse-2018-09-29T19:18/ssl/oxygenbasic.org.key
/root/gitlab-cleanse-2018-09-29T19:42/ssl/oxygenbasic.org.key
/var/opt/gitlab/postgresql/data/server.key
/var/named/chroot/var/run/named/session.key
/usr/share/doc/openssh-7.4p1/PROTOCOL.key
/usr/local/psa/admin/plib/modules/letsencrypt/vendor/namshi/jose/tests/public.es512.key
/usr/local/psa/admin/plib/modules/letsencrypt/vendor/namshi/jose/tests/private-ne.key
/usr/local/psa/admin/plib/modules/letsencrypt/vendor/namshi/jose/tests/public.es384.key
/usr/local/psa/admin/plib/modules/letsencrypt/vendor/namshi/jose/tests/private.es384.key
/usr/local/psa/admin/plib/modules/letsencrypt/vendor/namshi/jose/tests/private.key
/usr/local/psa/admin/plib/modules/letsencrypt/vendor/namshi/jose/tests/public.key
/usr/local/psa/admin/plib/modules/letsencrypt/vendor/namshi/jose/tests/private.es512.key
/usr/local/psa/admin/plib/modules/letsencrypt/vendor/namshi/jose/tests/private.es256.key
/usr/local/psa/admin/plib/modules/letsencrypt/vendor/namshi/jose/tests/public.es256.key
/usr/local/psa/admin/plib/modules/letsencrypt/vendor/namshi/jose/tests/public-ne.key
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/chef-13.6.4/spec/data/ssl/chef-rspec.key
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/eventmachine-1.0.9.1/tests/client.key
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/excon-0.62.0/tests/data/127.0.0.1.cert.key
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/excon-0.62.0/tests/data/excon.cert.key
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/httparty-0.13.7/spec/fixtures/ssl/generated/ca.key
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/httparty-0.13.7/spec/fixtures/ssl/generated/server.key
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/httpclient-2.8.3/test/client-pass.key
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/httpclient-2.8.3/test/client.key
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/httpclient-2.8.3/test/server.key
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/redis-3.3.5/test/support/ssl/trusted-ca.key
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/redis-3.3.5/test/support/ssl/trusted-cert.key
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/redis-3.3.5/test/support/ssl/untrusted-ca.key
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/redis-3.3.5/test/support/ssl/untrusted-cert.key
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/ruby-saml-1.7.2/test/certificates/ruby-saml.key
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/grpc-1.15.0-x86_64-linux/src/ruby/spec/testdata/client.key
/opt/gitlab/embedded/lib/ruby/gems/2.4.0/gems/grpc-1.15.0-x86_64-linux/src/ruby/spec/testdata/server1.key
[root@ip-172-30-0-53 resources]#




Not sure where to go from here.

Title: Re: All BASIC Sandbox
Post by: John on December 17, 2018, 01:46:23 PM
I updated the sandbox Gitlab Prometheus integration as I was getting a warning when I would run the Gitlab reconfigure that the current version was being depreciated in version 12.

Quote
Prometheus is a powerful time-series monitoring service, providing a flexible platform for monitoring GitLab and other software products. GitLab provides out of the box monitoring with Prometheus, providing easy access to high quality time-series monitoring of GitLab services.

Title: Re: All BASIC Sandbox
Post by: John on December 20, 2018, 04:44:30 PM
I think the link you sent me only solves 1/2 the problem. I need to get the Gitlab cert links pointing tp the Plesk Let's Encrypt active certs paths and it might solve the problem.

I'll let you know.

Code: Ruby
  1.     "nginx": {
  2.       "listen_port": 8181,
  3.       "custom_gitlab_server_config": "location ^~ /.well-known { root var/www/vhosts/allbasic.info/sandbox.allbasic.info/.well-known/acme-challenge; }",
  4.       "ssl_certificate": "/etc/gitlab/ssl/sandbox.allbasic.info.crt",
  5.       "ssl_certificate_key": "/etc/gitlab/ssl/sandbox.allbasic.info.key",
  6.  

I'm not sure wihere the ssl_certificate links should point to.


Code: Bash
  1. [root@ip-172-30-0-53 gitlab]# find / -name 'sandbox.allbasic.info*'
  2. /etc/httpd/conf/plesk.conf.d/vhosts/sandbox.allbasic.info.conf
  3. /etc/nginx/plesk.conf.d/vhosts/sandbox.allbasic.info.conf
  4. /etc/gitlab/ssl/sandbox.allbasic.info.crt
  5. /etc/gitlab/ssl/sandbox.allbasic.info.crt_bk
  6. /etc/gitlab/ssl/sandbox.allbasic.info.key
  7. /etc/gitlab/ssl/sandbox.allbasic.info.key_bk
  8. /etc/gitlab/ssl/sandbox.allbasic.info.key-staging
  9. /etc/gitlab/ssl/sandbox.allbasic.info.key-staging_bk
  10. /var/lib/psa/dumps/domains/allbasic.info/sites/sandbox.allbasic.info
  11. /var/www/vhosts/system/sandbox.allbasic.info
  12. /var/www/vhosts/allbasic.info/logs/sandbox.allbasic.info
  13. /var/www/vhosts/allbasic.info/sandbox.allbasic.info
  14. /usr/local/psa/etc/logrotate.d/sandbox.allbasic.info
  15. /usr/local/psa/var/modules/letsencrypt/etc/archive/sandbox.allbasic.info
  16. /usr/local/psa/var/modules/letsencrypt/etc/live/sandbox.allbasic.info
  17. /opt/plesk/php/7.2/etc/php-fpm.d/sandbox.allbasic.info.conf
  18. [root@ip-172-30-0-53 gitlab]#
  19.  
Title: Re: All BASIC Sandbox
Post by: AIR on December 20, 2018, 06:56:43 PM
Try looking in: /usr/local/psa/var/modules/letsencrypt/etc/live/sandbox.allbasic.info
Title: Re: All BASIC Sandbox
Post by: John on December 20, 2018, 08:07:13 PM
Code: Bash
  1. [root@ip-172-30-0-53 sandbox.allbasic.info]# ls -la
  2. total 8
  3. drwx------.  2 psaadm psaadm   93 Dec 17 01:49 .
  4. drwx------. 15 psaadm psaadm 4096 Dec 10 15:51 ..
  5. lrwxrwxrwx.  1 psaadm psaadm   46 Dec 17 01:49 cert.pem -> ../../archive/sandbox.allbasic.info/cert10.pem
  6. lrwxrwxrwx.  1 psaadm psaadm   47 Dec 17 01:49 chain.pem -> ../../archive/sandbox.allbasic.info/chain10.pem
  7. lrwxrwxrwx.  1 psaadm psaadm   51 Dec 17 01:49 fullchain.pem -> ../../archive/sandbox.allbasic.info/fullchain10.pem
  8. lrwxrwxrwx.  1 psaadm psaadm   49 Dec 17 01:49 privkey.pem -> ../../archive/sandbox.allbasic.info/privkey10.pem
  9. -rw-r--r--.  1 psaadm psaadm  544 Nov  5 14:48 README
  10. [root@ip-172-30-0-53 sandbox.allbasic.info]# pwd
  11. /usr/local/psa/var/modules/letsencrypt/etc/live/sandbox.allbasic.info
  12. [root@ip-172-30-0-53 sandbox.allbasic.info]#
  13.  
  14. [root@ip-172-30-0-53 sandbox.allbasic.info]# cat README
  15. This directory contains your keys and certificates.
  16.  
  17. `privkey.pem`  : the private key for your certificate.
  18. `fullchain.pem`: the certificate file used in most server software.
  19. `chain.pem`    : used for OCSP stapling in Nginx >=1.3.7.
  20. `cert.pem`     : will break many server configurations, and should not be used
  21.                  without reading further documentation (see link below).
  22.  
  23. We recommend not moving these files. For more information, see the Certbot
  24. User Guide at https://certbot.eff.org/docs/using.html#where-are-my-certificates .
  25. [root@ip-172-30-0-53 sandbox.allbasic.info]#
  26.  
  27.  
Title: Re: All BASIC Sandbox
Post by: AIR on December 20, 2018, 10:02:19 PM
I think you need to do this in your gitlab.rb file (disable the built in LE support first, then use the path you listed before):

(https://i.imgur.com/vIE0H8W.png)
Title: Re: All BASIC Sandbox
Post by: John on December 20, 2018, 11:26:09 PM
We're back!

Gitlab hung with this parameter enabled.

Code: Text
  1. nginx['redirect_http_to_https'] = true
  2.  

Thanks for all your help with this. It's been a long road. On a positive note, Plesk will automatically keep the cert. renewed like it does for the other sites I host.

Title: Re: All BASIC Sandbox
Post by: John on December 20, 2018, 11:51:33 PM
There is still a problem if I use the proxy reverse as the commit data isn't loading. With the :8181 reference in the URL, everything seems fine.

I may try the PHP redirect I use for sites with no home page to resolve :8181 being in the URL.
Title: Re: All BASIC Sandbox
Post by: John on December 21, 2018, 03:08:38 AM
Quote
I may try the PHP redirect I use for sites with no home page to resolve :8181 being in the URL.

That worked.
Title: Re: All BASIC Sandbox
Post by: John on December 25, 2018, 09:44:27 PM
AIR,

Would you have time to point me in the right direction with getting syntax highlighting working for the languages being hosted in the sandbox?
Title: Re: All BASIC Sandbox
Post by: John on June 17, 2019, 04:17:14 PM
The clone URL now includes the :8181 port number.