Hi Damian,
previously, I was on nginx 1.24, I see issues around security.
Many of these issue have been addressed by 1.27.
So, I upgraded - now nothing works again.
Whereas before it used
sever name definition:
was in sites-available as default (which I removed) and mysite.com had server_definition
html:
the default html was in /var/www/html/ And the mysite.com was in the /var/www/mysite.com
and /etc/nginx/nginx.conf
I tried moving the html to the /usr/share/nginx/mysite.com
AND
server definition files to /etc/nginx/conf.d
WHILE the /etc/nginx/nginx.conf file look different.
Q: where can I now find the configuration location so that 1.27 actually works? I am going backwards here. Quite frustrating.
Please advise. Maybe an example??
2 Likes
It would probably be most helpful here to share your full configuration. if you run nginx -V it should print the full config that nginx has in memory. There shouldn’t have been any configuration changes that would break between those versions, but it sounds like it might have a change in the directory structure of where it expects configs to be(sites-enabled is a “legacy” setup, while conf.d is the current standard structure).
When it comes to where you store your site static content, you can define where nginx looks for that content in the config. Just need to make sure that nginx has permissions to access the files.
1 Like
OK,
so here it is:
built by gcc 13.2.0 (Ubuntu 13.2.0-23ubuntu4)
built with OpenSSL 3.0.13 30 Jan 2024
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-http_v3_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt=‘-g -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffile-prefix-map=/data/builder/debuild/nginx-1.27.4/debian/debuild-base/nginx-1.27.4=. -flto=auto -ffat-lto-objects -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -fdebug-prefix-map=/data/builder/debuild/nginx-1.27.4/debian/debuild-base/nginx-1.27.4=/usr/src/nginx-1.27.4-1~noble -fPIC’ --with-ld-opt=‘-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -Wl,-z,relro -Wl,-z,now -Wl,–as-needed -pie’
It is a new vps/site. The upgrade broke the certs and I can’t seem to fix it (Certbot fails).
ping6 to google works so the network is alive.
Mostly because, as stated, the config is rather different to what it was for 1.24 (it was working then). My point is: it is OK to change the design but the change is design philosophy has an impact and folks (like me who are learners - need some pointers/docs to understand the rationale behind the changes) and therefore can figure out where to look/resolve. I know it sounds like whinging - and I truly am not - but it is very frustrating to folks not having a reference example to work from, if you see what I mean. It increases the barrier of adoption to newbies. I am a big fan of opensource/gpl and support it in my work.
Maybe it is the DNS - I can ping out not not in, the url does to resolve
1 Like
Hi Damian,
I noticed this is flagged as solved. I thought the protocol was that as originator of the issue am supposed to state it is solved/closed? (or in some cases the issue has had no further originator input for (say 2 days) the the issue is auto closed? This seems common practice, surely?
Setting that aside: You stated the web server redirection files are now positioned in config.d and the actual web files can be anywhere (as long as they can be accessed).
In my case: I have positioned the web server redirection files in config.d. In the file I have called out the location of the web index file (I left it at the original location of /var/www/) so the
server {
server_name mysite.xxx www.mysite.xxx;
root /var/www/mysite.xxx;
index index.html;
location / {
try_files $uri $uri/ =404;
}
as stated the html is stated at /var/www
When I run certbot:
certbot install --cert-name mysite.xxx-0001
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Deploying certificate
Could not install certificate
Could not automatically find a matching server block for mysite.xxx. Set the server_name directive to use the Nginx installer.
What server_name it it referring to? It seems that the files above is not visible.
Note: mysite.xxx is an example site AND I am running in a VPS
1 Like
@Damian_Curry
After 3 days I have worked out the answer and it is simple.
In /etc/nginx/conf.d, the website config files for the site should have an extension of .conf - e.g. mysite.abs.conf
Once I changed that then the website was working and certbot could be applied. (NB rename/delte the default file)
However, there is a lack of consistency here!
I suggest that the default file should be called default**.conf**. This is in order to ensure all the website (server) files have .config extensions.
I have been on many forums and posted this issue and have yet to receive a response - to avoid all newbie frustrations please consider the suggestion.
3 Likes
Sorry for not responding earlier, but that would be the issue. What files are read from the conf.d directory is defined by the include statement in the nginx.conf. By default it is set to include /etc/nginx/conf.d/*.conf. This does seem to be something that we need to more clearly define in the documentation.
3 Likes
Just to clarify, you are trying to serve static content from nginx on ‘myexample.net’, correct? can you share the output of nginx -T? That should print the running config nginx has in memory. When you mention restarting the webserver, are you referencing restarting the nginx process or the entire system? The part about breaking DNS is confusing me as well. Is this a public facing site with DNS pointed at your public IP of the NGINX server? Is NGINX running on a VM/baremetal or a container? Are you installing NGINX from the default os package manager?