Default index.html blindly overwritten

Bug #1194074 reported by Xevian Wake on 2013-06-24
44
This bug affects 7 people
Affects Status Importance Assigned to Milestone
nginx (Debian)
Fix Released
Unknown
nginx (Ubuntu)
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).

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
Launchpad Janitor (janitor) wrote :

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

Changed in nginx (Ubuntu):
status: Incomplete → Expired
Assaf Hershko (assaf-hershko) wrote :

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

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.

Thomas Ward (teward) wrote :

Confirmed because of duplicate bug #1245827

Changed in nginx (Ubuntu):
status: Expired → Confirmed
Nat Brown (natbro) wrote :

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

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
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.

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)

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.

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.

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?

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?

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
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!

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

Tony (archeybunker) 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.

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.

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.

To post a comment you must log in.
This report contains Public information  Edit
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.