Setdomain add a check for private ip ranges

[szaimen]

filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE |  FILTER_FLAG_NO_RES_RANGE)

If that is true do not continue and print the found ip address into the error message. Should be added before the port open check

Also if the domain that was found is the domain itself, set it to empty.

[ghost]

I dont understand this. Are private IP addresses not allowed to be used? And which ones do you recommend using?

[szaimen]

I dont understand the question... The domain that you enter during the setup should have set a public ip-address...

[szaimen]

The main reason for this check is to make the debugging easier during the setup...

[rhatguy]

How is the installer determining the IP address now? When I try to install its coming up with the message "It seems like the ip-address is set to an internal or reserved ip-address. This is not supported. (It was found to be set to '10.1.1.17')".

The VM I'm running this on is on a private IP, but I have a reverse proxy setup on the dns name I'm using. I also have /etc/hosts setup to point that name to my real public IP address.

how are we supposed to specify the real hostname of our systems after this change if the system really is on a private IP?

[szaimen]

This is basically the reason why we introduced this check. You can either try to remove your domain from the /etc/hosts file or try to overwrite it with https://stackoverflow.com/questions/32079364/how-can-you-make-the-docker-container-use-the-host-machines-etc-hosts-file/58994501#58994501

[myfp31]

Is there a way to avoid this check. I'm using NextCloud internally and I don't have any external IP.
I'm managing certificates on a RP (Caddy) but CaddyIP is on 192.168.1.X/24.
Then I can't manage deploying AIO version anymore.
Thanks in advance, Regards

[szaimen]

Then I can't manage deploying AIO version anymore.

You already managed to do so before?
Can you point out the steps that were needed before to make everything work for you locally?

[gclawes]

I'm having the same issue as @myfp31. Attempting to set up nextcloud using AIO on an internal network, using Caddy and an internal ACME CA for the reverse proxy (Caddyfile below). This should be a perfectly valid deployment setup, especially for homelab users.

Caddyfile:

nextcloud.virt.home.arpa {
    reverse_proxy localhost:11000
    tls [email protected] {
        ca https://step-ca.virt.home.arpa/acme/acme/directory
    }
}

https://nextcloud.virt.home.arpa:8443 {
    reverse_proxy https://localhost:8080 {
        transport http {
            tls_insecure_skip_verify
        }
    }
    tls [email protected] {
        ca https://step-ca.virt.home.arpa/acme/acme/directory
    }
}

[myfp31]

You already managed to do so before? Can you point out the steps that were needed before to make everything work for you locally?

Hello,

I would say yes, but to be honest, I'm just deploying it successfully three weeks ago in a pure lab (I was able to login to NC web interface as an admin and create users).
my goal is to migrate from a linuxserver implementation the home NC and I was interested by the AIO implementation.

So I have an internal DNS with the right resolution.
Caddy is deployed and configured as provided in reverse-proxy.md guide with internal CA to provide certificate.
If needed, I will access to Caddy Revers proxy thanks to a VPN access. Then, I really don't need a public IP address for NextCloud.

But I also understand that providing an AIO implementation for all use cases is quite impossible. Then let me know if you need to keep this filter I will try to deploy the standard NextCloud solution with docker compose method.

If needed, I would be able to do some tests Tuesday or Wednesday.

In any case, thanks for all this implementation.

[szaimen]

If you were successful, it seems like there is indeed a way to deploy it locally ;)

Do you mind creating a PR that adds some documentation on this?

In the meanwhile I modified #859 which will allow private ip-addresses when running behind a reverse proxy again after it gets merged and released.

[myfp31]

For sure, I will do a PR if you think it could be useful. I hope it will be understandable.

[szaimen]

Yes, I think it will be useful! Please create the PR and I will help with the details :)

[myfp31]

If I'm not wrong, the change is only in the develop version.

With that version, I confirm it works fine, it's just necessary to add caddy root certificate to trusted certificate of nextcloud-aio-mastercontainer.
In order to do that I propose to perform manually :

• add new volume with the caddy root certificate (name localRoot.crt)
• launch this command to concatenate the new certificate to the currents : docker exec nextcloud-aio-mastercontainer bash -c "cat /etc/ssl/certs/localRoot.crt >>/etc/ssl/certs/ca-certificates.crt"

does it sounds good for you ?
If yes, I will create the PR with all details

[szaimen]

Hi thanks for your attempt! :)

It seems like I've overread that you used self-signed certificates for this which is not really the way how I would do it honestly...
I'll add some documentation how I would recommend to get it running locally after I've addressed #876

And btw: adding the cert to the mastercontainer is probably not needed anymore when #873 is merged since you can simply disable the domain validation then.

[szaimen]

I already documented my ideas in #878