I just used cp to overwrite the certs like in the post I linked to. So far, I thought that executing service caddy reload would be enough to get caddy to serve the new certificate after overwriting it, but that does not seem to be the case. Therefore, do I need to fully restart it or is there a better way to get caddy to serve the new certificate? I've already looked through the documentation but couldn't find an answer. Adding --force to the reload command also didn't have the desired effect."similar to this" doesn't help--how, exactly, did you "manually replac[e] the ssl certificate for the caddy webserver"? The script you linked to wouldn't tell Caddy to use the cert you copied.
The script you linked to puts the cert and key in /etc/ssl, and Caddy doesn't keep its certs there--and there's no reason you should have expected that it does. If you want to use certs obtained other than by Caddy with Caddy, you'll need to tell Caddy where the cert and key are in the Caddyfile.I just used cp to overwrite the certs like in the post I linked to.
That isn't the problem. I already modified the Caddyfile accordingly and the script copies the cert and key to the appropriate location as specified in the Caddyfile. When I tested this for the first time it worked just fine, but I think this was only the case because the path to the cert and key was actually changed in the Caddyfile by me before I executed the reload command. Now, when overwriting the cert and key with updated ones from the CA, caddy seems to ignore this and still serves the old certificate.The script you linked to puts the cert and key in /etc/ssl, and Caddy doesn't keep its certs there--and there's no reason you should have expected that it does. If you want to use certs obtained other than by Caddy with Caddy, you'll need to tell Caddy where the cert and key are in the Caddyfile.
...and didn't think that was relevant, even just a little bit, to mention the two previous times I asked you how you made that change?I already modified the Caddyfile accordingly
service caddy reload
, and it's still serving the old cert files, sure, try restarting it. But I'd consider that a likely bug in Caddy and suggest you follow up on their forum.I'm sorry, but by saying that I "used cp to overwrite the certs", it seemed pretty clear to me that I am actually replacing the existing cert and key with my own ones instead of just copying them to some random location on the system and hoping that caddy would somehow pick them up and serve them. Overall, the only reason why I even touched the Caddyfile was just to change the names of the files and not the folder they are in....and didn't think that was relevant, even just a little bit, to mention the two previous times I asked you how you made that change?
If the Caddyfile is correctly configured to use external cert files, those files have changed, you've doneservice caddy reload
, and it's still serving the old cert files, sure, try restarting it. But I'd consider that a likely bug in Caddy and suggest you follow up on their forum.
You have obtained your Let's Encrypt certificate using the staging server. This certificate will not be trusted by your browser and will cause SSL errors when you connect. Once you've verified that everything else is working correctly, you should issue a trusted certificate. To do this, run: iocage exec nextcloud /root/remove-staging.sh
apologizes.. I should have mentioned it doesn't work either way.You must use a host name to connect, you cannot use an IP address. If I remember correctly this is explicitly mentioned in the instructions.
{"level":"info","ts":1679968795.6705623,"logger":"tls.obtain","msg":"obtaining certificate","identifier":"redacted.net"} {"level":"info","ts":1679968795.8707187,"logger":"http.acme_client","msg":"trying to solve challenge","identifier":"redacted.net","challenge_type":"dns-01","ca":"https://acme-staging-v02.api.letsencrypt.org/directory"} {"level":"error","ts":1679968818.5653934,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"redacted.net","issuer":"acme-staging-v02.api.letsencrypt.org-directory","error":"[redacted.net] solving challenges: waiting for solver certmagic.solverWrapper to be ready: checking DNS propagation of \"_acme-challenge.redacted.net\": dial tcp 10.10.26.80:53: i/o timeout (order=https://acme-staging-v02.api.letsencrypt.org/acme/order/95444404/7979776364) (ca=https://acme-staging-v02.api.letsencrypt.org/directory)"}
iocage console <Jail_Name> service mysql-server stop pkg delete mariadb103-server pkg autoremove pkg install mariadb106-server</code></pre> mv /var/db/mysql/my.cnf /usr/local/etc/mysql/conf.d/nextcloud.cnf service mysql-server start mysql_upgrade -p edit config.php change line to 'dbhost' => 'localhost:/var/run/mysql/mysql.sock', iocage restart <Jail_Name>
pkg remove -qy "php80" "php80-ctype" "php80-curl" "php80-dom" "php80-filter" "php80-gd" "php80-xml" "php80-mbstring" "php80-posix" "php80-session" "php80-simplexml" "php80-xmlreader" "php80-xmlwriter" "php80-zip" "php80-zlib" "php80-fileinfo" "php80-bz2" "php80-intl" "php80-ldap" "php80-pecl-smbclient" "php80-ftp" "php80-imap" "php80-bcmath" "php80-gmp" "php80-exif" "php80-pecl-APCu" "php80-pecl-memcache" "php80-pecl-redis" "php80-pecl-imagick" "php80-pcntl" "php80-phar" "php80-iconv" "php80-xsl" "php80-opcache" "php80-pdo_mysql" "php80-mysqli" pkg install -qy "php81" "php81-ctype" "php81-curl" "php81-dom" "php81-filter" "php81-gd" "php81-xml" "php81-mbstring" "php81-posix" "php81-session" "php81-simplexml" "php81-xmlreader" "php81-xmlwriter" "php81-zip" "php81-zlib" "php81-fileinfo" "php81-bz2" "php81-intl" "php81-ldap" "php81-pecl-smbclient" "php81-ftp" "php81-imap" "php81-bcmath" "php81-gmp" "php81-exif" "php81-pecl-APCu" "php81-pecl-memcache" "php81-pecl-redis" "php81-pecl-imagick" "php81-pcntl" "php81-phar" "php81-iconv" "php81-xsl" "php81-opcache" "php81-pdo_mysql" "php81-mysqli"
Because NC26 complains if it isn't there.Why was php81-sysvsem added to upgrade to NC26?
Not that I know of.Is there a reason to remove the db_root_password authentication
I use a Nginx Proxy Manager as a reverse proxy, and it is
Client -> Nginx Proxy Manager (10.10.10.252) -> Caddy (10.10.10.16) -> nextcloud (10.10.10.16)
and I can access the nextcloud it's almost ok.
but the client's IP is not correctly transferred, the ip showed in nextcloud is the reverse proxy's ip 10.10.10.252.
and do you have any solutions? with the plugin installed before, the ip is shown correctly.
Installation wasn't successful; you should see an indication of why in the log file.However, the login screen I'm getting is confusing - see image.
how do I fix this >>Installation wasn't successful; you should see an indication of why in the log file.
Creating the Nextcloud database failed, which caused the installation failure (which resulted in the screen you saw, rather than a normal login page). There should still be something further up--i.e., earlier--in the log file indicating what went wrong with the database.ERROR 2002 (HY000): Can't connect to local server through socket '/var/run/mysql/mysql.sock' (2)
Command: mysql -e CREATE DATABASE nextcloud; failed!