A user that log in to the portal and tries to create a website is not given the option to choose an IP address, only the wildcard option is given: If I try to add a web domain as admin, first it only shows the wildcard IP, but after I chosen a client, the IP becomes an option: Despite I choose to create the website with the given IP, 96.216.210.192, it afterwards shows as the wildcard IP in the portal. Apache seems to have been configured the the IP however: Code: root@ic:/etc/apache2/sites-enabled# grep VirtualHost 100-foo100.se.vhost <VirtualHost 95.216.210.192:80> </VirtualHost> I did not have this behaviour with the previous ISPConfig installation, I suspect there is a setting somewhere, but I cant find where.
This is new, as it is best practice to use * instead of the IP. You can enable the IP's to be selected under System -> Server IP Addresses -> 11.22.33.44 -> HTTP NameVirtualHost. It should not show up when you're admin, I'll try to reproduce this and see what's wrong.
Oki, n.b, it is also possible to create a website with an IP via API, which then causes issue in the portal.
This is not causing issues in ISPConfig, it's causing issues in Apache and Nginx. The API is an admin login, an admin should know when he can use an IP and when not. An IP address is a stronger match than a wildcard, which means that websites will not work properly when you mix * and IP on a server for domains that point to the same IP in DNS. the website that you assign the IP will get all traffic from sites that use * even if the domain does not match. An Ip is only used in case that you have a dedicated IPv4 address for each website, which was the case in the past but today, such setups are not used anymore. Therefore, it's best practiceto use *.
But with this reasoning there is no need to fix it in the portal either. Well, I disagree, IP is more precise and hence more predictable. But, I guess it is a matter of opinion, not what is right or wrong.
The portal is for end users, that does not know this. Therefore you can configure ISPConfig to only allow * or onkly allow the IP or to allow both for a customer, and the default is to allow only *. If you have a dedicated IP for each website, then yes. And if you have just one IP for the whole server, then there is no difference. But no matter what, ISPConfig supports all config options and you are free to chose what you prefer.
Well, as Thom said above, "It should not show up when you're admin, I'll try to reproduce this and see what's wrong.", he, and I, are referring to the admin part of the portal. Yes, and why should I only have one IP per server? With LE the need for dedicated IP has decreased, yes, but still there are clients that need their own IP. Neither cPanel nor DA considers wildcard as best practice.
It does not show up for the admin unless you enabled it under system > server IP (namevirtualhost checkbox), just tested with ISPConfig 3.2.2 here. Or you have set the IP for the site manually by using the API if you created the site by API, as this will make it show up as well, just for the admin. First, it does not matter what cPanel or DA considers to be a best practice, they are not the ones that define any standards. What we consider to be best practice is what works best for hosting control panel admins and users from our experience that we get with thousands of admins and users here and in our hosting businesses. It's great for you when you have plenty of IPv4 addresses left in your subnets, but that's not the reality of most hosters and users that ran servers today, this means that most new systems get assigned just a single IP address today and unless you have to deal with SSL/TLS clients that do not support SNI, then having just one IP address is generally fine. Btww, it does not matter if you use a Let's encrypt SSL cert or if you buy one.
When I choose a client, the IP turns up, and namevirtualhost checkbox is not checked. As I said above and as the image I provided shows.
Ok, your right. I missed choosing a client. This should not happen indeed. I've added a bug report for that. https://git.ispconfig.org/ispconfig/ispconfig3/-/issues/6091
