[ 
https://issues.apache.org/jira/browse/CASSANDRA-19750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18103461#comment-18103461
 ] 

Mohammad Suhel commented on CASSANDRA-19750:
--------------------------------------------

Sorry for the silence on this one — I was on a break for a while and missed 
following up on this thread.

I went back and looked at the redhat/cassandra.spec change I made, and I don't 
think it was right. What I did was remove the default.conf/ subdirectory that 
alternatives relies on, and point alternatives at /etc/cassandra itself instead 
— which is a self-referencing symlink and breaks the whole point of 
alternatives (being able to swap out which config set /etc/cassandra/conf 
points to). [~smiklosovic]  that was basically the answer to what you were 
asking — before my change it copied everything into default.conf/ and 
alternatives symlinked conf -> default.conf/; after my change it copied 
straight into /etc/cassandra/ and tried to point alternatives at that same 
directory, which doesn't really make sense.

But digging further, it turns out the RedHat side never actually had this bug 
in the first place. The existing cp -pr conf/* in the spec is a wildcard, so it 
already picks up cassandra-jaas.config along with everything else in conf/ — I 
didn't have to add anything for it. I wanted to be sure rather than just assume 
that though, so I actually built it end to end: ran ant artifacts to produce 
the real source tarball, built the RPM from the unmodified spec with rpmbuild, 
and checked rpm -qlp — cassandra-jaas.config is right there under 
/etc/cassandra/default.conf/. Then I installed that RPM on a live AlmaLinux 9 
container and let the real alternatives binary do its thing in %post — it 
created the /etc/cassandra/conf -> default.conf/ symlink like it's supposed to, 
and $CASSANDRA_CONF/cassandra-jaas.config (which is what cassandra-env.sh 
actually references) resolved straight through to the real file. Also checked 
3.11, 4.0, 4.1, 5.0, trunk, and the exact 4.1.5 tag from this ticket — same 
file, same spec logic everywhere.

So unlike Debian's .install file, which really was missing the entry (it's an 
explicit list, not a wildcard), RedHat didn't need a fix at all.

While I was at it I also rebuilt the Debian package for real 
(dpkg-buildpackage) and checked the resulting .deb with dpkg-deb -c — 
cassandra-jaas.config lands at /etc/cassandra/cassandra-jaas.config with the 
right permissions, matching how CASSANDRA_CONF is set on Debian. So that part 
is confirmed good as originally submitted.

I've pushed an update to the PR: redhat/cassandra.spec is back to how it was. I 
also rebased onto current cassandra-4.1 since the branch had drifted quite a 
bit while I was away — it's now just the one clean commit, should be much 
easier to review.

Let me know if anything's still off.

> /etc/cassandra/cassandra-jaas.config does not exist in Packages install
> -----------------------------------------------------------------------
>
>                 Key: CASSANDRA-19750
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-19750
>             Project: Apache Cassandra
>          Issue Type: Bug
>          Components: Packaging
>            Reporter: Johnny Miller
>            Assignee: Mohammad Suhel
>            Priority: Normal
>             Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0.x, 6.x
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> When installing cassandra 4.1.5 wth the debian packaged installer the file 
> cassandra-jaas.config  does not exist.
> When enabling JMX authentication in the cassandra-env.sh you uncomment the 
> line JVM_OPTS="$JVM_OPTS 
> -Djava.security.auth.login.config=$CASSANDRA_CONF/cassandra-jaas.config" 
> It is expecting this file to be in this location (which maps to 
> /etc/cassandra/) and it is not.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to