Default index.html blindly overwritten

Bug #1194074 reported by Xevian Wake
44
This bug affects 7 people
Affects Status Importance Assigned to Milestone
nginx (Debian)
Fix Released
Unknown
nginx (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

Just updated a server and the default /usr/share/nginx/www/index.html file was blindly overwritten with the 'Welcome to Nginx' one, as we're just using it for a simple website, the default configuration was used and this effectively took down the website (I had a backup and verified site, so was off for less than a minute).

Revision history for this message
Thomas Ward (teward) wrote :

Can you please add details of which Ubuntu version and which NGINX version you are using?

Changed in nginx (Ubuntu):
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for nginx (Ubuntu) because there has been no activity for 60 days.]

Changed in nginx (Ubuntu):
status: Incomplete → Expired
Revision history for this message
Assaf Hershko (assaf-hershko) wrote :

This just happened to me as well.. Ubuntu 12.04, Nginx 1.1.19.

Revision history for this message
Assaf Hershko (assaf-hershko) wrote :

To stress - it's a very serious issue, which took down a server and also meant code loss (as, unfortunately, the backup wasn't up to date). Can you please investigate? I'm concerned about it happening again.

Should I open a new bug, or can you re-open an expired one? Thanks.

Revision history for this message
Thomas Ward (teward) wrote :

Confirmed because of duplicate bug #1245827

Changed in nginx (Ubuntu):
status: Expired → Confirmed
Revision history for this message
Nat Brown (natbro) wrote :

happened to me twice, most recently Ubuntu 12.04.3 upgrading Nginx to 1.5.8.

Revision history for this message
Thomas Ward (teward) wrote :

Nat:

1.5.8 is not in Ubuntu, and you should not comment on a bug about 1.1.19 when you are using 1.5.8.

I have not yet tested to replicate this, or figure out a solution, but I have an idea of what needs to be done to fix this. Having said this, I am a little busy fighting with my system, so I'm going to mark this "Triaged" and work on this when I get the chance.

Changed in nginx (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Triaged
Revision history for this message
Thomas Ward (teward) wrote :

As a suggestion to all affected: I suggest that you do not use the default document root (/usr/share/nginx/www/) for your files, and instead use a different document root for your sites. By using the default document root, you are inviting issues such as these to occur.

I also suggest that you keep regular backups, which is part of server administration, to make sure that you don't lose your data.

Revision history for this message
Nat Brown (natbro) wrote :

Thomas - both points well taken, thanks for triaging. (fyi, 1.5.8 and now 1.5.9 are pulled in on 12.04.3 in AWS at least, so some folks who bump into this may be not purely stock, but again your point is well taken that 1.5.x aren't the minimal/initial test-case)

Revision history for this message
Robie Basak (racb) wrote :

I've just noticed this bug.

IMHO, /usr/share/nginx/www/ should never be used to actually serve files. To serve static files, the document root should be changed. Somewhere under /srv is suitable under the FHS.

It would be nice if this were documented better somehow (I don't know how), but this is a deliberate decision on the part of the Debian nginx maintainers. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730382 for some background and the current debate (which I note already links here as an example of how things go wrong).

I'm all for changing the default document root to /var/www/html/ like Apache to avoid this issue, but I think that this change is still up for debate in Debian. I'm neutral on whether Ubuntu should unilaterally make this change outside of Debian. On one hand I prefer not to diverge, but the existence of this bug does demonstrate that this is a real issue for real Ubuntu users. Apache's way seems to do better and is decades old.

Revision history for this message
Robie Basak (racb) wrote :

> IMHO, /usr/share/nginx/www/ should never be used to actually serve files.

Apart from the default ones provided by packaging, of course.

Revision history for this message
JKL (jkl102001) wrote :

Irrespective of what the default document root is, whether it is /usr/share/nginx/www or /var/www/html, the issue in this bug report is whether a user should expect to be able to modify the index.html file in the default document root and have those changes respected.

If your answer is that the default document root isn't a place that a user can put files, because certain files will be destroyed by package updates, than I put to you this question: what is the point of having a default document root in the first place?

I submit that everything installed under the default document root should be marked as a configuration file in the package, so that user modifications will be respected. I can't think of any good reason not to do things that way, regardless of what you think the document root should be.

Will Ubuntu fix the package, or does it need to be done by the Debian maintainer?

Revision history for this message
Robie Basak (racb) wrote :

> Will Ubuntu fix the package, or does it need to be done by the Debian maintainer?

Whether it needs "fixing" or not is a matter of debate. Personally, I agree with you, but this isn't a reason in itself to make a change. I would prefer to see consensus across Debian and Ubuntu, and am unwilling to advocate a change in Ubuntu's nginx packaging against Debian's opinion on this point.

Since Ubuntu follows Debian's direction by default, this needs to be taken up in Debian in the first instance. If you want to argue the point, then I suggest that you do it in the Debian bug.

Failing this, I think we need a specific reason to diverge in Ubuntu (as opposed to just a reason why Debian is wrong), since this commits Ubuntu developers to increased ongoing maintenance, and commits users to confusion because the two behave differently.

Is there perhaps some kind of middle ground? What if Debian shipped a README in /usr/share/nginx/www/ which prominently states that the directory will be overwritten on upgrade?

Revision history for this message
Michael Lustfield (michaellustfield) wrote :

Apache goes against the Debian policy on this one. They have to because of some hacks in some plugins that are supposed to enhance security. The default is simply a default. Some people will actually store websites in /etc/nginx/www/ on debian systems. There's no way to correct everyone that isn't willing to learn how to administer a system.

Even if we stick things where they don't belong (/var/www/html), people will still treat that like what they should overwrite which means we would then have to manage the package maintained version and the user version.

I'm okay with sticking a README file in the default location, but ... I really doubt anyone that needs to read it will actually read it.

For reference, I'm maintaining the package, and the first thing I do after installing nginx is rm /etc/nginx/sites-available/default. Some people prefer stuff be in /var/www, some prefer /srv, some even think /opt, and yet others think everything should be in /home. We adhere to the Debian policy which leaves the admin free to do whatever they want by way of simply creating their own config instead of using default.

Honestly, my intention with the default config was "it works", here are some examples and a quick intro to a config, now do it yourself.

Changed in nginx (Debian):
status: Unknown → Fix Released
Revision history for this message
Samuel Messner (obskyr) wrote :

This has been fixed for Debian, it should really be fixed for Ubuntu too. I don't keep the files being served in /usr/share/nginx/www/, but nginx still overwrote my index.html after an nginx -s reopen. I have a hard time seeing how this would be intended in any way - this behavior has the ability to hurt a site, not overwriting doesn't.

Hoping for a fix as soon as possible for Ubuntu, too!

Revision history for this message
Thomas Ward (teward) wrote :

Samuel Messner and everyone:

This has not actually been fixed based on the bug. The reason this is 'Fix Released' in Debian here is because Launchpad has the incorrect logic for the Debian bug. (See https://bugs.launchpad.net/launchpad/+bug/1413304 for details on the logic breakage).

From the Debian bug (and Michael Lustfield, who marked the bug as 'Done' in Debian, although it's not fixed):

The Linux FS hierarchy [1] is pretty self-explanatory and standard.
Unfortunately, many admins don't bother to actually read and
understand what the heck is going on in their system. They have a
tendency to follow poor documentation without verifying the quality of
it. It's a bit disturbing that the archlinux wiki has that, but at the
same time, it's edited by users.

We can't really police all documentation to ensure people use common
sense. As much as it's not our place to police all documentation on
the Internet, it's also not our place to protect users from every
single silly thing they may consider doing. It's taking
--no-preserve-root, and going a step further. Sure, this one could be
a simple patch. It's a patch that isn't needed, though.

I'm sorry to be blunt and perhaps a little rude, but there's only so
much hand-holding and so on that should be provided. In my book, this
one is well past the limit.

I do have some ideas to help with this blind assumption that package
territory is also user territory, but there's only so much that people
will read. They obviously aren't bothering to read the top comment on
the default nginx config.

[1] http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

Revision history for this message
Tony (archeybunker-deactivatedaccount) wrote :

Ubuntu 15.04 apt upgrades just overwrote my index.html at /usr/share/nginx/html/index.html

It looks like nginx had an update on 7-20. Regression seems to be there.

Revision history for this message
Thomas Ward (teward) wrote :

This isn't "fixed" - it's marked Fix Released in Debian only because of Debian considering this "Won't Fix".

There's a reason that we say that certain spaces on the file system aren't for users and this is one of them - this is why I said in my last post on this even that you should NOT be using the 'default' doc root.

Revision history for this message
Dan (0-dan-5) wrote :

I'd like to add to this, I installed nginx on my Raspberry Pi and was using it on my internal network. I'm not an administrator, just a tinkerer who has no knowledge that the default www share should not be used. Because of this i've lost my index.html that i was using.

I'd assume there are a lot of users like me who are not using nginx in a production environment, and as such i consider this to be a bug. A pretty bad bug that can wipe out someones hard work for absolutely no reason. Why even overwrite the standard index when you upgrade? It seems even more ridiculous than expecting everyone to know not to use the default www.

Revision history for this message
Frak (frakman) wrote :

When upgrading nginx, the installer is smart enough to notice that my configuration files are changed and gives me the option to keep my modified one, or update it, diff it etc but isn't smart enough to make a backup of index.html before it overwrites it? How hard is it to do the same thing for index.html??

Do the right thing and fix this so people can upgrade peacefully. Saying that 'you should have had a backup' is just lazy and irresponsible.

Revision history for this message
Thomas Ward (teward) wrote :

@Frak which NGINX are you upgrading from on which OS?

In current versions of the package from 16.04 and later, there is configuration changes in postinst to *NOT* overwrite index.html if an index.html exists already in the default docroot.

Revision history for this message
Frak (frakman) wrote :
Download full text (4.1 KiB)

Thank you for writing back Thomas. It seems I did not get that protection since I am on Ubuntu 14.04.
I am pleased to hear, however, that the installer behavior has improved. Thank you.

I was on nginx version 1.4.6 and upgraded to 1.12.2 to get support for dynamically loaded modules.
I am on Ubuntu 14.04.1. I upgraded using this sequence:

sudo add-apt-repository ppa:nginx/stable
sudo apt-get update
sudo apt-get install libnginx-mod-http-fancyindex

Previous version:
-----------------
nginx version: nginx/1.4.6 (Ubuntu)
built by gcc 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3)
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror =format-security -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro' --prefix=/u sr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log- path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --http-client- body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-pa th=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx /uwsgi --with-debug --with-pcre-jit --with-ipv6 --with-http_ssl_module --with-http_stub_status_module - -with-http_realip_module --with-http_addition_module --with-http_dav_module --with-http_geoip_module -- with-http_gzip_static_module --with-http_image_filter_module --with-http_spdy_module --with-http_sub_mo dule --with-http_xslt_module --with-mail --with-mail_ssl_module

Current Version:
----------------
nginx version: nginx/1.12.2
built with OpenSSL 1.0.1f 6 Jan 2014
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -fPIC -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now -fPIC' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_flv_module --with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_mp4_module --with-http_perl_module=dynamic --with-http_random_index_module --with-http_secure_link_module --with-http_sub_module --with-http_xslt_module=dynamic --with-mail=dynamic --with-mail_ssl_module --with-stream=dynamic --with-stream_ssl_module --with-stream_ssl_preread_module --add-dynamic-module=/build/nginx-WaTJd7...

Read more...

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.