这是indexloc提供的服务,不要输入任何密码
Skip to content

Conversation

@josegonzalez
Copy link
Member

No description provided.

@michaelshobbs
Copy link
Member

While we do overwrite /etc/nginx/nginx.conf, this will cause us not to get any conf updates from the upstream. I think we need an nginx upgrade strategy at some point. Maybe pin this to a version for now?

@josegonzalez
Copy link
Member Author

We don't want or need upstream changes. Can you describe a time when that wouldn't be the case?

@michaelshobbs
Copy link
Member

Currently we install nginx/1.6.2 because that's the latest in the repo. However, in this config, we could get nginx/1.7.0 binaries but nginx/1.6.2 config. This could be bad. I think the pedantically correct thing to do here is to pin to nginx/1.6.2 and keep old configs. Right?

@josegonzalez
Copy link
Member Author

They won't upgrade to 1.7.0 in a trusty release, and thats what we promote to users. If a user installs on another system, thats outside of what we can logically support and thus don't need to worry. I don't foresee us moving to 14.10 for example, or 15.04 when that comes out - just the latest LTS.

@michaelshobbs
Copy link
Member

I was using 1.7.0 as an example. Substitute that for any release that causes a change in config that we may want. Perhaps a security item or something of that nature.

I think pinning the version is the right move here. It also avoids any other oddities that might come up that break any of our config assumptions.

My stance is probably a little on the conservative side of the spectrum but pinning as a principle generally saves you headaches in the future and allows/forces you to be deliberate in your infrastructure changes.

@josegonzalez
Copy link
Member Author

I don't think pinning will work unless we copy the nginx package to our deb repo. Otherwise, ubuntu can/will remove the package once they update their own version.

@michaelshobbs
Copy link
Member

I mean we would need to keep up-to-date within reason. Currently versions go back to 1.4.6 in the trusty repos. So I don't think we're in any danger of 1.6.2 disappearing any time soon. Besides its much easier to debug an installation issue where the nginx package can't be installed versus some weird config issue. Ya know?

@josegonzalez
Copy link
Member Author

Gotcha, I'll update the PR to do that. Though it won't help for people updating from older versions of dokku...

@michaelshobbs
Copy link
Member

How do you mean it won't help?

@josegonzalez
Copy link
Member Author

Users coming from older versions will have their nginx upgraded and that is what is causing issues.

@michaelshobbs
Copy link
Member

Yeah that's fair. This would cause them to run 1.6.2 with 1.4.6 config other than our stuff we overwrite.

@josegonzalez
Copy link
Member Author

No, we update the nginx config to be what it should be, so they'd be running 1.6.2 with our approved config.

@michaelshobbs
Copy link
Member

There is other config that /etc/nginx/nginx.conf. We source in /etc/nginx/conf.d/* and /etc/nginx/sites-enabled/*`. It's probably fine though.... (famous last words)

@josegonzalez
Copy link
Member Author

The sourcing also happens in the normal config. The reason we even overwrite the config is because of the custom file in the conf.d. New versions make that setting default :|

@josegonzalez
Copy link
Member Author

Whats the verdict on this then?

@michaelshobbs
Copy link
Member

👍

josegonzalez added a commit that referenced this pull request Jan 16, 2015
Keep existing configuration files when installing nginx. Refs #886
@josegonzalez josegonzalez merged commit 514d66f into master Jan 16, 2015
@josegonzalez josegonzalez deleted the keep-old branch January 16, 2015 20:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants