You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Michael Shuler (JIRA)" <ji...@apache.org> on 2015/12/15 20:11:46 UTC
[jira] [Commented] (CASSANDRA-10872) Debian Package does not prompt
the user to review the config files; it just replaces them causing trouble
(since the daemon starts by default)
[ https://issues.apache.org/jira/browse/CASSANDRA-10872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058577#comment-15058577 ]
Michael Shuler commented on CASSANDRA-10872:
--------------------------------------------
Thanks for the report, [~synbit].
> Debian Package does not prompt the user to review the config files; it just replaces them causing trouble (since the daemon starts by default)
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-10872
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10872
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
> Environment: Ubuntu 12.04, Cassandra 2.0.16 -> 2.0.17
> Reporter: Vasilis
> Assignee: Michael Shuler
> Priority: Critical
>
> We run Cassandra 2.0.16 on Ubuntu 12.04 and were trying to upgrade to 2.0.17 due to CASSANDRA-9662. The problem is that during the upgrade the we were not prompted how to handle cassandra-env.sh and cassandra-rackdc.properties.
> The output from the upgrade:
> Setting up cassandra (2.0.17) ...
> Installing new version of config file /etc/cassandra/cassandra-env.sh ...
> Installing new version of config file /etc/cassandra/cassandra-rackdc.properties ...
> This meant that the nodes started automatically after the install with the wrong DC name.
> I don't think that these config files should have been replaced without the admin being asked; this doesn't appear to comply with standard Debian packages.
> Secondly if CASSANDRA-2356 was implemented the problem would not be as severe; i.e. it would be possible to workaround this issue. Whereas currently, there is no way to prevent the node when upgraded from starting in the wrong DC.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)